ARC

最新推荐文章于 2024-12-23 10:25:25 发布

andyddd

最新推荐文章于 2024-12-23 10:25:25 发布

阅读量2.3k

点赞数

分类专栏： iOS

iOS 专栏收录该内容

13 篇文章

订阅专栏

很优秀的文章，因原文被墙，所以转帖过来，原文地址：http://www.yifeiyang.net/development-of-the-iphone-simply-1/

ARC是什么

变化点使用ARC的好处不好的地方

ARC基本规则

Objective-C对象引用关键字

总结

iPhone开发之深入浅出 (1) — ARC是什么

新年伊始，万象更新。新一年开始，我们来更加深入了解一下iPhone开发的内部。作为开始，我们先来了解一下ARC。

ARC是什么

ARC是iOS 5推出的新功能，全称叫 ARC(Automatic Reference Counting)。简单地说，就是代码中自动加入了retain/release，原先需要手动添加的用来处理内存管理的引用计数的代码可以自动地由编译器完成了。

该机能在 iOS 5/ Mac OS X 10.7 开始导入，利用 Xcode4.2 可以使用该机能。简单地理解ARC，就是通过指定的语法，让编译器(LLVM 3.0)在编译代码时，自动生成实例的引用计数管理部分代码。有一点，ARC并不是GC，它只是一种代码静态分析（Static Analyzer）工具。

变化点

通过一小段代码，我们看看使用ARC前后的变化点。

@interface NonARCObject : NSObject {
    NSString *name;
}
-(id)initWithName:(NSString *)name;
@end

@implementation NonARCObject
-(id)initWithName:(NSString *)newName {
    self = [super init];
    if (self) {
        name = [newName retain];
    }
    return self;
}

-(void)dealloc {
    [name release];
    [Super dealloc];
}
@end

@interface ARCObject : NSObject {
    NSString *name;
}
-(id)initWithName:(NSString *)name;
@end

@implementation ARCObject
-(id)initWithName:(NSString *)newName {
    self = [super init];
    if (self) {
        name = newName;
    }
    return self;
}
@end

我们之前使用Objective-C中内存管理规则时，往往采用下面的准则

生成对象时，使用autorelease
对象代入时，先autorelease后再retain
对象在函数中返回时，使用return [[object retain] autorelease];

而使用ARC后，我们可以不需要这样做了，甚至连最基础的release都不需要了。

使用ARC的好处

使用ARC有什么好处呢？

看到上面的例子，大家就知道了，以后写Objective-C的代码变得简单多了，因为我们不需要担心烦人的内存管理，担心内存泄露了
代码的总量变少了，看上去清爽了不少，也节省了劳动力
代码高速化，由于使用编译器管理引用计数，减少了低效代码的可能性

不好的地方

记住一堆新的ARC规则 — 关键字及特性等需要一定的学习周期
一些旧的代码，第三方代码使用的时候比较麻烦；修改代码需要工数，要么修改编译开关

关于第二点，由于 XCode4.2 中缺省ARC就是 ON 的状态，所以编译旧代码的时候往往有"Automatic Reference Counting Issue"的错误信息。

这个时候，可以将项目编译设置中的“Objectice-C Auto Reference Counteting”设为NO。如下所示。

如果只想对某个.m文件不适应ARC，可以只针对该类文件加上 -fno-objc-arc 编译FLAGS，如下图。

ARC基本规则

retain, release, autorelease, dealloc由编译器自动插入，不能在代码中调用
dealloc虽然可以被重载，但是不能调用[super dealloc]

由于ARC并不是GC，并需要一些规则让编译器支持代码插入，所以必须清楚清楚了这些规则后，才能写出健壮的代码。

Objective-C对象

ObjectiveC中的对象，有强参照(Strong reference)和弱参照(Weak reference)之分，当需要保持其他对象的时候，需要retain以确保对象引用计数加1。对象的持有者(owner)只要存在，那么该对象的强参照就一直存在。

对象处理的基本规则是

只要对象的持有者存在（对象被强参照），那么就可以使用该对象
对象失去了持有者后，即被破弃

强参照 (Strong reference)

(s1)

firstName作为”natsu”字符串对象的最初持有者，是该NSString类型对象的Strong reference。

(s2)

这里将firstName代入到aName中，即aName也成为了@”natsu”字符串对象的持有者，对于该对象，aName也是Strong reference。

(s3)

这里，改变firstName的内容。生成新的字符串对象”maki”。这时候firstName成为”maki”的持有者，而@”natsu”的持有者只有aName。每个字符串对象都有各自的持有者，所以它们都在内存中都存在。

(s4)

追加新的变量otherName, 它将成为@”maki”对象的另一个持有者。即NSString类型对象的Strong reference。

(s5)

将otherName代入到aName，这时，aName将成为@”maki”字符串对象的持有者。而对象@”natsu”已经没有持有者了，该对象将被破弃。

