Tag: 自动ref counting

Objective-C中的自动引用计数不会阻止或最小化什么样的泄漏？

在Mac和iOS平台上，内存泄漏通常是由未释放的指针引起的。 传统上，检查你的分配，复制和保留以确保每个都有相应的释放消息一直是非常重要的。 Xcode 4.2附带的工具链引入了最新版本的LLVM编译器的自动引用计数（ARC），通过让编译器为你编写内存pipe理你的东西，完全消除了这个问题。 这非常酷，它确实减less了大量不必要的，平凡的开发时间，并防止了大量的不小心的内存泄漏，这些泄漏很容易通过适当的保留/释放平衡来修复。 甚至当您为Mac和iOS应用程序启用ARC时，需要对autorelease池进行不同的pipe理（因为您不应再分配您自己的NSAutoreleasePool ）。 但是还有什么其他的内存泄漏不能防止我仍然需要注意？ 另外，Mac OS X和iOS上的ARC和Mac OS X上的垃圾收集有什么区别？

泄漏仪器不显示时如何debugging内存泄漏？

我有一个用Swift编写的iOS应用程序正在泄漏内存 – 在某些情况下，应该释放一些对象，但它们不是。 我已经通过简单地添加deinitdebugging消息来了解这个问题： deinit { println("DEINIT: KeysProvider released") } 所以，在应该导致对象释放的事件之后，deinit消息应该出现在控制台中。 但是，对于一些应该发布的对象，则缺less该消息。 尽pipe如此，泄漏开发工具并没有显示任何泄漏。 我如何解决这种情况？

要ARC还是不要ARC？ 优缺点都有什么？

我还没有使用ARC，因为目前正在处理的项目中的大部分代码都是在iOS 5.0之前编写的。 我只是想知道，不手动保留/释放的方便性（大概是可靠性更高的代码）会超过使用ARC的“成本”吗？ 你有什么经验的ARC，你会推荐它？ 所以： ARC能为项目带来多less好处？ ARC在Java中有像垃圾收集一样的成本吗？ 你有没有使用ARC，如果是的话，你到目前为止如何find它？

我如何实现与ARC兼容的Objective-C单例？

如何转换（或创build）在Xcode 4.2中使用自动引用计数（ARC）时编译和行为正确的单例类？

如何在执行API时避免在块中捕获自己？

我有一个工作的应用程序，我正在将其转换为Xcode 4.2中的ARC。 其中一个预先检查的警告涉及在一个导致保留周期的块中强烈地捕获self 。 我已经做了一个简单的代码示例来说明问题。 我相信我明白这意味着什么，但我不确定实施这种情况的“正确”或推荐的方式。 self是类MyAPI的一个实例 下面的代码被简化为只显示与我的问题相关的对象和块的交互 假设MyAPI从远程源获取数据，MyDataProcessor使用该数据并生成输出 处理器configuration有块来传输进度和状态 代码示例： // code sample self.delegate = aDelegate; self.dataProcessor = [[MyDataProcessor alloc] init]; self.dataProcessor.progress = ^(CGFloat percentComplete) { [self.delegate myAPI:self isProcessingWithProgress:percentComplete]; }; self.dataProcessor.completion = ^{ [self.delegate myAPIDidFinish:self]; self.dataProcessor = nil; }; // start the processor – processing happens asynchronously and the processor is released in the […]

为什么在ARC中仍然需要@autoreleasepool？

对于大多数情况下，使用ARC（自动引用计数），我们不需要考虑Objective-C对象的内存pipe理。 不允许再创buildNSAutoreleasePool ，但有一个新的语法： @autoreleasepool { … } 我的问题是，当我不应该手动释放/自动释放时，为什么我需要这个？ 编辑：总结一下我所得到的一切和评论简洁： 新的语法： @autoreleasepool { … }是新的语法 NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; … [pool drain]; 更重要的是： ARC使用autorelease以及release 。 它需要一个自动释放池来实现。 ARC不会为您创build自动释放池。 然而： 每个Cocoa应用程序的主线程中都有一个autorelease池。 有两种情况你可能想要使用@autoreleasepool ： 当你在一个辅助线程中，并且没有自动释放池时，你必须自己来防止泄漏，比如myRunLoop(…) { @autoreleasepool { … } return success; } myRunLoop(…) { @autoreleasepool { … } return success; } 。 当你想创build一个更加本地化的游泳池时，正如@mattjgalloway在他的回答中所表明的那样。

Objective-C ARC：强大vs保留和弱与分配

ARC引入的属性有两个新的内存pipe理属性， weak 。 除了copy ，这显然是完全不同的东西， strong与保与weak assign有区别？ 根据我的理解，这里唯一的区别是weak将指向nil ，而assign不会，这意味着一旦释放指针，就会向指针发送消息时程序崩溃。 但如果我使用weak ，这将不会发生，因为消息发送到nil将不会做任何事情。 我不知道strong和retain之间的任何差异。 为什么我应该使用assign和retain在新项目中，还是有什么理由被弃用？

performSelector可能会导致泄漏，因为它的select器是未知的

ARC编译器收到以下警告： "performSelector may cause a leak because its selector is unknown". 这是我正在做的事情： [_controller performSelector:NSSelectorFromString(@"someMethod")]; 为什么我得到这个警告？ 我知道编译器不能检查select器是否存在，但为什么会导致泄漏？ 我怎样才能改变我的代码，使我不再得到这个警告？

如何禁用项目中单个文件的ARC？

我在我的项目中成功使用了ARC。 但是，我遇到了一些文件（比如unit testing和模拟对象），现在ARC的规则稍微脆弱一些。 我记得听说有一种方法可以在每个文件的基础上禁用ARC，尽pipe我一直无法find这个选项。 这可能吗？ 如何在每个文件基础上禁用ARC？

我们应该在Swift中总是使用封闭

在WWDC 2014会议403 中级Swift和成绩单中 ，有以下幻灯片 在这种情况下，发言者说，如果我们不使用[unowned self] ，那将是一个内存泄漏。 这是否意味着我们应该总是在关闭中使用[unowned self] ？ 在Swift Weather应用程序的ViewController.swift的第64行 ，我没有使用[unowned self] 。 但我通过使用self.temperature和self.loadingIndicator等一些@IBOutlet来更新UI。 这可能是好的，因为我定义的所有@IBOutlet都是weak 。 但为了安全起见，我们是否应该总是使用[unowned self] ？ class TempNotifier { var onChange: (Int) -> Void = {_ in } var currentTemp = 72 init() { onChange = { [unowned self] temp in self.currentTemp = temp } } }