理解 Objective-C 的 ARC

在ARC出现以前，程序员们只能靠retain/relese/autorelease来确保对象们恰好“坚持”到被需要的那一刻。如果忘了retain，或者多次release某个对象，程序就会发生内存泄漏的问题，甚至直接崩溃。

在Xcode 4.2中，除了语法检查外，Apple的新LLVM编译器还将内存管理的苦差事接了过来，它会检查代码，决定何时释放对象。Apple的文档里是这么定义ARC的:

“自动引用计数(ARC)是一个编译器级的功能，它能简化Cocoa应用中对象生命周期管理（内存管理）的流程。” 

ARC使内存管理在大部分时候变得如同小事一桩，但我们仍要在决定自己的类如何管理其它对象的引用时承担一些责任。

那么，让我们正式开始吧……

手工引用计数

手工管理、引用计数式的内存管理在iOS中是这样工作的: 当使用alloc/init(或其它类似方法)创建对象时，随同对象返回的，还有个retainCount，其值为1，表明我们获得了这个对象的所有权。

1 2 3

NSObject *obj = [[NSObject alloc] init]; // do some stuff [obj release];

在对象的alloc/init和release(即放弃对象的所有权)之间，我们可以任意处理它，这很安全，因为系统是无法回收正在使用中的对象的。

自动释放池

将对象加入到自动释放池也是类似，对象会一直存在，直到未来的某个时间我们不再需要它，才会被系统回收。

1 2 3 4