弱参照 (Weak reference)

接下来我们来看看弱参照 (Weak reference) 的使用方式。

(w1)

与强参照方式同样，firstName作为字符串对象@”natsu”的持有者存在。即是该NSString类型对象的Strong reference。

(w2)

使用关键字__weak，声明弱参照weakName变量，将firstName代入。这时weakName虽然参照@”natsu”，但仍是Weak reference。即weakName虽然能看到@”natsu”，但不是其持有者。

(w3)

firstName指向了新的对象@”maki”，成为其持有者，而对象@”natsu”因为没有了持有者，即被破弃。同时weakName变量将被自动代入nil。

引用关键字

ARC中关于对象的引用参照，主要有下面几关键字。使用strong, weak, autoreleasing限定的变量会被隐式初始化为nil。

__strong

变量声明缺省都带有__strong关键字，如果变量什么关键字都不写，那么缺省就是强参照。

__weak

上面已经看到了，这是弱参照的关键字。该概念是新特性，从 iOS 5/ Mac OS X 10.7 开始导入。由于该类型不影响对象的生命周期，所以如果对象之前就没有持有者，那么会出现刚创建就被破弃的问题，比如下面的代码。

1 2	NSString __weak *string = [[NSString alloc] initWithFormat:@"First Name: %@", [self firstName]]; NSLog(@"string: %@", string); //此时 string为空

如果编译设定OS版本 Deployment Target 设定为这比这低的版本，那么编译时将报错(The current deployment target does not support automated __weak references)，这个时候，我们可以使用下面的__unsafe_unretained。

弱参照还有一个特征，即当参数对象失去所有者之后，变量会被自动付上nil (Zeroing)。

__unsafe_unretained

该关键字与__weak一样，也是弱参照，与__weak的区别只是是否执行nil赋值(Zeroing)。但是这样，需要注意变量所指的对象已经被破弃了，地址还还存在，但内存中对象已经没有了。如果还是访问该对象，将引起「BAD_ACCESS」错误。

__autoreleasing

该关键字使对像延迟释放。比如你想传一个未初始化的对像引用到一个方法当中，在此方法中实例化此对像，那么这种情况可以使用__autoreleasing。他被经常用于函数有值参数返回时的处理，比如下面的例子。

- (void) generateErrorInVariable:(__autoreleasing NSError **)paramError {
    ....
    *paramError = [[NSError alloc] initWithDomain:@"MyApp" code:1 userInfo:errorDictionary];
}

....
{
    NSError *error = nil;
    [self generateErrorInVariable:&error];
    NSLog(@"Error = %@", error);
}

又如函数的返回值是在函数中申请的，那么希望释放是在调用端时，往往有下面的代码。

-(NSString *)stringTest
{
    NSString *retStr = [NSString stringWithString:@"test"];

    return [[retStr retain] autorelease];
}

// 使用ARC

-(NSString *)stringTest
{
    __autoreleasing NSString *retStr = [NSString alloc] initWithString:@"test"];

    return retStr;
}

即当方法的参数是id*，且希望方法返回时对象被autoreleased，那么使用该关键字。

总结

今天，我们看到了基本的ARC使用规则

代码中不能使用retain, release, retain, autorelease
不重载dealloc（如果是释放对象内存以外的处理，是可以重载该函数的，但是不能调用[super dealloc]）
不能使用NSAllocateObject, NSDeallocateObject
不能在C结构体中使用对象指针
id与void *间的如果cast时需要用特定的方法（__bridge关键字）
不能使用NSAutoReleasePool、而需要@autoreleasepool块
不能使用“new”开始的属性名称（如果使用会有下面的编译错误”Property’s synthesized getter follows Cocoa naming convention for returning ‘owned’ objects”）

今后，我们将更加深入ARC，学习其更多的特性。

4一/12 4

iPhone开发之深入浅出 (2) — ARC之@property使用

博主：易飞扬
原文链接 : http://www.yifeiyang.net/development-of-the-iphone-simply-2/
转载请保留上面文字。

所有者属性读写相关的属性 (readwrite, readonly)

iPhone开发之深入浅出 (2) — ARC之@property使用

上一回我们学到了一些ARC的基本概念，这一次我们来看看ARC对@property的使用规则有何影响。

所有者属性

我们先来看看与所有权有关系的属性，关键字间的对应关系。

属性值	关键字	所有权
strong	__strong	有
weak	__weak	无
unsafe_unretained	__unsafe_unretained	无
copy	__strong	有
assign	__unsafe_unretained	无
retain	__strong	有

strong

该属性值对应 __strong 关键字，即该属性所声明的变量将成为对象的持有者。

weak

该属性对应 __weak 关键字，与 __weak 定义的变量一致，该属性所声明的变量将没有对象的所有权，并且当对象被破弃之后，对象将被自动赋值nil。

