属性内存管理相关修饰符的使用规范

简介

  • strong/retain:只能修饰对象。持有对象。两者等价。

  • assign/unsafe_unretained:最好只修饰基础数据类型。修饰对象时,不持有对象。对象销毁后会属性值不会自动清空从而造成悬垂指针。两者等价。

  • weak:只能修饰对象。不持有对象。当对象被销毁后,属性值会自动清空。

  • copy:只能修饰对象。与 strong 类似,但是赋值的是被复制的对象。


strong/retain

修饰语义

此特质表明该属性定义了一种“拥有关系”(owning relationship)。为这种属性设置新值时,设置方法会先保留新值,并释放旧值,然后再将新值设置上去。

- (void)setObject:(id)object {
    [object retain];
    [_object release];
    _object = object;
}

修饰限制

只能用来修饰“对象类型”。如果用来修饰“基础数据类型”,编译器会报错:“带有 retain 或 strong 特质的属性必须是对象类型”。这是因为基础数据类型没有引用计数,编译器不能插入管理引用计数的代码。

Property with 'retain (or strong)' attribute must be of object type

区别

两者是完全等价的。但 strong 是随 iOS5 引入 ARC 时加入的新特性,所以在 MRC 环境下(-fno-objc-arc)只能用 retain 来修饰。在 ARC 环境下,为了与 MRC 进行区分,也为了和 weak 对应,最好使用 strong。


assign/unsafe_unretained

修饰语义

此特质表明该属性定义了一种“非拥有关系”(nonowning relationship)。为这种属性设置新值时,设置方法既不保留新值,也不释放旧值。

修饰限制

最好用来修饰“基础数据类型”。如果修饰“对象类型”,当目标对象遭到摧毁时,属性值不会自动清空(autonilling),从而造成悬垂指针。这时,再次访问此属性就是不安全的(unsafe),因为不能够确定引用的内存是否已经回收。

区别

weak 是随着 iOS5 引入 ARC 时加入的新特性。在此之前,assign 通常只用于“基础数据类型”,unsafe_unretained 则多用于“对象类型”(与 ARC 下的 weak 对应)。实际上,尽管 ARC 式的内存管理是编译器的工作,但附有 unsafe_unretained 修饰符的变量不属于编译器的内存管理对象。所以 unsafe_unretained 修饰“基础数据类型”并不会报错,在实际使用时,与 assign 是完全等价的。

自动清空(weak 具备的特质)是随着 ARC 而引入的新特性,由运行期系统来实现。MRC 时代的运行系统(objec4 Objective-C 运行时库493.9以下)还无法实现自动清空,所以用弱引用修饰对象是不安全的。因此,才会出现与 assign 语义相同的 unsafe_unretained 来起到标示作用,用来告诉开发者,这样来修饰对象是不安全的(unsafe)。仅此而已。

在MRC环境下(-fno-objc-arc),也应该遵循这样的规则来使用。在 ARC 环境下,assign/unsafe_unretained 都不建议用来修饰“对象类型”,而应该使用更安全的 weak。其实,在 weak 引入之后, unsafe_unretained 已经失去了使用意义。在修饰“对象类型”的时候,我们有更安全的 weak。修饰“基础数据类型”的时候也不符合为 unsafe 的语义和 MRC 的使用习惯。但是 unsafe_unretained 在 ARC 下也是有使用场景的。如果想把对象加到C语言结构体中,这时就可以使用 unsafe_unretained 修饰(或者强制转换成“void *”),这时是符合 unsafe 语义的。


weak

修饰语义

此特质所表达的所属关系与 assign/unsafe_unretained 类似。然而在属性所指向的对象遭到摧毁时,属性值也会清空(nil out)。

使用附有 weak 修饰符的变量会自动注册到 autoreleasepool。如果大量使用 weak 修饰的变量,则会消耗相应的 CPU 资源。良策是只在需要避免循环引用时使用 weak。以下源代码使用了5次附有 weak 修饰符的变量。相应地,变量 o 所赋值的对象也就注册到 autoreleasepool 中5次。

id __weak o = obj;
NSLog(@"1 %@", o);
NSLog(@"2 %@", o);
NSLog(@"3 %@", o);
NSLog(@"4 %@", o);
NSLog(@"5 %@", o);

