屬性內存管理相關修飾符的使用規范

簡介

  • 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閱讀 228,936評論 6 535
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,744評論 3 421
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 176,879評論 0 381
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,181評論 1 315
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,935評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,325評論 1 324
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,384評論 3 443
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,534評論 0 289
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 49,084評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,892評論 3 356
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,067評論 1 371
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,623評論 5 362
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,322評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,735評論 0 27
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,990評論 1 289
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,800評論 3 395
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 48,084評論 2 375

推薦閱讀更多精彩內容