并且，delegate 和 Outlet 应该用 weak 属性来声明。同时，如上一回介绍的 iOS 5 之前的版本是没有 __weak 关键字的，所以 weak 属性是不能使用的。这种情况我们使用 unsafe_unretained。

unsafe_unretained

等效于__unsafe_unretaind关键字声明的变量；像上面说明的，iOS 5之前的系统用该属性代替 weak 来使用。

copy

与 strong 的区别是声明变量是拷贝对象的持有者。

assign

一般Scalar Varible用该属性声明，比如,int, BOOL。

retain

该属性与 strong 一致；只是可读性更强一些。

读写相关的属性 (readwrite, readonly)

读写相关的属性有 readwrite 和 readonly 两种，如果使用ARC之后，我么需要注意一下 readonly 属性的使用。

比如下面的变量声明。

1	@property (nonatomic, readonly) NSString *name;

一般声明为 readonly 的变量按理说应该不需要持有所有权了，但是在ARC有效的情况下，将出现下面的错误信息：

“ARC forbids synthesizing a property of an Objective-C object with unspecified ownership or storage attribute”

如果定义了ARC有效，那么必须要有所有者属性的定义；所以我们的代码改成这样，就OK了

1	@property (nonatomic, strong, readonly) NSString *name;

不过有一点，Scalar Varible的变量缺省都有 assign 的属性定义，所以不需要给他们单独的明示声明了。

19二/12 5

方法	动作
alloc/new/copy/mutableCopy	生成对象并拥有所有权
retain	拥有对象所有权
release	释放对象所有权
dealloc	释放对象资源

iPhone开发之深入浅出 (4) — ARC之循环参照

博主：易飞扬
原文链接 : http://www.yifeiyang.net/development-of-the-iphone-simply-4/

转载请保留上面文字。

概念解决方式

Delegate模式 Blocks

iPhone开发之深入浅出 (4) — ARC之循环参照

概念

当我们使用强参照（Strong reference）时，往往需要留意循环参照的问题。循环参照指的是两个对象被互相强参照，以至于任一对象都不能释放。

一般情况下，当对象之间有“父子关系”时，强参照的情况发生的比较多。比如通讯薄对象AddrBook和每个通讯录Entry的关系如下。

这种情况下，由于Entry对象被AddrBook强参照，所以不能释放。另一方面，如果Entry被释放了，AddrBook对象的强参照也就没有了，其对象也应被释放。

解决方式

像上面的例子，当多个对象间有“父子关系”时，需要在一侧用“弱参照”来解决循环参照问题。一般情况下，“父亲”作为“孩子”的拥有者，对“孩子”是强参照，而“孩子”对父亲是弱参照。

如图所示，当强参照AddrBook对象的变量被释放的时候，AddrBook对象将被自动释放，同时将失去Entry成员对象的强参照。另外，当AddrBook对象被释放的时候，Entry对象中的AddrBook变量也将由Zeroing机制，自动带入nil。我们不需要担心释放对象的再访问问题。

下面，我们将看看有几种情况下，需要注意循环参照问题。

Delegate模式

iOS程序中经常用到delegate模式，比如ViewController中，用ModalView打开/关闭DetailViewController时，需要delegate的设定。

这里，ViewController对象中强参照detailViewController，如果DetailViewController的delegate不是弱参照ViewController话，将引起循环参照。

另外，当类中使用weak @property声明的delegate变量时，如果参照对象被释放，该变量将被自动设为nil，不需要程序代码设置。

Blocks

Blocks是iOS 4开始导入的，可以理解为python或者lisp中的Lambda，C++11也已导入了该概念；类似概念ruby/smalltalk/JSP语言中也有定义。具体讲解见以后的文章，本节我们主要看看在Block中的循环参照问题。

比如，block对象用copy的属性定义时候，

typedef void(^MyBlock)(void);

@interface MyObject : NSObject
@property (nonatomic, copy) MyBlock block;
@property (nonatomic, strong) NSString *str;

- (void)performBlock;
@end

@implementation MyObject
@synthesize block, str;

- (void)performBlock {
    if (self.block) {
        self.block();
    }
}
@end

调用端如下：

MyObject *object = [[MyObject alloc] init];
object.str = @"hoge";

object.block = ^{
    NSLog(@"block: str=%@", object.str);
};
[object performBlock];

我们看到，Block的构文中参照了object，同样object也强参照block。

为了解决该问题，我们可以有下面两种选择。

使用__block关键字修饰

使用__block关键字，让对象有读写权限，如果Block内的处理完毕就释放object。

__block MyObject *object = [[MyObject alloc] init];
object.str = @"hoge";

object.block = ^{
    NSLog(@"block: str=%@", object.str);
    object = nil;
};
[object performBlock];

该关键字的意思就是让block取消对object的强参照，以避免循环参照。但是，有一个问题就是，object的释放动作是在Block内部执行，如果Block没有被执行的话，循环参照一直存在。比如上面的代码，如果第8行 [object performBlock]; 没有执行的话，那么一直还是循环参照状态。

