在Objective-C 这种面向对象的语言里,内存管理是个重要的概念。要想用一门语言写出内存使用效率高而且又没有bug的代码,就得掌握其内存管理模型的种种细节。
一旦理解了这些规则,你就会发现,其实Objective-C 的内存管理没那么复杂,而且有了"自动引用计数"(Automatic Reference Counting,ARC)之后,就变得更为简单了。ARC几乎把所有内存管理事宜都交给编译器来决定,开发者只需关注于业务逻辑。
引用计数
Objective-C 中的内存管理,也就是引用计数。可以用开关房间的灯为例来说明引用计数机制。
假设办公室的照明设备只有一个。上班进入办公室的人需要照明。所以要把灯打开。而对于下班离开办公室的人来说,已经不需要照明了,所以需要把灯关掉。若 是很多人上下班,每个人都开灯或是关灯,那么办公室的情况又将如何呢?最早下班离开的人如果关了灯,那就会让办公室还没走的所有人的将处于一片黑暗之中。
解决这一问题的办法是使办公室在还有至少1人的情况下保持开灯状态,而在无人时保持关灯状态。
(1)最早进入办公室的人开灯。
(2)之后进入办公室的人,需要照明。
(3)下班离开办公室的人,不需要照明。
(4)最后离开办公室的人关灯(此时已无人需要照明)。
为判断是否还有人在办公室里,这里导入计数功能来计算"需要照明的人数"。下面让我们来看一看这一功能是如何运作的。
(1)第一个人进入办公室,"需要照明的人数"加1。计数值从0变成了1,因此要开灯。
(2)第二个人进入办公室,"需要照明的人数"加1。计数值从1变成了2。
(3)每当有人下班离开办公室时,"需要照明的人数"就减1。如计数值从2变成了1。
(4)最后一个人下班离开办公室时,"需要照明的人数"就减1。计数值从1变成了0,因此要关灯。
这样就能在不需要照明的时候保持关灯状态。办公室中仅有的照明设备也得到了很好的管理。
在 Objective-C 中,"对象"相当于办公室的照明设备。在现实世界中办公室的照明设备只有一个,但在Objective-C的世界里,虽然计算机资源有限,但一台计算机可以同时处理好几个对象。
此外,"对象的使用环境"相当于上班进入办公室的人。虽然这里的"环境"有时也指在运行中的程序代码、变量、变量作用域、对象等,但在概念上就是使用对象的环境。上班进入办公室的人对办公室照明设备发出的动作,与 Objective-C 的对应关系如下:
| 对照明设备所做的动作 | 对OC对象所做的动作 |
| 开灯 | 生成对象 |
| 需要照明 | 持有对象 |
| 不需要照明 | 释放对象 |
| 关灯 | 销毁对象 |
使用引用计数功能计算需要照明的人数,使办公室的照明得到了很好的管理。同样,使用引用计数功能,对象也能得到很好的管理,这就是 Objective-C 的内存管理。
内存管理的思考方式
首先来学习引用计数式内存管理的思考方式。看到"引用计数"这个名称,我们便会不自觉地联想到"某处有某物多少多少"而将注意力放在计数上。但其实,更加客观、正确的思考方式是:
- 自己生成的对象,自己持有。
- 非自己生成的对象,自己也能持有。
- 不再需要自己持有的对象时释放。
- 非自己持有的对象无法释放。
引用计数式的内存管理的思考方式仅此而已。按照这个思路,完全不必考虑引用计数。
上文出现了"生成"、"持有"、"释放"三个词。而在Objective-C内存管理中还要加上"废弃"一词。各个词表示的 Objective-C方法如表
| 对象操作 | Objective-C方法 |
| 生成并持有对象 | alloc/new/copy/mutableCopy等方法 |
| 持有对象 | retain方法 |
| 释放对象 | release方法 |
| 销毁对象 | dealloc方法 |
这些有关Objective-C内存管理的方法,实际上不包括在该语言中,而是包含在Cocoa框架中用于OSX、iOS应用开发。
ARC规则
"引用计数式内存管理"的本质部分在ARC中并没有改变。就像"自动引用计数"这个名称表示的那样,ARC只是自动地帮助我们处理"引用计数"的相关部分。
所有权修饰符
Objective-C编程为了处理对象,可将变量类型定义为id类型或各种对象类型。
所谓对象类型就是指向NSObject这样的Objective-C类的指针,例如"NSObject*"。id类型用于隐藏对象类型的类名部分,相当于C语言中常用的"void*"。
ARC有效时,id类型和对象类型同C语言其他类型不同,其类型上必须附加所有权修饰符。所有权修饰符一共有4种。
- __strong修饰符
- __weak修饰符
- __unsafe_unretained修饰符
- __autoreleasing修饰符
__strong修饰符
__strong修饰符是id类型和对象类型默认的所有权修饰符。也就是说,以下源代码中的id变量,实际上被附加了所有权修饰符。
id obj = [[NSObject alloc]init];
id和对象类型在没有明确指明所有权修饰符时,默认为__strong修饰符。上面的源代码与以下相同。
id __strong obj = [[NSObject alloc]init];
该源代码在ARC无效时又该如何表述呢?
/* ARC无效 */
id obj = [[NSObject alloc]init];
该源代码一看则明,目前在表面上并没有任何变化。再看看下面的代码。
{
id __strong obj = [[NSObject alloc]init];
}
此源代码明确指定了C语言的变量的作用域。ARC无效时,该源代码可记述如下:
/* ARC无效 */
{
id obj = [[NSObject alloc]init];
[obj release];
}
为了释放生成并持有的对象,增加了调用release方法的代码。该源代码进行的动作同先前ARC有效时的动作完全一样。
如此源代码所示,附有__strong修饰符的变量obj在超出其变量作用域时,即在该变量被废弃时,会释放其被赋予的对象。
如"__strong"这个名称所示,__strong修饰符表示对对象的"强引用"。持有强引用的变量在超出其作用域时被废弃,随着强引用的失效,引用的对象会随之释放。
下面关注一下源代码中关于对象的所有者的部分。
{
id __strong obj = [[NSObject alloc]init];
}
此源代码就是之前自己生成并持有对象的源代码,该对象的所有者如下:
{
/*
* 自己生成并持有对象
*/
id __strong obj = [[NSObject alloc]init];
/*
* 因为变量obj为强引用
* 所以自己持有对象
*/
}
/*
* 因为变量obj超出其作用域,强引用失效,
* 所以自动地释放自己持有的对象。
* 对象的所有者不存在,因此废弃改对象。
*/
此外,对象的所有者和对象的生命周期是明确的。那么在取得非自己生成并持有的对象时又会如何呢?
{
id __strong obj = [NSMutableArray array];
}
在NSMutableArray类的array类方法的源代码中取得非自己生成并持有的对象,具体如下:
{
/*
* 取得非自己生成并持有的对象
*/
id __strong obj = [NSMutableArray array];
/*
* 因为变量obj为强引用,
* 所以自己持有对象
*/
}
/*
* 因为变量obj超出其作用域,强引用失效,
* 所以自动地释放自己持有的对象
*/
在这里对象的所有者和对象的生存周期也是明确的。
{
/*
* 自己生成并持有的对象
*/
id __strong obj = [[NSObject alloc]init];
/*
* 因为变量obj为强引用,
* 所以自己持有对象
*/
}
/*
* 因为变量obj超出其作用域,强引用失效,
* 所以自动地释放自己持有的对象。
* 对象的所有者不存在,因此废弃该对象。
*/
当然,附有__strong修饰符的变量之间可以相互赋值。
id __strong obj0 = [[NSObject alloc]init];
id __strong obj1 = [[NSObject alloc]init];
id __strong obj2 = nil;
obj0 = obj1;
obj2 = obj0;
obj1 = nil;
obj0 = nil;
obj2 = nil;
下面来看一下生成并持有对象的强引用。
id __strong obj0 = [[NSObject alloc]init]; /* 对象A */
/*
* obj0 持有对象A的强引用
*/
id __strong obj1 = [[NSObject alloc]init];/* 对象B */
/*
* obj1 持有对象的B强引用
*/
id __strong obj2 = nil;
/*
* obj2 不持有任何对象
*/
obj0 = obj1;
/*
* obj0 持有由 obj1 赋值的对象B的强引用
* 因为 obj0 被赋值,所以原先持有的对对象A的强引用失效。
* 对象A的持有者不存在,因此废弃对象A。
*
* 此时,持有对象B的强引用的变量为
* obj0 和 obj1
*/
obj2 = obj0;
/*
* obj2 持有由 obj0 赋值的对象B的强引用
*
* 此时,持有对象B的强引用的变量为
* obj0 , obj1 和 obj2
*/
obj1 = nil;
/*
* 因为 nil 被赋予了 obj1 , 所以对对象B的强引用失效。
*
* 此时,持有对象B的强引用的变量为
* obj0 和 obj2
*/
obj0 = nil;
/*
* 因为 nil 被赋予了 obj0 , 所以对对象B的强引用失效。
*
* 此时,持有对象B的强引用的变量为
* obj2
*/
obj2 = nil;
/*
* 因为 nil 被赋予了 obj2 , 所以对对象B的强引用失效。
* 对象B的所有者不存在,因此废弃对象B。
*/
通过上面这些不难发现,__strong修饰符的变量,不仅只在变量作用域中,在赋值上也能够正确地管理器对象的所有者。
当然,即便是 Objective-C类成员变量,也可以在方法参数上,使用附有__strong修饰符的变量。
@interface Test : NSObject
{
id __strong _obj;
} - (void)setObject:(id __strong)obj;
@end @implementation Test
- (id)init
{
self = [super init];
return self;
} - (void)setObject:(id __strong)obj
{
_obj = obj;
}
@end
接着试着使用该类。
{
id __strong test = [[Test alloc]init];
[test setObject:[NSObject alloc]init];
}
该例中生成并持有对象的状态记录如下:
{
id __strong test = [Test alloc]init];
/*
* test 持有Test对象的强引用
*/
[test setObject:[NSObject alloc]init];
/*
* Test 对象的_obj成员
* 持有NSObject对象的强引用
*/
}
/*
* 因为test变量超出其作用域,强引用失效,
* 所以自动释放Test对象
* Test对象的所有者不存在,因此废弃该对象。
*
* 废弃Test对象的同时,
* Test对象的 _obj成员也被废弃,
* NSObject 对象的强引用失效
* 自动释放NSObject对象
* NSObject对象的所有者不存在,因此废弃该对象。
*/
像这样,无需额外工作便可以使用与类成员变量以及方法参数中。
另外,__strong修饰符通后面要讲的__weak修饰符和__autoreleasing修饰符一起,可以保证将附有这些修饰符的自动变量初始化为nil。
id __strong obj0;
id __weak obj1;
id __autoreleasing obj2;
以下源代码与上相同。
id __strong obj0 = nil;
id __weak obj1 = nil;
id __autoreleasing obj2 = nil;
正如苹果宣称的那样,通过__strong修饰符,不必再次键入retain或者release,完美的满足了"引用计数式内存管理的思考方式":
- 自己生成的对象,自己所持有
- 非自己生成的对象,自己也能持有
- 不再需要自己持有的对象时释放
- 非自己持有的对象无法释放
前两项"自己生成的对象,自己持有"和""非自己生成的对象,自己也能持有"只需通过对带__strong修饰符的变量赋值便可达成。通过废弃带 __strong修饰符的变量(变量作用域结束或是成员变量所属对象废弃)或者对变量赋值,都可以做到"不在需要自己持有的对象时释放"。最后一项"非自 己持有的对象无法释放",由于不必再次键入release,所以原本就不会执行。这些都满足于引用计数式内存管理的思考方式。
因为id类型和对象类型的所有权修饰符默认为__strong修饰符,所以不需要写上"__strong"。使ARC有效及简单的编程遵循了Objective-C内存管理的思考方式。
__weak修饰符
看起来好通过__strong修饰符编译器就能够完美的进行内存管理。但是遗憾的是,仅通过__strong修饰符是不能解决有些重大问题的。
这里提到的重大问题就是引用计数式内存管理中必然会发生的"循环引用"的问题。
例如,前面出现的带有__strong修饰符的成员变量在持有对象时,很容易发生循环引用问题。
@interface Test : NSObject
{
id __strong _obj;
} - (void)setObject:(id __strong)obj;
@end @implementation Test
- (id)init
{
self = [super init];
return self;
} - (void)setObject:(id __strong)obj
{
_obj = obj;
}
@end
以下为循环引用。
{
id test0 = [[Test alloc] init];
id test1 = [[Test alloc] init];
[test0 setObject:test1];
[test1 setObject:test0];
}
为便于理解,下面写出了生成并持有对象的状态。
{
id test0 = [[Test alloc] init]; /* 对象A */
/*
* test0 持有对象A的强引用
*/
id test1 = [[Test alloc] init];/* 对象B */
/*
* test1 持有对象B的强引用
*/
[test0 setObject:test1];
/*
* Test对象A的_obj成员变量持有Test对象B的强引用
*
* 此时,持有Test对象B的强引用变量为
* Test对象A的_obj和test1
*/
[test1 setObject:test0];
/*
* Test对象B的_obj成员变量持有Test对象A的强引用
*
* 此时,持有Test对象A的强引用变量为
* Test对象B的_obj和test0
*/
}
/*
* 因为test0变量超出其作用域,强引用失效,
* 所以自动释放Test对象A。
*
* 因为test1变量超出其作用域,强引用失效,
* 所以自动释放Test对象B。
*
* 此时,持有Test对象A的强引用的变量为
* Test对象B的_obj。
*
* 此时,持有Test对象B的强引用的变量为
* Test对象A的_obj。
*
* 发生内存泄漏。
*/
循环引用容易发生内存泄漏。所谓内存泄漏就是应当废弃的对象在超出其生存周期后继续存在。
此代码的本意是赋予变量test0的对象A和赋予标量test1的对象B在超出期变量作用域时被释放,即在对象不被任何变量持有的状态下予以废弃。但是,循环引用使得对象不能被再次废弃。
向下面这种情况,虽然只有一个对象,但在该对象持有其自身时,也会发生循环引用。
id test = [[Test alloc]init];
[test setObject:test];
怎么样才能避免循环引用呢?看到__strong修饰符就会意识到了,既然有strong,就应该会有与之对应的weak。也就是说,__weak修饰符可以避免循环引用。
__weak修饰符与__strong修饰符相反,提供弱引用。弱引用不能持有对象实例。我们来看下面的代码:
id __weak obj = [[NSObject alloc]init];
变量obj上附加了__weak修饰符。实际上如果编译以上代码,编译器会发出警告。
此源代码将自己生成并持有的对象赋值给附有__weak修饰符的变量obj。即变量obj持有对象的弱引用。因此,为了不以自己持有的状态来保存自己生 成并持有的对象,生成的对象会立即释放。编译器会发出警告。如果像下面这样,将对象赋值给附有__strong修饰符的变量之后再赋值给附有__weak 修饰符的变量,就不会发出警告了。
{
id __strong obj0 = [[NSObject alloc]init];
id __weak obj1 = obj0;
}
下面确认对象的持有状况。
{
/*
* 自己生成并持有对象
*/
id __strong obj0 = [[NSObject alloc]init];
/*
* 因为obj0变量为强引用
* 所以自己持有对象
*/
id __weak obj1 = obj0;
/*
* obj1变量持有生成对象的弱引用
*/
}
/*
* 因为obj0变量超出其作用域,强引用失效,
* 所以自动释放自己持有的对象
* 因为对象的所有者不存在,所以废弃该对象
*/
因为带__weak修饰符的变量(即弱引用)不持有对象,所以在超出其变量作用域时,对象即被释放。如果像下面这样将先前发生循环引用的类成员变量改成附有__weak修饰符的成员变量的话,该现象便可避免。
@interface Test : NSObject
{
id __weak _obj;
}
- (void)setObject:(id __strong)obj;
@end
__weak修饰符还有一个优点。在持有某个对象的弱引用时,若该对象被废弃,则此弱引用将自动失效且处于nil被赋值的状态(空弱引用)。如以下代码所示。
id __weak obj1 = nil;
{
id __strong obj0 = [[NSObject alloc]init];
obj1 = obj0;
NSLog(@"A: %@",obj1);
}
NSLog(@"B: %@",obj1);
此源代码执行结果如下:
A: <NSObject: 0x753e180>
B: (null)
下面我们来确认一下对象的持有情况,看看为什么得到这样的执行结果。
id __weak obj1 = nil;
{
/*
* 自己生成并持有对象
*/ id __strong obj0 = [[NSObject alloc]init]; /*
* 因为obj0变量为强引用
* 所以自己持有对象
*/ obj1 = obj0; /*
* obj1变量持有对象的弱引用
*/ NSLog(@"A: %@",obj1); /*
* 输出obj1变量持有的弱引用的对象
*/
} /*
* 因为obj0变量超出其作用域,强引用失效
* 所以自动释放自己持有的对象
* 因为对象无持有者,所以废弃该对象
*
* 废弃对象的同时
* 持有该对象弱引用的obj1变量的弱引用失效,nil赋值给obj1。
*
*
*/ NSLog(@"B: %@",obj1);
/*
* 输出赋值给obj1变量中的nil
*/
像这样,使用__weak,修饰符可避免循环引用。通过检查附有__weak修饰符的变量是否为nil,可以判断被赋值的对象是否已被废弃。
__unsafe_unretained修饰符
__unsafe_unretained修饰符正如其名unsafe所示,是不安全的所有权修饰符。尽管ARC式的内存管理是编程器的工作,但附有__unsafe_unretained修饰符的变量不属于编译器的内存管理对象。这一点在使用时需要注意。
id __unsafe_unretained obj = [[NSObject alloc]init];
该源代码将自己生成并持有的对象赋值给附有__unsafe_unretained修饰符的变量中。虽然使用了unsafe变量,但编译器不会忽略,而是给与适当的警告。
附有__unsafe_unretained修饰符的变量同附有__weak修饰符的变量一样,因为自己生成并持有的对象不能继续为自己所有,所以生成的对象会立即被释放。到这里,__unsafe_unretained修饰符和__weak修饰符是一样的,下面我们来看看源代码的差异。
id __unsafe_unretained obj1 = nil;
{
id __strong obj0 = [[NSObject alloc]init];
obj1 = obj0;
NSLog(@"A: %@",obj1);
} NSLog(@"B: %@",obj1);
该源代码的执行结果为:
A: <NSObject: 0x753e180>
B: <NSObject: 0x753e180>
我们还像以前那样,通过确认对象的持有情况来理解发生了什么。
id __unsafe_unretained obj1 = nil;
{
/*
* 自己生成并持有对象
*/ id __strong obj0 = [[NSObject alloc]init]; /*
* 因为obj0变量为强引用
* 所以自己持有对象
*/ obj1 = obj0; /*
* 虽然 obj0 变量赋值给 obj1
* 但是obj1 变量既不持有对象的强引用也不持有对象的弱引用
*/ NSLog(@"A: %@",obj1); /*
* 输出obj1变量表示的对象
*/
} /*
* 因为obj0变量超出其作用域,强引用失效
* 所以自动释放自己持有的对象
* 因为对象无持有者,所以废弃该对象。
*/ NSLog(@"B: %@",obj1);
/*
* 输出赋值给obj1变量表示的对象
*
* obj1变量表示的对象
* 已经被废弃(悬垂指针)!
* 错误访问!
*/
也就是说,最后一行的NSLog只是碰巧正常运行而已。虽然访问了已经被废弃的对象,但应用程序在个别运行状态下才会崩溃。
在使用__unsafe_unretained修饰符时,赋值给附有__strong修饰符的变量时有必要确保被复制的对象确实存在。
__autoreleasing修饰符
ARC有效时不能使用autorelease方法,也不能使用NSAutoreleasePool类。这样一来,虽然autorelease无法直接使用,但实际上,ARC有效时autorelease功能是起作用的。
ARC无效时会像下面这样来使用:
/* ARC无效 */
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc]init];
id obj = [[NSObject alloc]init];
[obj autorelease];
[pool drain];
ARC有效时,该源代码也能写成下面这样:
@autoreleasepool {
id __autoreleasing obj = [[NSObject alloc]init];
}
指定"@autoreleasepool块"来替代"NSAutoreleasePool类对象生成、持有以及废弃"这一范围。
另外ARC有效时,要通过将对象赋值给附加了__autoreleasing修饰符的变量来替代调用autorelease方法。对象赋值给附有__autoreleasing修饰符的变量等价于ARC无效时调用对象的autorelease方法,即对象被注册到autoreleasepool中。
也就是说可以理解为,在ARC有效时,用@autoreleasepool块替代NSAutoreleasePool类,用附有__autoreleasing修饰符的变量替代autorelease方法。
但是显示地附加__autoreleasing修饰符同显式的附加__strong修饰符一样罕见。
取得非自己生成并持有的对象时,如同一下源代码,虽然可以使用alloc/new/copy/mutableCopy以外的方法来取得对象,但该对象已被注册到了autoreleasepool。这同在ARC无效时取得调用了autorelease方法的对象是一样的。这是由于编译器会检查方法名是否以alloc/new/copy/mutableCopy开始,如果不是则自动将返回值的对象注册到autoreleasepool。另外init方法返回值的对象不注册到autoreleasepool。
@autoreleasepool {
id __strong obj = [NSMutableArray array];
}
我们再来看看该源代码中对象的所有状况。
@autoreleasepool {
/*
* 取得非自己生成并持有的对象
*/
id __strong obj = [NSMutableArray array];
/*
* 因为变量obj为强引用
* 所以自己持有对象
*
* 并且该对象
* 由编译器判断其方法名
* 自动注册到autoreleasepool
*/
}
/*
* 因为变量obj超出其作用域,强引用失效,
* 所以自动释放自己持有的对象
*
* 同时随着@autoreleasepool块的结束
* 注册到autoreleasepool中的
* 所有对象被自动释放
*
* 因为对象的所有者不存在,所以废弃对象
*/
像这样不使用__autoreleasing修饰符也能使对象注册到autoreleasepool。以下为取得非自己生成并持有对象时被调用方法的源代码示例。
+ (id)array
{
return [[NSMutableArray alloc]init];
}
该源代码也没有使用__autoreleasing修饰符,可写成以下形式。
+ (id)array
{
id obj = [[NSMutableArray alloc]init]
return obj;
}
因为没有显式指定所有权修饰符,所以id obj同附有__strong修饰符的id _strong obj是完全一样的。由于return使得对象变量超出期作用域,所以该强引用对应的自己持有的对象会被自动释放,但该对象作为函数的返回值,编译器会自动将其注册到autoreleasepool。
以下为使用__weak修饰符的例子。虽然__weak修饰符是为了避免循环引用而使用的,但在访问附有__weak修饰符的变量时,实际上必定要访问注册到autoreleasepool的对象。
id __weak obj1 = obj0;
NSLog(@"class = %@ ",[obj1 class]);
以下源代码与此相同。
id __weak obj1 = obj0;
id __autoreleasing tmp = obj1;
NSLog(@"class = %@ ",[tmp class]);
为什么在访问__weak修饰符的变量时必须要访问注册到autoreleasepool的对象呢?这是因为__weak修饰符只持有对象的弱引用,而在访问引用对象的过程中,该对象有可能被废弃。如果把要访问的对象注册到autoreleasepool中,那么在@autoreleasepool块结束之前都能确保该对象存在。因此,在使用附有__weak修饰符的变量时就必定要使用注册到autoreleasepool中的对象。
最后一个非显式地使用__autoreleasing修饰符的例子,同前面讲述的id obj和id __strong obj完全一样。那么id的指针id *obj又如何呢?可以由id __strong obj的例子类推出id __strong *obj吗? 其实,推出来的是id __autoreleasing *obj。同样的,对象的指针NSObject **obj便成为了NSObject* __autoreleasing *obj。
像这样,id的指针或对象的指针在没有显式的指定时会被附加上__autoreleasing修饰符。
比如,为了得到详细的错误信息,经常会在方法的参数中传递NSError对象的指针,而不是函数返回值。Cocoa框架中,大多数方法也是使用这种方法,如NSString的stringWithContentsOfFile:encoding:error类方法等。使用该方式的源代码如下所示。
NSError *error = nil;
BOOL result = [obj performOperationWithError:&error];
该方法的声明为:
- (BOOL) performOperationWithError:(NSError **)error;
同前面讲述的一样,id的指针或对象的指针会默认附加上__autoreleasing修饰符,所以等同于以下源代码。
- (BOOL) performOperationWithError:(NSError * __autoreleasing*)error;
参数中持有对象指针的方法,虽然为响应其执行结果,需要生成NSError类对象,但也必须符合内存管理的思考方式。
作为alloc/new/copy/mutableCopy方法返回值取得的对象是自己生成并持有的,其他情况下便是取得非自己生成并持有的对象。因此,使用附有__autoreleasing修饰符的变量作为对象取得参数,与出alloc/new/copy/mutableCopy外其他方法的返回值取得对象完全一样,都会注册到autoreleasepool,并取得非自己生成并持有的对象。
比如,performOperationWithError方法的源代码应该是下面这样:
- (BOOL) performOperationWithError:(NSError * __autoreleasing*)error{
/* 错误发生 */
*error = [[NSError alloc]initWithDomain:MyAppDomain code:errorCode userInfo:nil];
return NO;
}
因为声明为 NSError *__autoreleasing * 类型的error作为*error被赋值,所以能够返回注册到autoreleasepool中的对象。
然而,下面的源代码会产生编译器错误。
NSError *error = nil;
NSError **pError = &error;
赋值给对象指针时,所有权修饰符必须一致。
此时,对象指针必须附加__strong修饰符
NSError *error = nil;
NSError * __strong *pError = &error;
/* 编译正常 */
当然对于其他所有权修饰符也是一样。
NSError __weak *error = nil;
NSError *__weak *pError = &error;
/* 编译正常 */
NSError __unsafe_unretained *unsafeError = nil;
NSError *__unsafe_unretained *pUnsafeError = &unsafeError;
/* 编译正常 */
前面的方法参数中使用了附有__autoreleasing修饰符的对象指针类型。
- (BOOL) performOperationWithError:(NSError * __autoreleasing*)error;
然而调用方法却使用了附有__strong修饰符的对象指针类型。
NSError __strong *error = nil;
BOOL result = [obj performOperationWithError:&error];
对象指针赋值时,其所有权修饰符必须一致,但为什么该源代码没有警告就顺利通过编译了呢?实际上,编译器自动地将该源代码转化成了下面这种形式。
NSError __strong *error = nil;
NSError __autoreleasing *tmp = error;
BOOL result = [obj performOperationWithError:&tmp];
error = tmp;
当然也可以显式的指定方法参数中对象的指针类型的所有权修饰符。
- (BOOL) performOperationWithError:(NSError * __strong*)error;
向该源代码声明的一样,对象不注册到autoreleasepool也能够传递。但是前面也说过,只有作为alloc/new/copy/mutableCopy方法的返回值而取得对象时,能够自己生成并持有对象。其他情况即为"取得非自己生成并持有的对象",这些务必牢记。为了在使用参数取得对象时,贯彻内存管理的思考方式,我们要将参数声明为附有__autoreleasing修饰符的对象指针类型。
另外,虽然可以非显式的指定__autoreleasing修饰符,但在显式的指定__autorelesing修饰符时,必须注意对象变量要为自动变量(包括局部变量、函数以及方法参数)。
下面,我们换个话题,详细了解下@autoreleasepool。如以下源代码所示,ARC无效时,可将NSAutoreleasepool对象嵌套使用。
/* ARC无效 */
NSAutoreleasePool *pool0 = [[NSAutoreleasePool alloc]init];
NSAutoreleasePool *pool1 = [[NSAutoreleasePool alloc]init];
NSAutoreleasePool *pool2 = [[NSAutoreleasePool alloc]init];
id obj = [[NSObject alloc]init];
[obj autorelease];
[pool2 drain];
[pool1 drain];
[pool0 drain];
同样的,@autoreleasepool块也可以嵌套使用。
@autoreleasepool {
@autoreleasepool {
@autoreleasepool {
id __autoreleasing obj = [[NSObject alloc]init];
}
}
}
比如 ,在iOS应用程序模板中,向下面的main函数一样,@autoreleasepool块包含了全部程序。
int main(int argc, char * argv[]) {
@autoreleasepool {
return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
}
}
NSRunLoop等实现不论ARC有效还是无效,均能够随时释放注册到autoreleasepool中的对象。
另外,即使ARC无效时,@autoreleasepool块也能够使用,如以下所示:
@autoreleasepool{
id obj= [[NSObject alloc]init];
[obj autorelease];
}
因为autoreleasepool范围以块级源代码表示,提高了程序的可读性,所以无论ARC 是否有效都推荐使用@autoreleasepool块,另外调试用的非公开函数_obj_autoreleasePoolPrint()都可使用,利用这一函数可有效地帮助我们调试注册到autoreleasepool上的对象。
规则
在ARC有效的情况下,编译源代码,必须遵循一定的规则。下面就是具体的ARC规则:
- 不能使用retain/release/retain/autorelease
- 不能使用NSAllocateObject/NSDeallocateObject
- 须遵守内存管理的方法命名规则
- 不要显示调用dealloc
- 使用@autoreleasepool块替代NSAutoreleasePool
- 不能使用区域(NSZone)
- 对象型变量不能作为C语言结构体(struct/union)的成员
- 通过"__bridge" 显式转换"id"和"void*"