自动引用计数(Automatic Reference Counting, ARC)把压在程序员们肩头的管理内存的重担卸除了不少，更不用说让跟踪内存泄漏那样的烦心事也少了很多。不过，虽然ARC很棒，我们仍然不能完全把内存管理这回事儿抛在脑后。
这篇文章将要讨论以下方面的问题，帮助大家快速进入ARC的世界。
在ARC出现以前，程序员们只能靠retain/relese/autorelease来确保对象们恰好“坚持”到被需要的那一刻。如果忘了retain，或者多次release某个对象，程序就会发生内存泄漏的问题，甚至直接崩溃。
在Xcode 4.2中，除了语法检查外，Apple的新LLVM编译器还将内存管理的苦差事接了过来，它会检查代码，决定何时释放对象。Apple的文档里是这么定义ARC的:
“自动引用计数(ARC)是一个编译器级的功能，它能简化Cocoa应用中对象生命周期管理（内存管理）的流程。”
ARC使内存管理在大部分时候变得如同小事一桩，但我们仍要在决定自己的类如何管理其它对象的引用时承担一些责任。
本文总共是从七个方向去说明的。那么，让我们正式开始吧……
一、引用计数是什么: 快速复习
手工管理、引用计数式（MRC）的内存管理在iOS中是这样工作的: 当使用alloc/init(或其它类似方法)创建对象时，随同对象返回的，还有个retainCount，其值为1，表明我们获得了这个对象的所有权。
在对象的alloc/init和release(即放弃对象的所有权)之间，我们可以任意处理它，这很安全，因为系统是无法回收正在使用中的对象的。
将对象加入到自动释放池也是类似，对象会一直存在，直到未来的某个时间我们不再需要它，才会被系统回收。
二、ARC的工作原理
大多数新的iOS程序员都会在引用计数这问题上遇到理解障碍。ARC则是一个编译前的步骤，它为我们的代码自动加上retain/release/autorelease语句。
ARC并不是垃圾收集，而且，引用计数也没有消失，只是变成自动而已。听起来像是事后追加的这么一个功能，不过，只要我们想一想Objective-C有多少功能是通过对源文件的预处理来实现的，就不会这么想了。
当采用ARC后，代码只要这样写:
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{}块。一个很好的例子:
7. 其它
基于Zone的内存已经没了(在运行时里也没了)。不能再使用NSAllocateObject和NSDeallocateObject。
五、ARC限定符 - 声明的属性
身为程序员，习惯于做出一些决定，例如把某个量声明为变量还是常量、本地还是全局，等等。因此，在这里，我们也要决定某个属性与其它属性的关系。我们用strong/weak来把这一关系告诉编译器。
强引用
强引用是对某对象的引用，并且能阻止它被回收。换句话说，强引用创建了一个所有关系。在ARC之前，我们这么写:
在ARC下，我们需要这么写，以确保当前实例获得被引用对象的所有权(主人不被回收，它也不能被回收)。
弱引用是对某对象的引用，但不能阻止它被回收。换句话说，弱引用并不会创建所有关系。在ARC之前，我们这么写:
在ARC下，我们需要这么写，以确保当前实例没有获得被引用对象的所有权(一般来说，子对象不应该拥有父对象，这时可以用弱引用)。
六、ARC限定符 - 常规变量
上一节是说明如何管理属性。对于常规变量，则有:
一般来说，我们不太需要使用上面这些限定符。在使用移植工具的时候可能会看到那么几个，但新工程基本上不需要。
__strong: 默认限定符，不需要显式指定。表示任何用alloc/init创建的对象在当前范围的生命期内得以保留。“当前范围”是指变量声明语句所在的两个大括号之间(方法、循环、块，等等)。
__weak: 表示对象可以随时被摧毁。只有当它被其它对象强引用时才有用。__weak变量在摧毁时，被设为nil。
__unsafe_unretained: 与__weak类似，但在摧毁时，不设为nil，保留原值（不再指向有效的东西）。
__autoreleasing: 不要与autorelease搞混，它用于通过引用传递对象，比如，通过引用传递NSError对象: [myObject performOperationWithError:&tmp]。
注: 我们发现在ARC下，@property中使用“retain”时(而不是“strong”)，编译器并不会报错，而且能生成同样结果。但以后可能会变，所以还是用“strong”吧。
七、移植到ARC
Xcode 4.2提供了一个移植ARC的工具，还可以帮你将无法自动移植的代码手工转换过去。
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并且让大家离开使用手动的引用计数。
(来自:开源中国AlfredCheung、周荣冰的翻译)
手工管理、引用计数式（MRC）的内存管理在iOS中是这样工作的: 当使用alloc/init(或其它类似方法)创建对象时，随同对象返回的，还有个retainCount，其值为1，表明我们获得了这个对象的所有权。
- NSObject *obj = [[NSObject alloc] init];
- // do some stuff
- [obj release];
将对象加入到自动释放池也是类似，对象会一直存在，直到未来的某个时间我们不再需要它，才会被系统回收。
- -(NSObject*) someMethod {
- NSObject *obj = [[[NSObject alloc] init] autorelease];
- return obj; // will be deallocated by autorelease pool later
- }
大多数新的iOS程序员都会在引用计数这问题上遇到理解障碍。ARC则是一个编译前的步骤，它为我们的代码自动加上retain/release/autorelease语句。
ARC并不是垃圾收集，而且，引用计数也没有消失，只是变成自动而已。听起来像是事后追加的这么一个功能，不过，只要我们想一想Objective-C有多少功能是通过对源文件的预处理来实现的，就不会这么想了。
当采用ARC后，代码只要这样写:
- NSObject *obj = [[NSObject alloc] init];
- // do some stuff
- NSObject *obj = [[NSObject alloc] init];
- // do some stuff
- [obj release]; // **Added by ARC**
三、在工程中开启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{}块。一个很好的例子:
- int main(int argc, char *argv[])
- {
- @autoreleasepool {
- return UIApplicationMain(argc, argv, nil, NSStringFromClass([ExampleAppDelegate class]));
- }
- }
基于Zone的内存已经没了(在运行时里也没了)。不能再使用NSAllocateObject和NSDeallocateObject。
五、ARC限定符 - 声明的属性
身为程序员，习惯于做出一些决定，例如把某个量声明为变量还是常量、本地还是全局，等等。因此，在这里，我们也要决定某个属性与其它属性的关系。我们用strong/weak来把这一关系告诉编译器。
强引用
强引用是对某对象的引用，并且能阻止它被回收。换句话说，强引用创建了一个所有关系。在ARC之前，我们这么写:
- // Non-ARC Compliant Declaration
- @property(retain) NSObject *obj;
- // ARC Compliant Declaration
- @property(strong) NSObject *obj;
- // Non-ARC Compliant Declaration
- @property(assign) NSObject *parentObj;
在ARC下，我们需要这么写，以确保当前实例没有获得被引用对象的所有权(一般来说，子对象不应该拥有父对象，这时可以用弱引用)。
- // ARC Compliant Declaration
- @property(weak) NSObject *parentObj;
六、ARC限定符 - 常规变量
上一节是说明如何管理属性。对于常规变量，则有:
- __strong
- __weak
- __unsafe_unretained
- __autoreleasing
一般来说，我们不太需要使用上面这些限定符。在使用移植工具的时候可能会看到那么几个，但新工程基本上不需要。
__strong: 默认限定符，不需要显式指定。表示任何用alloc/init创建的对象在当前范围的生命期内得以保留。“当前范围”是指变量声明语句所在的两个大括号之间(方法、循环、块，等等)。
__weak: 表示对象可以随时被摧毁。只有当它被其它对象强引用时才有用。__weak变量在摧毁时，被设为nil。
__unsafe_unretained: 与__weak类似，但在摧毁时，不设为nil，保留原值（不再指向有效的东西）。
__autoreleasing: 不要与autorelease搞混，它用于通过引用传递对象，比如，通过引用传递NSError对象: [myObject performOperationWithError:&tmp]。
注: 我们发现在ARC下，@property中使用“retain”时(而不是“strong”)，编译器并不会报错，而且能生成同样结果。但以后可能会变，所以还是用“strong”吧。
七、移植到ARC
Xcode 4.2提供了一个移植ARC的工具，还可以帮你将无法自动移植的代码手工转换过去。
- 打开不兼容ARC的工程，进入Edit > Refactor > Convert to Objective-C ARC。
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并且让大家离开使用手动的引用计数。
(来自:开源中国AlfredCheung、周荣冰的翻译)