使用__weak关键字修饰

另一种方案就是让Block的参照变为弱参照。

MyObject *object = [[MyObject alloc] init];
object.str = @"hoge";

__weak MyObject *weakObject = object;
object.block = ^{
    NSLog(@"block: str=%@", weakObject.str);
};
[object performBlock];

考虑到异步通信时Blocks的使用情况，weak变量weakObject有可能随时变为nil，所以类似于下面先变为strong变量，并检查是否为nil的处理方式应该更安全。

MyObject *object = [[MyObject alloc] init];
object.str = @"hoge";

__weak MyObject *weakObject = object;
object.block = ^{
    MyObject strongObject = weakObject;
    if (strongObject) {
        NSLog(@"block: str=%@", strongObject.str);
    }
};
[object performBlock];

总上，当我们使用Blocks时，也需要考虑Block中变量和实例的关系，不要引起不必要的循环参照问题。

8三/12 0

iPhone开发之深入浅出 (5) — ARC之Outlet与弱引用

博主：易飞扬
原文链接 : http://www.yifeiyang.net/development-of-the-iphone-simply-5/
转载请保留上面文字。

使用weak property声明Outlet

简化viewDidUnload 什么时候要用strong property

iPhone开发之深入浅出 (5) — ARC之Outlet与弱引用

使用weak property声明Outlet

当我们使用 Interface Builder 生成Outlet对象的时候，一般都是作为 subview 来使用的。比如 UIViewController 的view。所以说Outlet的持有者就是superview对象，即有“父子”关系。由上一回 iPhone开发之深入浅出 (4) — ARC之循环参照我们知道，当对象间有“父子”关系时，需要使用弱参照，以避免“循环参照”。

ViewController 本身是不会作为Outlet的所有者的，所以使用weak property声明。

简化viewDidUnload

Outlet都使用weak property声明的时候，还有一个好处，就是简化viewDidUnload的处理。

iOS在系统内存不足的时候，UIViewController会将没有表示的所有view做unload处理，即调用viewDidUnload接口。

所以，如果是强参照的情况下，需要释放所有权，
1

@property (nonatomic, strong) IBOutlet UILabel *label;
1 2 3 4

