iOS项目转移到自动引用计数

这里主要参考了Apple官方文档：Transitioning to ARC Release Notes

在支持iOS5的Xcode4中，创建项目会看到这样的选项：

这是iOS5的新特性，自动对象引用计数。默认情况下是勾选的，当然你可以取消它，按照以前的方式手动释放对象内存。

自动引用计数（简称ARC）是一个编译时特性，用于Objective-C对象自动内存管理。你可能会联想到Java的自动垃圾回收（GC），但是如刚才提到的，它们有一个本质不同，ARC是一个编译时技术，你可以想像为，编译时将手动释放内存引用代码加入到你的代码中，并完成编译。从这点来看，实现原理类似Java的范型计数。

对于熟悉手动释放内存的开发者来说，设计开发庞大应用的时候，要验算每个使用过的对象是否被正确的释放了。有了ARC以后，开发者可更多的将注意力放在如何实现用户需求，而不是浪费在这样的系统需求上。不过，ARC是个新事物，学习它也需要成本，对于一些被项目压的喘不过气来的开发者，往往没有精力学习和评估怎样进行切换。希望我的文章能帮助他们。

上面这张图很形象的说明了手动释放内存和使用ARC特性的代码，可以看到ARC可让开发者编写更少的代码（不必写保持和释放对象的代码），因此花费的时间更少。

 

综述

再进一步说一下ARC的基本概念，它通过在编译时增加代码，让对象在不需要的时候释放，而不会存在更长时间。理论上，它和手动引用计数释放内存的效果时一样的，相当于为代码自动增加retain，release和autorelease方法的调用。

为了能在编译时生成正确的代码，ARC对代码中的方法有一些限制，后面会提到。另外，ARC引入了新的生命周期标识符，用于对象引用和属性的声明。

ARC在Xcode 4.2中得到支持，可支持Mac OSX 10.6和10.7，以及iOS4和iOS5。弱引用在Mac OSX 10.6和iOS4中不支持。

Xcode通过一个新的工具可自动将代码转换（比如删除retain和release调用）为ARC方式，并且帮助开发者借鉴不能自动转换的问题。该工具可转换项目中所有的文件，使之使用ARC，也可以选择转换指定的文件，让其他文件还使用手动引用计数。

 

ARC浏览

ARC替代了以前使用retain、release和autorelease的方式。ARC在编译时评估对象的生命周期并自动插入适当的方法调用。编译器也会生成适当的dealloc方法调用。总的来说，在使用ARC时，只有当使用方法名称约定的代码，是你需要使用手动引用计数的情况。

下面看示例，一个实现Person类的代码：

@interface Person : NSObject
@property (nonatomic, strong) NSString *firstName;
@property (nonatomic, strong) NSString *lastName;
@property (nonatomic, strong) NSNumber *yearOfBirth;
@property (nonatomic, strong) Person *spouse;
@end

@implementation Person
@synthesize firstName, lastName, yearOfBirth, spouse;
@end

 

这里strong属性，是ARC引入的新的生命周期修饰符。这里先不具体介绍它，后面再详细说明。

使用ARC，在contrived方法中创建Person实例的代码类似下面这样：

