ARC切换及开发注意事项

ARC介绍

Automatic Reference Counting (ARC) 是一个编译期的技术，利用此技术可以简化Objective-C编程在内存管理方面的工作量。由开发人员来维护iOS对象的引用计数。不仅要求开发人员了解iOS的内存管理细节，更要求熟知并恪守计数管理规则。自动内存管理能够有效提高开发人员的工作效率，同时减少手动管理带来的人为错误(野指针和泄露往往难以定位并且影响严重)。

ARC : ■ Easier to learn ■ More productive ■ Easier to maintain ■ Safer and more stable

ARC切换常见问题

1、iOS版本兼容

ARC is supported in Xcode 4.2 for OS X v10.6 and v10.7 (64-bit applications) and for iOS 4 and iOS 5.Weak references are not supported in OS X v10.6 and iOS 4.

在iOS引入Weak references前，大多数项目会借助开源代码实现弱引用(如MAZeroingWeakRef)功能。同样借助开源项目 PLWeakCompatibility 我们可以在iOS4上使用Weak references。

PLWeakCompatibility is a set of stubs that implement the Objective-C runtime functions the compiler uses to make __weak work. It automatically calls throughto the real runtime functions if they're present (i.e. your app is running on iOS5+ or Mac OS X 10.7+) and uses its own implementation if they're not.By default, PLWeakCompatibility uses MAZeroingWeakRef to handle __weak if MAZeroingWeakRef is present. If not, it uses its own, less sophisticated, internal implementation.

2、第三方库对ARC的支持

项目往往会关联引用第三方库而这些项目并不全支持ARC。

• 不支持ARC的项目通过如下设置关闭ARC：Build Setting => Apple LLVM compiler 3.0-Code Generation => Objective-C automatic Reference Counting = NO
• 不支持ARC的源文件通过如下设置关闭ARC：Build Phases => Compile Sources => Compiler Flags = -fno-objc-arc

3、性能及稳定性

有别于.Net/Java的全自动的垃圾回收机制，本质上仍然手动内存管理方式。ARC在编译期间为每个Objective-C指针变量添加合适的retain, release, autorelease等函数，保存每个变量的生存周期控制在合理的范围内，以期实现代码上的自动内存管理。

项目切换ARC问题

1、工作量

由于项目一直处于快速迭代状态，没有剩余工作量可以投入切换工作，而且切换本身的工作量要高于前期的预估。虽然Xcode提供ARC自动转换工具，但实际使用差强人意。手动一次性切换工作量太大并且切换后不易回滚。由于切换ARC涉及部分底层逻辑的改动，切换完成后需要回归测试。

2、学习成本

项目开发人员习惯于非ARC下的开发，不了解ARC下的开发注意事项，可能影响开发效率及程序稳定性。需要学习了解ARC的原理以及使用注意事项。

3、项目发布

切换后要保证程序的完整性以及稳定性，保证项目的按时发布。这需要预留回归测试时间以及简易的回滚机制。

项目切换ARC操作

• 集成ARC-Safe Memory Management，在新增代码中使用新的内存管理调用(Makes your code both ARC and non-ARC compatible!)。
• 已有的代码则借助Xcode的替换工具，使用正则表达式进行匹配、替换。
• Objective-C and Core Foundation对象转换修改。
• 对不支持ARC的第三方库及文件关闭ARC功能。
• 全部替换完成后开启工程ARC，编译修复剩余问题。
• 修改存在自管理内存对象相关逻辑(ITTDataRequest)。
• 观察程序稳定性，测试修复存在的内存泄露以及循环引用。
• 逐步清除相关内存管理宏定义的调用。

在项目提测前完成ARC切换，开发结束后一并提测。安排测试员做回归和稳定性测试，保证测试充分。

ARC开发注意事项

• Forget about using retain, release, retainCount, and autorelease. 

• Forget about using NSAllocateObject and NSDeallocateObject.

• Follow the naming rule for methods related to object creation.

When an object is returned by certain methods, where the name begins with one of the list(alloc,new,copy,mutableCopy), the caller has ownership of the object. This rule is still applicable with ARC.

- (id) method __attribute((ns_returns_retained));      // return as retain +1, init,new,alloc,copy,mutablecopy default are this  - (id) method __attribute((ns_returns_not_retained));  // just return- (id) method __attribute((ns_returns_autoreleased));  // return as autorlease,  except default, are this 

- (void)initMethod __attribute__((objc_method_family(none))); 

• Forget about calling dealloc explicitly.

You can’t call [super dealloc] explicitly. It is just done automatically by ARC.

• Forget about using Zone (NSZone).
• Object type variables can’t be members of struct or union in C language. 
• ‘id’ and ‘void*’ have to be cast explicitly. 
• Use @autoreleasepool instead of NSAutoreleasePool. 

Toll-Free Bridge

• __bridge_transfer：用于将CF对象的管理权移至NSObject层由ARC负责。
• __bridge_retained：用于将一个NSObject对象转换成CF对象，并且引用计数加一。在CF层用完这个CF对象后，就需要使用CFRelease()释放该对象。
• __bridge：Just for assignment

to convert an object between Objective-C and Core FoundationCFTypeRef CFBridgingRetain(id X) {return (__bridge_retained CFTypeRef)X;}id CFBridgingRelease(CFTypeRef X) {return (__bridge_transfer id)X;}

所有权修饰符

PS：xib控件关联非最外层的View，使用weak属性声明。

详细的原理及技术细节可以查看：《Pro.Multithreading.and.Memory.Management.for.iOS.and.OS.X》