(void)viewDidUnload { self.label = nil; // 取消强参照，释放所有权 [super viewDidUnload]; }
如果没有 self.label = nil 的处理，那么 UIViewController 将不会释放 label 的所有权；结果，系统是调用了unload，但是subview对象始终留在内存中。随着界面上控件的增多，内存泄露会越来越大。

如果使用的是weak property声明的话，会是怎样的呢？
1

@property (nonatomic, weak) IBOutlet UILabel *label;
这时，系统在unload时，由于label没有被强参照，更加ARC的规则，这时，label的对象即被释放。并在释放的同时，变量自动指向nil。
1 2 3 4

- (void)viewDidUnload { // 这里什么也不用管 [super viewDidUnload]; }
其实，如果我们的viewDidUnload只是用来释放Outlet用的话，那么该函数也可以不被重载的。

什么时候要用strong property

由上我们也可以看到，并不是所有的Outlet都用弱参照来声明都是正确的；当使用Interface Builder生成的第一层的view或
者windows被作为Outlet来使用的话，那么不是不能声明为弱参照property的。（比如，Storyboard的各个scene）

理由很简单，没有被任何人强参照的对象，生成之后就会立刻被释放。

综上，当我们使用Outlet的时候，注意不同的情况来使用strong或者是weak。

24三/12 1

iPhone开发之深入浅出 (6) — ARC之对象转型
博主：易飞扬
原文链接 : http://www.yifeiyang.net/development-of-the-iphone-simply-6/

转载请保留上面文字。

引子 __bridge

__bridge_retained __bridge_transfer

Toll-Free bridged 总结

iPhone开发之深入浅出 (6) — ARC之对象转型

自 Xcode4.2 开始导入ARC机制后，为了支持对象间的转型，Apple又增加了许多转型用的关键字。这一讲我们就来了解其用法，以及产生的理由。

引子

我们先来看一下ARC无效的时候，我们写id类型转void*类型的写法：

1 2	id obj = [[NSObject alloc] init]; void *p = obj;

反过来，当把void*对象变回id类型时，只是简单地如下来写，

1 2	id obj = p; [obj release];

但是上面的代码在ARC有效时，就有了下面的错误：

    error: implicit conversion of an Objective-C pointer
        to ’void *’ is disallowed with ARC
        void *p = obj;
                  ^

    error: implicit conversion of a non-Objective-C pointer
        type ’void *’ to ’id’ is disallowed with ARC
        id o = p;
                ^

__bridge

为了解决这一问题，我们使用 __bridge 关键字来实现id类型与void*类型的相互转换。看下面的例子。

id obj = [[NSObject alloc] init];

void *p = (__bridge void *)obj;

id o = (__bridge id)p;

将Objective-C的对象类型用 __bridge 转换为 void* 类型和使用 __unsafe_unretained 关键字修饰的变量是一样的。被代入对象的所有者需要明确对象生命周期的管理，不要出现异常访问的问题。

除过 __bridge 以外，还有两个 __bridge 相关的类型转换关键字：

__bridge_retained
__bridge_transfer

接下来，我们将看看这两个关键字的区别。

__bridge_retained

先来看使用 __bridge_retained 关键字的例子程序：

1
2
3

id obj = [[NSObject alloc] init];

void *p = (__bridge_retained void *)obj;

从名字上我们应该能理解其意义：类型被转换时，其对象的所有权也将被变换后变量所持有。如果不是ARC代码，类似下面的实现：

id obj = [[NSObject alloc] init];

void *p = obj;
[(id)p retain];

可以用一个实际的例子验证，对象所有权是否被持有。

void *p = 0;

{
    id obj = [[NSObject alloc] init];
    p = (__bridge_retained void *)obj;
}

NSLog(@"class=%@", [(__bridge id)p class]);

出了大括号的范围后，p 仍然指向一个有效的实体。说明他拥有该对象的所有权，该对象没有因为出其定义范围而被销毁。

__bridge_transfer

相反，当想把本来拥有对象所有权的变量，在类型转换后，让其释放原先所有权的时候，需要使用 __bridge_transfer 关键字。文字有点绕口，我们还是来看一段代码吧。

如果ARC无效的时候，我们可能需要写下面的代码。

// p 变量原先持有对象的所有权
id obj = (id)p;
[obj retain];
[(id)p release];

那么ARC有效后，我们可以用下面的代码来替换：

1 2	// p 变量原先持有对象的所有权 id obj = (__bridge_transfer id)p;

可以看出来，__bridge_retained 是编译器替我们做了 retain 操作，而 __bridge_transfer 是替我们做了 release¹。

Toll-Free bridged

在iOS世界，主要有两种对象：Objective-C 对象和 Core Foundation 对象0。Core Foundation 对象主要是有C语言实现的 Core Foundation Framework 的对象，其中也有对象引用计数的概念，只是不是 Cocoa Framework::Foundation Framework 的 retain/release，而是自身的 CFRetain/CFRelease 接口。

这两种对象间可以互相转换和操作，不使用ARC的时候，单纯的用C原因的类型转换，不需要消耗CPU的资源，所以叫做 Toll-Free bridged。比如 NSArray和CFArrayRef, NSString和CFStringRef，他们虽然属于不同的 Framework，但是具有相同的对象结构，所以可以用标准C的类型转换。

比如不使用ARC时，我们用下面的代码：

1 2	NSString *string = [NSString stringWithFormat:...]; CFStringRef cfString = (CFStringRef)string;

同样，Core Foundation类型向Objective-C类型转换时，也是简单地用标准C的类型转换即可。

但是在ARC有效的情况下，将出现类似下面的编译错误：

    Cast of Objective-C pointer type ‘NSString *’ to C pointer type ‘CFStringRef’ (aka ‘const struct __CFString *’) requires a bridged cast
    Use __bridge to convert directly (no change in ownership)
    Use __bridge_retained to make an ARC object available as a +1 ‘CFStringRef’ (aka ‘const struct __CFString *’)

错误中已经提示了我们需要怎样做：用 __bridge 或者 __bridge_retained 来转型，其差别就是变更对象的所有权。

正因为Objective-C是ARC管理的对象，而Core Foundation不是ARC管理的对象，所以才要特意这样转换，这与id类型向void*转换是一个概念。也就是说，当这两种类型（有ARC管理，没有ARC管理）在转换时，需要告诉编译器怎样处理对象的所有权。

上面的例子，使用 __bridge/__bridge_retained 后的代码如下：

__bridge

1 2	NSString *string = [NSString stringWithFormat:...]; CFStringRef cfString = (__bridge CFStringRef)string;

只是单纯地执行了类型转换，没有进行所有权的转移，也就是说，当string对象被释放的时候，cfString也不能被使用了。

__bridge_retained

NSString *string = [NSString stringWithFormat:...];
CFStringRef cfString = (__bridge_retained CFStringRef)string;
...
CFRelease(cfString); // 由于Core Foundation的对象不属于ARC的管理范畴，所以需要自己release

使用 __bridge_retained 可以通过转换目标处（cfString）的 retain 处理，来使所有权转移。即使 string 变量被释放，cfString 还是可以使用具体的对象。只是有一点，由于Core Foundation的对象不属于ARC的管理范畴，所以需要自己release。

实际上，Core Foundation 内部，为了实现Core Foundation对象类型与Objective-C对象类型的相互转换，提供了下面的函数。

CFTypeRef  CFBridgingRetain(id  X)  {
    return  (__bridge_retained  CFTypeRef)X;
}

id  CFBridgingRelease(CFTypeRef  X)  {
    return  (__bridge_transfer  id)X;
}

所以，可以用 CFBridgingRetain 替代 __bridge_retained 关键字：

NSString *string = [NSString stringWithFormat:...];
CFStringRef cfString = CFBridgingRetain(string);
...
CFRelease(cfString); // 由于Core Foundation不在ARC管理范围内，所以需要主动release。

__bridge_transfer

所有权被转移的同时，被转换变量将失去对象的所有权。当Core Foundation对象类型向Objective-C对象类型转换的时候，会经常用到 __bridge_transfer 关键字。

CFStringRef cfString = CFStringCreate...();
NSString *string = (__bridge_transfer NSString *)cfString;

// CFRelease(cfString); 因为已经用 __bridge_transfer 转移了对象的所有权，所以不需要调用 release

同样，我们可以使用 CFBridgingRelease() 来代替 __bridge_transfer 关键字。

1 2	CFStringRef cfString = CFStringCreate...(); NSString *string = CFBridgingRelease(cfString);

总结

由上面的学习我们了解到 ARC 中类型转换的用法，那么我们实际使用中按照怎样的原则或者方法来区分使用呢，下面我总结了几点关键要素。

明确被转换类型是否是 ARC 管理的对象
- Core Foundation 对象类型不在 ARC 管理范畴内
- Cocoa Framework::Foundation 对象类型（即一般使用到的Objectie-C对象类型）在 ARC 的管理范畴内
如果不在 ARC 管理范畴内的对象，那么要清楚 release 的责任应该是谁
各种对象的生命周期是怎样的

1. 声明 id obj 的时候，其实是缺省的申明了一个 __strong 修饰的变量，所以编译器自动地加入了 retain 的处理，所以说 __bridge_transfer 关键字只为我们做了 release 处理。

28三/12 3

iPhone开发之深入浅出 (7) — ARC总结

博主：易飞扬
原文链接 : http://www.yifeiyang.net/development-of-the-iphone-simply-7/

转载请保留上面文字。

内存管理基本原则所有权关键字 ARC使用准则

不能使用 retain/release/retainCount/autorelease 不能使用 NSAllocateObject/NSDeallocateObject 不能使用 NSZone 不能明示调用dealloc 内存管理相关的函数必须遵循命名规则使用@autoreleasepool代替NSAutoreleasePool Objective-C 对象不能作为C语言结构体（struct/union）的成员【id】与【void*】之间需要明示cast

题外话

Xcode 4.3带来的变化 ARC 代码自动变换为什么iOS中没有GC

iPhone开发之深入浅出 (7) — ARC总结

通过前面几篇文章的介绍，我想大家应该对ARC有了一个比较完整的理解。最后，我们来对ARC做一个总结，并把一些未涉及到的细节部分再深入讨论一下。

内存管理基本原则

内存管理的依循下面的基本原则

自己生成的对象，那么既是其持有者
不是自己生成的对象，也可成为其持有者（一个对象可以被多个人持有）
如果不想持有对象的时候，必须释放其所有权
不能释放已不再持有所有权的对象
不管ARC有没有效，该原则始终存在。

所有权关键字

从代码上看，有ARC的代码和没有ARC的代码区别就在下面的几个关键字。

类似 NSObject* 的对象类型，或者 id 类型¹，当ARC有效的时候，根据具体情况，这些关键字必须要使用²。

__strong
__weak
__unsafe_unretained
__autoreleasing
__strong是默认的修饰符。

__weak修饰了一个自动nil的weak引用。

__unsafe_unretained声明了一个不会自动nil的weak引用。当变量被释放，那么它就变成了一个野指针了。

__autoreleasing 用来修饰一个声明为 (id *) 的函数的参数，当函数返回值时被释放。

接下来，我们结合下面ARC的使用准则，来看看一些使用ARC后的技术细节。

ARC使用准则

为了比秒程序秒退的尴尬，ARC有效时，我们的代码必须遵循下面的准则。

不能使用 retain/release/retainCount/autorelease
不能使用 NSAllocateObject/NSDeallocateObject
不能使用 NSZone
不能明示调用dealloc
内存管理相关的函数必须遵循命名规则
使用@autoreleasepool代替NSAutoreleasePool
Objective-C 对象不能作为C语言结构体（struct/union）的成员
【id】与【void*】之间需要明示cast

建议使用Objective-C的class来管理数据格式，来代替C语言的struct。不能隐式转换 id 和 void *。

让我们一个一个来分析

不能使用 retain/release/retainCount/autorelease

内存管理完全交给编译器去做，所以之前内存相关的函数(retain/release/retainCount/autorelease)不能出现在程序中。Apple的ARC文档中也有下面的说明。

ARC 有效后，不需要再次使用retain 和 release

如果我们在程序中使用这些函数，经得到类似下面的编译错误信息。

    error: ARC forbids explicit message send of ’release’
         [o release];
          ^ ~~~~~~~

不能使用 NSAllocateObject/NSDeallocateObject

生成并持有一个Objective-C对象的时候，往往像下面一样使用NSObject的alloc接口函数。

    id obj = [NSObject alloc];

实际上，如果我们看了GNUstep 中关于 alloc 的代码就会明白，实际他是使用 NSAllocateObject 来生成并持有对象实例的。换言之，ARC有效的时候，NSAllocateObject函数的调用也是禁止的。如果使用，也会遇到下面的编译错误。

    error: ’NSAllocateObject’ is unavailable:
        not available in automatic reference counting mode

同样，对象释放时使用的 NSDeallocateObject 函数也不能使用。

不能使用 NSZone

NSZone 是什么？NSZone 是为了防止内存碎片而导入的一项措施。Zone 是内存管理的基本单元，系统中管理复数的Zone。系统根据对象的使用目的，尺寸，分配其所属的Zone区域。以提高对象的访问效率，避免不必要的内存碎片。但是，现在的运行时系统（用编译开关 __OBJC2__ 指定的情况下）是不支持Zone概念的。所以，不管ARC是否有效，都不能使用 NSZone。

不能明示调用dealloc

不管是否使用ARC，当对象被释放的时候，对象的dealloc函数被调用（就像是C++中对象的析构函数）。在该函数中，需要做一些内存释放的动作。比如，当对象中使用了malloc分配的C语言内存空间，那么dealloc中就需要像下面一样处理内存的释放。

- (void) dealloc
{
    free(buffer_);
}

又或者是注册的delegate对象，观察者对象需要被删除的时候，也是在dealloc函数中动作。

- (void) dealloc
{
    [[NSNotificationCenter defaultCenter] removeObserver:self];
}

如果在ARC无效的时候，我们还要像下面一样，调用父类对象的dealloc函数。

- (void) dealloc
{
    [super dealloc];
}

但是当ARC有效的时候，[super dealloc];的调用已经被编译器自动执行，已经不需要我们明示调用了。如果你在代码中还这样写，难免遇到下面的错误。

    error: ARC forbids explicit message send of ’dealloc’
         [super dealloc];
          ^ ~~~~~~~

内存管理相关的函数必须遵循命名规则

在iPhone开发之深入浅出 (3) — ARC之前世今生中，我们知道如果是 alloc/new/copy/mutableCopy/init 开头的函数，需要将对象所有权返回给调用端。这条规则不管ARC是否有效都应该被遵守。只是 init 开头的函数比较特殊，他只在ARC下有要求，而且异常苛刻。

init 开始的函数只能返回id型，或者是该函数所属的类/父类的对象类型。基本上来说，init函数是针对alloc函数的返回值，做一些初始化处理，然后再将该对象返回。比如：

    id obj = [[NSObject alloc] init];

再比如下面定义的函数就是不对的：

    - (void) initThisObject;

需要是下面这样：

    - (id) initWithObject:(id)obj;

另外，下面名为 initialize 的函数比较特殊，编译器将把它过滤掉，不按上面的规则处理。

使用@autoreleasepool代替NSAutoreleasePool

在ARC之下，已经不能在代码中使用 NSAutoreleasePool，我们之前写 main.m 文件的时候，往往像下面这样写。

    int main(int argc, char *argv[]) {
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
    int retVal = UIApplicationMain(argc, argv, nil, nil);
    [pool release];
    return retVal;
}

而当ARC有效后，我们需要用@autoreleasepool代替NSAutoreleasePool。

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

当编译器看到 @autoreleasepool 定义的块后会自动生成 NSAutoreleasePool 对象，并将需要的对象放入 AutoReleasePool 中，当出方块的定义范围时，pool 中的对象将被释放。

Objective-C 对象不能作为C语言结构体（struct/union）的成员

当我们设置ARC有效，并在C语言的结构体中定义Objective-C的对象时，将出现类似下面的编译错误。

1
2
3

struct Data {
    NSMutableArray *array;
};

    error: ARC forbids Objective-C objs in structs or unions
         NSMutableArray *array;
                         ^

由于 ARC 是将内存管理的细节委托给编译器来做，所以说编译器必须要管理对象的生命周期。而LLVM 3.0中不存在对单纯C语言构造体成员的内存管理方法。如果单纯是栈对象，利用进出栈原理，可以简单地维护对象的生命周期；而结构体是不行的，简单地理解，结构体没有析构函数，编译器自身不能自动释放其内部的 Objective-C 对象。

当我们必须在C语言的结构体中放入 Objective-C 对象的时候，可以使用 void* 转型，或者使用 __unsafe_unretained 关键字。比如下面：

1
2
3

struct Data {
    NSMutableArray __unsafe_unretained *array;
};

这样一来，该内存信息不在编译器内存管理对象内，仅仅是使用而已，没有对象的持有权。当然，对象所有权的持有者需要明确的管理他与该结构体的交互，不要引起不必要的错误³。

【id】与【void*】之间需要明示cast

ARC 有效的时候，由于编译器帮我们做了内存管理的工作，所以我们不需要太担心。但是当与 ARC 管理以外的对象类型交互的时候，就需要特殊的转型关键字，来决定所有权的归属问题。

主要的转型关键字是:

关键字	解释
__bridge	单纯的类型转换，没有进行所有权的转移
__bridge_retained	类型转换是伴随所有权传递，转换前后变量都持有对象的所有权
__bridge_transfer	类型转换伴随所有权转移，被转换变量将失去对象的所有权

当我们在 Core Foundation 对象类型与 Objective-C 对象类型之间切换的时候，需要把握下面的因素：

明确被转换类型是否是 ARC 管理的对象
- Core Foundation 对象类型不在 ARC 管理范畴内
- Cocoa Framework::Foundation 对象类型（即一般使用到的Objectie-C对象类型）在 ARC 的管理范畴内
如果不在 ARC 管理范畴内的对象，那么要清楚 release 的责任应该是谁
各种对象的生命周期是怎样的

题外话

Xcode 4.3带来的变化

最近随着 iOS 5.1 的推出，Xcode也推出了4.3版本。在该版本下，ARC 有效时的属性(@property) 定义的时候，如果不明确指定所有权关键字，那么缺省的就是 strong。而在 Xcode4.2 中，即使 strong 也要显示指定。

在 Xcode4.2 的时候，针对下面的代码，

// ARC 无效
@property (nonatomic, retain) NSString *string;

// --->

// ARC 有效
@property (nonatomic, strong) NSString *string;

而在 Xcode 4.3 中，我们可以这么做，

// ARC 无效
@property (nonatomic, retain) NSString *string;

// --->

// ARC 有效
@property (nonatomic) NSString *string;

ARC 代码自动变换

另外，Xcode 4.2开始，增加了旧代码向 ARC 代码自动转换的功能。有兴趣的朋友可以试试。位置是：

Edit->Refactor->Convert to Objective-C ARC…

为什么iOS中没有GC

我们已经知道ARC并不是GC（垃圾回收）了，那么，为什么iOS中不支持该机能呢？还特意搞出个ARC来。以下是我的分析：

消耗CPU时间的处理尽量避免，以节约电池电量
GC执行的后，会停掉运行时库；这是最大的心结
嵌入式设备本身内存就不是很大，如果GC不停的在后台运行，执行的频率会很高，严重影响性能
- UI动画处理是iOS的一大卖点，而有了GC后可能会引起不必要的性能损失

1. 关于Objective-C对象的解释，可以参考iPhone开发入门（7）— 从C/C++语言到Objective-C语言。

2. 当然，如果你不写，编译器会用缺省的值代替。具体见iPhone开发之深入浅出 (3) — ARC之前世今生中的描述。

3. 关于这一点，可以参考iPhone开发之深入浅出 (1) — ARC是什么一文，明白为什么 __unsafe_unretained 是危险的。

ARC

ARC是什么

变化点

使用ARC的好处

不好的地方

ARC基本规则

Objective-C对象

强参照 (Strong reference)

弱参照 (Weak reference)

引用关键字

总结

iPhone开发之深入浅出 (2) — ARC之@property使用

所有者属性

读写相关的属性 (readwrite, readonly)

iPhone开发之深入浅出 (3) — ARC之前世今生

Objective-C 内存管理

基本原则

编程准则

生成对象时，使用autorelease

对象代入时，先autorelease后再retain

对象在函数中返回时，使用return [[object retain] autorelease]

ARC 诞生

__strong

__weak

__autoreleasing

ARC 规则

iPhone开发之深入浅出 (4) — ARC之循环参照

概念

解决方式

Delegate模式

Blocks

使用__block关键字修饰

使用__weak关键字修饰

iPhone开发之深入浅出 (5) — ARC之Outlet与弱引用

使用weak property声明Outlet

简化viewDidUnload

什么时候要用strong property

iPhone开发之深入浅出 (6) — ARC之对象转型

引子

__bridge

__bridge_retained

__bridge_transfer

Toll-Free bridged

总结

iPhone开发之深入浅出 (7) — ARC总结

内存管理基本原则

所有权关键字

ARC使用准则

不能使用 retain/release/retainCount/autorelease

不能使用 NSAllocateObject/NSDeallocateObject

不能使用 NSZone

不能明示调用dealloc

内存管理相关的函数必须遵循命名规则

使用@autoreleasepool代替NSAutoreleasePool

Objective-C 对象不能作为C语言结构体（struct/union）的成员

【id】与【void*】之间需要明示cast

题外话

Xcode 4.3带来的变化

ARC 代码自动变换

为什么iOS中没有GC