将附有 __weak 修饰符的变量 o 赋值给附有 __strong 修饰符的变量后再使用可以避免此类问题。在“tmp = o;”时对象仅注册到 autoreleasepool 中1次。

id __weak o = obj;
id tmp = o;
NSLog(@"1 %@", tmp);
NSLog(@"2 %@", tmp);
NSLog(@"3 %@", tmp);
NSLog(@"4 %@", tmp);
NSLog(@"5 %@", tmp);

修饰限制

只能用来修饰“对象类型”。如果用来修饰“基础数据类型”,编译器会报错:“带有weak特质的属性必须是对象类型”。这是因为“基础数据类型”不能执行自动清空(不能置为nil)。

Property with 'weak' attribute must be of object type

区别

weak 是随着 iOS5 引入ARC时加入的新特性,在 MRC 环境下(-fno-objc-arc)习惯用 unsafe_unretained 来修饰。weak 引用可以自动清空,也可以不自动清空。自动清空(autonilling)是随着 ARC 而引入的新特性,由运行期系统来实现。在具备自动清空功能的弱引用上,可以随意读取其数据,因为这种引用不会指向已经回收过的内存。所以相比 assign/unsafe_unretained,你可以将 weak 理解为 safe_unretained。

*实际上,存在着不支持 weak 修饰符的对象。比如 NSMachPort 类的对象、allowsWeakRefrence/reatinWeakRefrence 实例方法(没有写入 NSObject 接口说明文档中)返回 NO 的对象等。这不在本文的讨论范围。


copy

修饰语义

此特质所表达的所属关系与 strong/retain 类似。然而设置方法并不保留新值,而是将其“拷贝”(copy)。

修饰限制

只能用来修饰“对象类型”。如果用来修饰“基础数据类型”,编译器会报错:“带有 copy 特质的属性必须是对象类型”。这是因为基础数据类型没有引用计数,编译器不能插入管理引用计数的代码。

Property with 'copy' attribute must be of object type

*copy 多用于修饰 Block、NSString 等,其具体使用场景不在本文讨论范围。


补充

属性修饰符与对象所有权修饰符的对应关系

  • strong:__strong修饰符
  • retain:__strong修饰符
  • assign:__unsafe_unretained修饰符
  • unsafe_unretained:__unsafe_unretained修饰符
  • weak:__weak修饰符
  • copy:__strong修饰符(但是赋值的是被复制的对象)

关联对象中与内存管理相关的修饰符的对应关系

  • OBJC_ASSOCIATION_ASSIGN:@property (assign) / @property(unsafe_unretained)
  • OBJC_ASSOCIATION_RETAIN_NONATOMIC:@property (nonatomic, strong)
  • OBJC_ASSOCIATION_COPY_NONATOMIC:@property (nonatomic, copy)
  • OBJC_ASSOCIATION_RETAIN:@property (atomic, strong)
  • OBJC_ASSOCIATION_COPY:@property (atomic, copy)

总结

  • retain 和 unsafe_unretained 都是 MRC 时代的修饰符,他们分别对应 ARC 引入的 strong 和 weak。在 ARC 环境中不要再使用它们。
  • strong 和 weak 是 ARC 环境中应该使用的一对修饰符。一个持有修饰对象,一个不持有修饰对象,且都不能修饰“基础数据类型”,都能够自动清空。
  • assign 在任何环境中都应该用来修饰“基础数据类型”(都允许修饰“对象类型”),没有持有与否的语义。
  • copy 会将对象进行拷贝,具体的使用场景不在本文的讨论范围。

博客:xuyafei.cn
简书:jianshu.com/users/2555924d8c6e
微博:weibo.com/xuyafei86
Github:github.com/xiaofei86

参考资料

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 162,408评论 4 371
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 68,690评论 2 307
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 112,036评论 0 255
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 44,726评论 0 221
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 53,123评论 3 296
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 41,037评论 1 225
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 32,178评论 2 318
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,964评论 0 213
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,703评论 1 250
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,863评论 2 254
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,333评论 1 265
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,658评论 3 263
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,374评论 3 244
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,195评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,988评论 0 201
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 36,167评论 2 285
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,970评论 2 279

推荐阅读更多精彩内容