- (void)contrived {
    Person *aPerson = [[Person alloc] init];
    [aPerson setFirstName:@"William"];
    [aPerson setLastName:@"Dudney"];
    [aPerson:setYearOfBirth:[[NSNumber alloc] initWithInteger:2011]];
    NSLog(@”aPerson: %@”, aPerson);
｝ 

因为ARC接管了内存管理，因此Person和NSNumber实例都不会内存泄漏。

可以很安全的为Person类实现下面的方法：

- (void)takeLastNameFrom:(Person *)person {

    NSString *oldLastname = [self lastName];

    [self setLastName:[person lastName]];

    NSLog(@”Lastname changed from %@ to %@”, oldLastname, [self lastName]);

}

ARC确保NSLog语句执行前，oldLastName不会被释放掉。

ARC要求的新规则

下面说一下使用ARC要求的新规则：

• 不能显式调用dealloc，或者实现和调用retain，release，retainCount和autorelease，当然也不能使用比如@selector(retain)等形式。
  另外，如果你实现了dealloc方法，不可以用于释放实例变量，但是你可以在此对系统的对象执行setDelegate:nil操作，因为系统的类（或者其他代码）未使用ARC进行编译。
  ARC情况下自定义实现的dealloc方法 ，不可以调用[super dealloc]，这会引起编译错误。
  当然，你还可以继续使用CFRetain、CFRelease和其他core fundation对象相关的函数，因为它们没有通过ARC编译。 
• 不可以使用NSAllocateObject和NSDeallocateObject。
   你可以使用alloc创建对象，运行时会处理对象的dealloc。
• 你不可以在C结构体中使用对象指针。
  作为替代，需要创建Objective-C类来管理数据。 
• 不可以再随意的转换id和void ＊类型。
  //todo 
• 不能再使用NSAutoreleasePool对象。
  ARC提供了@autoreleasepool块代替它。这比使用NSAutoreleasePool更有效。 
• 不能再使用内存区。
  不再需要在任何情况下使用NSZone，它将被新的Objective-C运行时忽略。
• ARC为了能和以前手动保持和释放内存的代码兼容，在方法和变量命名上做了限制，即不能让属性的名称前缀是new。

ARC引入的新的生命周期修饰符

这里要提前说两个概念，弱引用（weak reference）和归零弱引用（zeroing weak reference）。

这两个概念，本文参考了：Zeroing Weak References in Objective-C

什么是弱引用，看下面例子：

    – (void)setFoo: (id)newFoo
    {
        _foo = newFoo;
    }

这里_foo引用了newFoo，但是没有做retain，因此没有参与引用实例的生命周期。如果其他地方release造成该对象dealloc， _foo指向的对象将不可用。那会发生什么呢？我想很多程序员都碰到过这类情况，应用往往会崩溃（闪退）。

Cocoa框架中使用deletate引用的对象，几乎总是采用弱引用，就是利用了弱引用的这个特点。

什么是归零弱引用，刚才提到弱引用，一不小心，应用就崩溃了。归零弱引用在前者基础上，增加了保护措施，一旦引用对象被销毁，它会自动返回nil。这个特性在Mac OS X开发中已经使用：

__weak id _foo;

但是它需要GC支持，这个特性在iOS开发中不可用。

现在，iOS5推出的ARC特性，不但包含了对弱引用的支持，甚至可以替代GC特性在Mac OS X开发的作用。

有关属性值关键字，ARC引入了strong和weak关键字。

强引用：

@property(strong) MyClass *myObject; //你可以看作加了retain操作

弱引用：

@property(weak) MyClass *myObject; //和以前@property(assign) MyClass *myObj语法是类似的，但对象销毁自动返回nil

有关变量的标识符，如下：

• __strong，默认值
• __weak，标识对象是归零弱引用
• __unsafe_unretained，标识对象是弱引用
• __autoreleasing，标识对象在return时自动释放

在这里，__weak要小心使用，比如：

这样使用__weak，在后面的打印语句执行的时候将是null，因为弱引用不保持对象，这句话执行后对象就被释放了。

好在如上面截图所示，Xcode会给出警告作为提示。

另外，需要注意局部变量和方法参数修饰符的匹配。比如，有这样的方法：

-(BOOL)performOperationWithError:(NSError * __autoreleasing *)error;

然后这样使用该方法：

NSError *error = nil;

BOOL OK = [myObject performOperationWithError:&error];
if (!OK) {

这里的NSError *error = nil，会被自动编译为：

NSError * __strong e = nil;

那么，ARC为了匹配局部变量和方法参数，会产生中间临时变量：

NSError __strong *error = nil;
NSError __autoreleasing *tmp = error;
BOOL OK = [myObject performOperationWithError:&tmp];
error = tmp;
if (!OK) {

解决办法是，要么把局部变量设置为__autorelease，要么把方法参数设置为__strong。

 

使用生命周期修饰符，避免强引用循环

这里先说下，什么是强引用循环。比如A对象在属性中retain了B对象，而B对象在属性中也retain了A对象，那么它们之间存在了强引用循环。当然在实际开发中，可能这个循环更大，可能是多于2个对象产生了这种循环，变得更加难以察觉。

使用生命周期修饰符，可避免这种情况。比如，开发中常碰到的父子结构的对象关系。要求它们之间相关引用。那么可以让父对象强引用（__strong）子对象，子对象归零弱引用（__weak）父对象。

当然事情可能没那么简单，比如开发中使用了块对象。在手工引用计数模式下：

__block id x;

效果相当于没有保持x在内存中。

在ARC模式下，该语句，默认是保持的。如果还是想在ARC模式下实现手动引用的效果，则需要改为：

 __unsafe_unretained __block id x;

不过，这种弱引用，将造成危险（因为可能会造成危险），因此不建议使用。

那么怎么办呢？你有两种选择：

1. 使用__weak标识符替代__block标识符，缺点是不支持iOS4和Mac OS X 10.6
2. 不改变__block标识符，在块中使用完该变量后，设置变量为nil，这样就不会循环保持了

 

ARC提供了新的语句管理自动释放池

使用ARC后，就不能再直接使用NSAutoReleasePool类了。ARC引入了新的语法和语句：

@autoreleasepool {
     // Code, such as a loop that creates a large number of temporary objects.
}

编译器根据这个结构，检查语法块中对象引用计数的状态。

进入语法块的时候，自动释放池会压栈，正常退出时，比如运行到块外，则会弹栈。不过，为了兼容已存在代码，如果退出时有异常，则不弹栈。

这个语法可用于各种Objective-C模式。这比以前使用NSAutoReleasePool类更有效，建议替代使用。

 

管理Outlet的方式可以在Mac和iOS下一致了

这个方式就是：

• outlet都应该是week的
• 除了nib文件中文件所有者到顶级对象的那些顶级对象，它们应该用strong

 

局部变量都会被初始化为nil

使用ARC后，不论使用哪个修饰符，strong，weak还是其他的，都会被隐含的初始化为nil：

- (void)myMethod {
    NSString *name;
    NSLog(@”name: %@”, name);
}

无论是否变换修饰符，目前默认是strong，打印的结果都是nil。

 

使用编译器标志启用和禁用ARC

可通过新的标志-fobjc-arc启用ARC。还可以指定单个文件使用ARC。比如你可以指定项目使用ARC，然后再禁用某几个文件的这个标志。

ARC只在Xcode4.2被支持，4.1不支持ARC。ARC支持Mac OS X 10.6和10.7，也支持iOS4和iOS5。不过，Mac OS X 10.6和iOS4不支持弱引用。

 

在ARC模式下使用Core Function风格的类

比如，CFArrayRef，或者某些使用Core Function约定的框架，比如Core Graphic中的CGColorSpaceRef等。

编译器无法自动管理这些对象的生命周期。你必须调用比如CFRetain和CFRelease这样的方法管理它们。

如果你想在Objective-C和Core Foundation风格的对象间转型，需要告知编译器该对象的所有者。

有两种办法：

1. 如果喜欢函数调用，可以使用类似CFBridgingRetain这样的宏
2. 如果喜欢C风格的转型，可直接做转型

 

编译器对Cocoa方法返回的CF对象的处理

编译器可通过Core Foundation方式的命名规则理解这些，对Objective-C返回的CF对象做正确的处理。

 

使用所有者关键字转型函数的参数

如果要在函数调用中转型Objective-C和CF对象，你需要告诉编译器传递的对象的所有者关系。

CF对象和Objective-C对象都有自己定义的所有者关系规则，可见：

• Memory Management Programming Guide for Core Foundation
• Advanced Memory Management Programming Guide