一、前言
项目简介
需要转换的Objective-C文件数量：1000个左右。
开发工具：Xcode 8.0.1
转换方式
我使用的是Xcode本身提供的ARC转换功能。当然你也可以手动手动转换，那不属于本文范畴，而且其工作量绝对能让你崩溃。
二、转换过程
代码备份
在进行如此大规模的更改之前，一定要先进行代码备份：直接在本地将代码复制一份，或者记住更改前代码在VCS上的版本号。
过滤无需转换的文件
找出项目中引用的仍使用手动内存管理的第三方库，或者某些你不希望转换的文件，对其添加-fno-objc-arc标记。
Xcode自动转换工具只针对Objective-C对象，只会处理Objective-C/Objective-C++即后缀名为.m/.mm的两种文件，因此其他的C/C++对应的.c/.cpp都无需理会。
执行检查操作
使用Xcode转换工具入口如图所示：
点击Convert to Objective-C ARC后会进入检查操作入口，如图：
该步骤要选择哪些文件需要转换，Xcode会自动帮你识别哪些文件需要转换，这里可以全选。
点击check按钮后Xcode会帮助我们检查代码中存在的不符合ARC使用规则的错误或警告，只有所有的错误都解决以后才能执行真正的转换操作。
解决错误/告警
执行完check操作后，会给出提示：
三百多个错误，同时还有一千两百多个警告信息，都要哭了。。。
错误和警告的解决内容较多，后面会单独介绍。
执行转换操作
解决完所有的error后，会弹出下述提示界面：
大意是Xcode将要将你的工程转换成使用ARC管理内存，所有更改的代码在真正更改之前会在一个review界面展示。同时所有的更改完成以后，Xcode会讲项目Target对应的工程设置的使用ARC设置（Objective-C Automatic Reference Counting）会被置成YES（上图右上角的警告标识就是在告诉我们项目已经支持ARC了，但工程中有文件还不支持）：
这时离成功就不远了，胜利在望！
点击next按钮后跳转到review界面，样式类似于使用Xcode提交SVN的确认提交界面，如下图所示：
该界面列出了所有需要有代码更改的文件，同时能够直接对比转换前和转换后的代码变化。为了稳妥起见，我选择了每个文件都点进去扫了一眼，这也给我们一次机会检查是否漏掉了不能转换的文件。确定一切无误以后，点击右下角的save按钮，一切就大功告成了！
错误/警告解决
错误
ARC forbids synthesizing a property of an Objective-C object with unspecified ownership or storage attribute
property属性必须指定一个内存管理关键字，在属性定义处增加strong关键字即可。
ARC forbids explicit message send of ‘release’
这种情况通常是使用包含release的宏定义，将该宏和使用该宏的地方删除即可。
Init methods must return a type related to the receiver type
错误原因是A类里的一个方法以init开头，而且返回的是B类型，好吧，乖乖改方法名。
Cast of C pointer type ‘ivPointer’ (aka ‘void ’) to Objective-C pointer type ‘iFlyTTSManager_old ’ requires a bridged cast
cast_pointer_objective-c
这是Toll-Free Bridging转换问题，在ARC下根据情况使用对应的转换关键字就行了，后文会专门介绍。
警告
解决警告的目的是消除警告处代码存在的隐患，既然Xcode给了提示，那么每一个警告信息都值得我们认真对待。
Capturing self in this block is likely to lead to a retain cycle
这是典型的block循环引用问题，将block中的self改成使用指向self的weak指针即可。
Using ‘initWithArray:’ with a literal is redundant
好吧，原来是没必要的alloc操作，直接按Xcode提示将alloc删除即可：
Init methods must return a type related to the receiver type
原来是A类里的一个方法以init开头，而且返回的是B类型，好吧，乖乖改方法名。
Property follows Cocoa naming convention for returning ‘owned’ objects
这是因为@property属性的命名以new开头了，可恶。。。修改方法是将对应的getter方法改成非new开头命名的：
ARC下方法名如果是以new/alloc/init等开头的，而且还不是类的初始化方法，就该小心了，要么报错，要么警告，原因你懂的。
Block implicitly retains ‘self’; explicitly mention ‘self’ to indicate this is intended behavior
意思是block中使用了self的实例变量_selectedModeMarkerView，因此block会隐式的retain住self。Xcode认为这可能会给开发者造成困惑，或者因此而因袭循环引用，所以警告我们要显示的在block中使用self，以达到block显示retain住self的目的。
该警告有两种改法： ①按照Xcode提示，改成self->_selectedModeMarkerView：
②直接将该警告关闭 警告名称为：Implicit retain of ‘self’ within blocks 对应的Clang关键字是：-Wimplicit-retain-self
Weak property may be unpredictably set to nil 和 Weak property ‘delegate’ is accessed multiple times in this method but may be unpredictably set to nil; assign to a strong variable to keep the object alive
这是工程中数目最多的警告，这是因为所有的delegate属性都是weak的，Xcode默认开启了下图中的两个警告设置，将其关闭即可：
Capturing ‘self’ strongly in this block is likely to lead to a retain cycle
这是明显的block导致循环引用内存泄露的情况，之前代码中坑啊！修改方案：
Method parameter of type ‘NSError __autoreleasing ’ with no explicit ownership
这种就不用说了，按警告中的提示添加__autoreleasing关键字即可。
以上列出的错误和警告只是数量较多的，还有很多其他就不在这里一一列举了。
另外，推荐 Mattt Thompson 大神关于Clang中几乎所有warning的名称和对应报错提示语的网站：http://fuckingclangwarnings.com/，以后解决warning类问题就简单多了！
Xcode自动转换
关键字转换
Xcode会自动将某些关键字自动转换成ARC的对应版本。
retain自动转成strong，如图：
assign关键字转成weak
修饰Objective-C对象或者id类型对象的assign关键字会被转成weak，如图：
但是修饰Int/bool等数值型变量的assign不会自动转换成weak，如图：
关键字删除
和手动内存管理相关的几个关键字，比如：release/retain/autorelease/super dealloc等会被删除；
dealloc方法中如果除了release/super dealloc语句外，如果别的代码，dealloc方法会保留,如图：
如果没有整个方法都会被删除：
关键字替换
在转换时block关键字会被自动替换成weak：
@autoreleasepool
NSAutoreleasePool不支持ARC，会被替换成@autoreleasepool：
关于被宏注释代码
使用宏定义的对象释放代码
宏定义如下所示：
|
1
2
|
#define RELEASE_SAFELY(__POINTER) { [(__POINTER) release]; (__POINTER) = nil; } |
在执行ARC转换检查操作时，Xcode会在使用该宏的地方报错：
将该宏和使用该宏的地方删除即可。
被宏注释掉的代码，Xcode在转换时是不会处理的，如图：
PS：这是相当坑的一点，因为你根本预料不到工程中使用了多少宏，注释掉了多少代码。当你执行完转换操作，以为就大功告成的时候，却在某天因为一个宏的开启遇到了一堆新的转ARC不彻底的问题。这种问题也没招，只能遇到一个改一个了。
ARC和block
不管是手动内存管理还是ARC，block循环引用导致的内存泄露都是一个令人头疼的问题。在MRC中，解决block循环引用只需要使用__block关键字，在ARC下解决与block的使用就略显复杂了：
__block关键字
block内修改外部定义变量
和手动内存管理一样，ARC如果在block中需要修改block之外定义的变量需要使用__block关键字修饰，比如：
|
1
2
3
4
|
__block NSString *name = @"foggry";self.expireCostLabel.completionBlock = ^(){ name = @"wangzz";}; |
上例中name变量需要在block中修改，因此必须使用__block关键字。
__block在MRC和ARC中的区别
在ARC下的block中使用__block关键字修饰的对象时，block会retain该对象；而在MRC下却不会retain。关于这点在官方文档Transitioning to ARC Release Notes中有详细的描述：
In manual reference counting mode, block id x; has the effect of not retaining x. In ARC mode, block id x; defaults to retaining x (just like all other values).
下面的代码不管在MRC还是ARC中myController对象都是有内存泄露的：
|
1
2
3
4
5
|
MyViewController *myController = [[MyViewController alloc] init…];// ...myController.completionHandler = ^(NSInteger result) { [myController dismissViewControllerAnimated:YES completion:nil];}; |
内存泄露问题在MRC中可以按如下方式更改：
|
1
2
3
4
5
|
MyViewController * __block myController = [[MyViewController alloc] init…];// ... myController.completionHandler = ^(NSInteger result) { [myController dismissViewControllerAnimated:YES completion:nil];}; |
然而在ARC中这么改就不行了。正如开始所说的那样，在ARC中myController.completionHandler的block会retainmyController对象，使得内存泄露问题仍然存在！！
在ARC中该问题有两种解决方案，第一种：
|
1
2
3
4
5
6
|
MyViewController * __block myController = [[MyViewController alloc] init…];// ... myController.completionHandler = ^(NSInteger result) { [myController dismissViewControllerAnimated:YES completion:nil]; myController = nil;}; |
该方法在block中使用完myController时，是它指向nil。没有strong类型的指针指向myController指向的对象时，对象会被释放掉。
第二种种解决方案，直接使用weak代替block关键字：
|
1
2
3
4
5
6
|
MyViewController *myController = [[MyViewController alloc] init…];// ... MyViewController * __weak weakMyViewController = myController;myController.completionHandler = ^(NSInteger result) { [weakMyViewController dismissViewControllerAnimated:YES completion:nil];}; |
该方法直接避免了对block对myController对象的retain。
存在循环引用关系
如果self直接或者间接的对block存在强引用，在block中又需要使用self关键字，此时self和block就存在循环引用的关系。此时必须使用__weak关键字定义一个指针指向self，在block中使用该指针来引用self：
|
1
2
3
4
|
MessageListController * __weak weakSelf = self;self.messageLogic.loadMoreBlock = ^(IcarMessage * theMessage) { [weakSelf.tableView setPullTableIsLoadingMore:YES];}; |
需要说明的是，尽管上例中weakSelf指针对self只是弱引用，但是self对block却是强引用，self的生命周期一定是长于block的，因此不用担心在block中使用weakSelf指针时，其指向的self会被释放掉。
不存在循环引用关系
下面的例子：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
MyViewController *myController = [[MyViewController alloc] init…];// ...MyViewController * __weak weakMyController = myController;myController.completionHandler = ^(NSInteger result) { MyViewController *strongMyController = weakMyController; if (strongMyController) { // ... [strongMyController dismissViewControllerAnimated:YES completion:nil]; // ... } else { // Probably nothing... }}; |
如前面所说，myController.completionHandler的block中不能直接使用myController对象，会造成内存泄露，因此需要先用一个weak的指针指向myController对象，然后在block中使用该weak指针。但是为了确保在block执行的时候myController对象没有被释放掉，就在block一开始的地方定义了一个临时的strong类型的指针strongMyController指向weak指针weakMyController，其实最终的结果就是block中对myController对象强引用了。在block执行完被销毁的时候，strongMyController指针变量会被销毁，其最终指向的myController对象因此也会被销毁。这样在使用一个对象的时候做就保证了该对象是存在的，使用完了再放弃该对象的所有权。
ARC和Toll-Free Bridging
MRC下的Toll-FreeBridging不涉及内存管理的转移，Objective-C（后文简称OC）和Core Foundation（后文简称CF）各自管理各自的内存,相互之间可以直接交换使用，比如：
|
1
2
|
NSLocale *gbNSLocale = [[NSLocale alloc] initWithLocaleIdentifier:@"en_GB"];CFLocaleRef gbCFLocale = (CFLocaleRef)gbNSLocale; |
而在ARC下,事情就会变得复杂一些。因为ARC能够管理OC对象的内存,却不能管理CF对象,CF对象依然需要我们手动管理内存。在CF和OC之间bridge对象的时候,问题就出现了,编译器不知道该如何处理这个同时有OC指针和CF指针指向的对象。这时候,需要使用__bridge, __bridge_retained, __bridge_transfer等修饰符来告诉编译器该如何去做。
__bridge
它告诉编译器仍然负责管理好在OC一端的引用计数的事情,开发者也继续负责管理好在CF一端的事情，比如：
|
1
2
3
4
|
CFStringRef cfString = CFStringCreateWithCString(kCFAllocatorDefault, "CFString", kCFStringEncodingUTF8);NSString *ocString = (__bridge NSString *)cfString;CFRelease(cfString);NSLog(@"%@",ocString); |
__bridge_retained 或 CFBridgingRetain
二者作用是一样的，只是用法不同。
告诉编译器需要retain对象,而开发者在CF一端负责释放。这样就算对象在OC一端被释放,只要开发者不释放CF一端的对象, 对象就不会被真的销毁。
|
1
2
3
4
5
6
|
NSArray *ocArray = [[NSArray alloc] initWithObjects:@"foggry", nil];CFArrayRef cfArray = (__bridge_retained CFArrayRef)ocArray;/** 使用cfArray **/CFRelease(cfArray); |
__bridge_transfer 或 CFBridgingRelease
二者作用也是一样的，只是用法不同。
该关键字告诉编译器bridge的同时,也转移了对象的所有权，比如：
|
1
2
3
4
|
CFStringRef cfString = CFStringCreateWithCString(kCFAllocatorDefault, "CFString", kCFStringEncodingUTF8);NSString *ocString = (__bridge_transfer NSString *)cfString;//CFRelease(cfString); //不再需要释放操作NSLog(@"%@",ocString); |
转换过程中大家只需要根据具体需求选用适当的关键字即可。
另外，在ARC中id和void *也不能直接相互转换了，必须通过Toll-FreeBridging使用适当的关键字修饰。
ARC和IBOutLet
对于IBOutLet属性应该用strong还是weak一直都有疑惑。关于这一点官方文档是这么介绍的：
From a practical perspective, in iOS and OS X outlets should be defined as declared properties. Outlets should generally be weak, except for those from File’s Owner to top-level objects in a nib >>>file (or, in iOS, a storyboard scene) which should be strong. Outlets that you create should therefore typically be weak.
那么长的一段英文想说的是：如果nib文件构建的view是直接被Controller引用的顶层view，对应的IBOutLet属性应该是strong；
如果view是顶层view上的一个子view，那么该view的属性应该是weak，因为顶层view被Controller使用strong属性引用了，而顶层view本身又持有该view；
如果Controller对某个view需要单独引用，或者Controller没有引用某个view的父view，那么其属性也应该是strong。
好吧，其实我能说如果你实在懒得区分什么时候用strong，什么时候用weak，那就将所以后的IBOutLet属性都设成strong吧！在Controller销毁的时候，对应的IBOutLet实例变量也会被销毁，strong指针会被置成nil，因此也不会有内存问题。
参考文档
Transitioning to ARC Release Notes