-(NSObject*) someMethod {   NSObject *obj = [[[NSObject alloc] init] autorelease];   return  obj;  // will be deallocated by autorelease pool later }

ARC的工作原理

大多数新的iOS程序员都会在引用计数这问题上遇到理解障碍。ARC则是一个编译前的步骤，它为我们的代码自动加上retain/release/autorelease语句。

ARC并不是垃圾收集，而且，引用计数也没有消失，只是变成自动而已。听起来像是事后追加的这么一个功能，不过，只要我们想一想Objective-C有多少功能是通过对源文件的预处理来实现的，就不会这么想了。

当采用ARC后，代码只要这样写:

1 2	NSObject *obj = [[NSObject alloc] init]; // do some stuff

ARC会自动将它变成:

1 2 3

NSObject *obj = [[NSObject alloc] init]; // do some stuff [obj release];  // **Added by ARC**

从下图(来自Apple官方文档)看起来，好像retain/release的数量快赶上真正有用的代码了。当然，这肯定不是熟手的情况，不过可以看成是对新手的保守估计。这些代码跑起来，要跟踪某个内存问题真的是会搞死人。

在工程中开启ARC

如果想开启ARC，只要在工程的Build Settings中设置ARC为YES。在幕后，实际上是设置了-fobj-arc的编译器标识。

ARC施加的新规则

如果想用ARC，必须服从一些新规则。

1. 对象的Alloc/Init

创建对象的方法跟以前一样，但你一定不能调用retain/release/autorelease/retainCount。也不能通过selector偷偷地调用它们: 禁止使用@selector(retain)和@selector(release)。

2. dealloc方法

ARC为自动为你调用，一定不能直接调用dealloc。不过，如果你需要释放实例变量以外的资源，还是可以创建自定义的dealloc方法。但在这个方法里，不要调用[super dealloc]。因为ARC会帮你调。

3. 声明的属性

在ARC之前，我们是用@property指令中的assign/retain/copy参数来告诉编译器，如何管理这些属性的内存。用了ARC之后，这些参数就作废了，改用weak/strong这两个参数。

4. C结构中的对象指针

同样禁止使用。文档里建议不要把它们放在结构了，改放到类里去。否则ARC就不认识它们了。可能会出现一些移植上的问题。不过，ARC是可以以文件为单位来关闭的。参考下文的“引入不兼容ARC的代码”。

5. id与void*之间的临时互转

当我们在Core Foundation的C函数和Foundation Kit的Objective-C方法间传递对象时，常常需要进行id和void*两个类型的互转。叫做无缝桥接(Toll Free Bridging)。

如果使用ARC，必须在CF对象进入和脱离ARC的控制时，用提示/限定符来告知编译器。限定符有__bridge、__bridge_retain和__bridge_transfer。另外，仍需要用CFRetain和CFRelease来管理Core Foundation的对象。

这一块已经比较高深了，如果你不清楚CF对象是什么，也不需要太烦恼。

6. 以@autoreleasepool代替NSAutoReleasePool

兼容ARC的代码不能再使用NSAutoReleasePool对象，而要改用@autoreleasepool{}块。一个很好的例子:

1 2 3 4 5 6

int main(int argc, char *argv[]) {   @autoreleasepool {     return  UIApplicationMain(argc, argv, nil, NSStringFromClass([ExampleAppDelegate class]));   } }

7. 其它

基于Zone的内存已经没了(在运行时里也没了)。不能再使用NSAllocateObject和NSDeallocateObject。

ARC限定符 - 声明的属性

身为程序员，习惯于做出一些决定，例如把某个量声明为变量还是常量、本地还是全局，等等。因此，在这里，我们也要决定某个属性与其它属性的关系。我们用strong/weak来把这一关系告诉编译器。

强引用

强引用是对某对象的引用，并且能阻止它被回收。换句话说，强引用创建了一个所有关系。在ARC之前，我们这么写:

1 2	// Non-ARC Compliant Declaration @property(retain) NSObject *obj;

在ARC下，我们需要这么写，以确保当前实例获得被引用对象的所有权(主人不被回收，它也不能被回收)。

1 2	// ARC Compliant Declaration @property(strong) NSObject *obj;

弱引用

弱引用是对某对象的引用，但不能阻止它被回收。换句话说，弱引用并不会创建所有关系。在ARC之前，我们这么写:

1 2	// Non-ARC Compliant Declaration @property(assign) NSObject *parentObj;

在ARC下，我们需要这么写，以确保当前实例没有获得被引用对象的所有权(一般来说，子对象不应该拥有父对象，这时可以用弱引用)。

1 2	// ARC Compliant Declaration @property(weak) NSObject *parentObj;

ARC限定符 - 常规变量

上一节是说明如何管理属性。对于常规变量，则有:

1 2 3 4

__strong __weak __unsafe_unretained __autoreleasing

一般来说，我们不太需要使用上面这些限定符。在使用移植工具的时候可能会看到那么几个，但新工程基本上不需要。

__strong: 默认限定符，不需要显式指定。表示任何用alloc/init创建的对象在当前范围的生命期内得以保留。“当前范围”是指变量声明语句所在的两个大括号之间(方法、循环、块，等等)。

__weak: 表示对象可以随时被摧毁。只有当它被其它对象强引用时才有用。__weak变量在摧毁时，被设为nil。

__unsafe_unretained: 与__weak类似，但在摧毁时，不设为nil，保留原值（不再指向有效的东西）。

__autoreleasing: 不要与autorelease搞混，它用于通过引用传递对象，比如，通过引用传递NSError对象: [myObject performOperationWithError:&tmp]。

来源: Clang project

注: 我们发现在ARC下，@property中使用“retain”时(而不是“strong”)，编译器并不会报错，而且能生成同样结果。但以后可能会变，所以还是用“strong”吧。

移植到ARC

Xcode 4.2提供了一个移植ARC的工具，还可以帮你将无法自动移植的代码手工转换过去。

1. 打开不兼容ARC的工程，进入Edit > Refactor > Convert to Objective-C ARC。

   
   

2. 选择需要转换的构建目标和文件(在后续步骤排除不需要转换的文件)

3. 运行预查，按下一步。

注: 按下一步后，LLVM编译器会开始构建，以便对工程进行分析。如果有错误，是无法进入下一步的。如果是第一次打开低版本Xcode建立的工程，请先执行清理。

4. 检查一下工具建议的修改，并选择是否要排除某个文件。然后按下保存。

注: 如果有文件无法移植，工具也会告诉你。并不是所有文件都需要移植(包括库)。ARC是以文件为基础生效的，可以参考下文，看编译时如何把不需要开启ARC的文件排除在外。

5. 工具会自动设置编译器的标识，开启ARC。可以查看工程的Build Settings确认这一点。

引入不兼容ARC的代码

Apple的文档说，“ARC能以文件为基础，与采用手工引用计数的代码进行交互。你可以在部分文件上使用手工引用计数。”

它的意思是说，我们可以让一部分文件用ARC，另一部分文件不用。下面是将文件批量排除在ARC之外的步骤。在我写下这篇文章的时候，还有许多流行的库都没有用ARC，为了解决这个问题，请按照下面的步骤做:

在Xcode的工程树上，点击你自己的工程

点击Target

选择Build Phases标签

展开Compile Sources

选择需要排除在ARC外的文件

按下回车

输入-fno-objc-arc

再按下回车

现在，你选中的文件都有了-fno-objc-arc编译器标识，会被排除在ARC之外

我该用ARC吗？

如果你是Objective-C的新手，肯定会欢迎ARC。一开始，有太多的东西要学习，有了ARC就不用担心手工计数的问题。随着你开始接触一些已有的库，就会经历一些痛苦(译者注: 目前的第三方库很多不兼容ARC)，但只要习惯了将它们排除在ARC之外，就没什么问题了。

如果你不是新手，在没有ARC的年代已经玩的很high，那么可能会觉得“我干嘛要用它！”对你来说，这可能是正确的答案——就目前而言。因为，大多数流行的库都还没转到ARC下，而且ARC对Core Foundation的支持也不好。使用CF类的时候有一些限制，而且，移植代码的时候，为了让免费桥接生效，还需要加上一大堆限定符。

在我看来，目前ARC已经是可以使用的状态了。不过，除非你对它很熟悉，否则还是先用在新工程里会比较好。虽然ARC兼容iOS 4.0以上，但弱引用只在iOS 5.0以上才支持，所以现在还是不要把所有东西都移植过去(有一些相关的文章，请参考最后的“资源”一节)

至于性能方面，早前有报告指出用ARC之后速度会变快，我想可能是由于减少对自动释放的依赖的缘故。虽然这完全可以通过改进代码、更好地使用retain/release来实现，但我觉得重点在于，ARC总是会自动帮你选择最优的方法。

目前为止，还是有很多令人苦恼的东西被移到ARC，但还不是全部。在长周末后我们会离开一段时间以投入到新的项目，但是这是苹果一个“新的”推荐手段，所以你可以肯定以后的设计决策会继续强大ARC并且让大家离开使用手动的引用计数。

Convenience method的内存管理

        与自动释放相关的，有一大类构造方法（constructor method），由它们构造的对象直接就是自动释放的对象；这一类构造方法叫做便捷方法。比如下面这句的字符串就是一个自动释放的对象，stringWithFormat:就是一个便捷方法。

NSString* string = [NSString stringWithFormat:@”autoreleaseString”];

再举几个便捷方法的例子。

1.NSArray的arrayWithObjects:和arrayWithArray:。

2.UIImage的imageNamed:。

3.NSNumber的numberWithBool等。

        也就是说这些方法返回的对象，我们可以用，但是还是不能确定得知道她什么时候dealloc，那么我们能不能主动删除这些“便捷函数”返回的对象呢？如果，程序中有大量的“便捷函数”，这样无疑占用了大量内存空间。

        难道只能避免循环调用这种“便捷函数”？

        现在我们已经解释了，autorelease方法会在一段时间以后释放掉一个对象，在这段时间内我们可以安全地使用该对象。那么这段时间究竟是多久呢？

        上面已经介绍了自动释放的机制，“便捷函数”产生的对象至少能够存活到自动释放池销毁的时候。