前言

為什么不要在init和dealloc方法中調(diào)用getter和setter:
Apple在Mac與iOS中關(guān)于內(nèi)存管理的開(kāi)發(fā)文檔中，有一節(jié)的題目為：“Don’tUse Accessor Methods in Initializer Methods and dealloc”，文中說(shuō)：“Theonly places you shouldn’t use accessor methods to set an instancevariable are in initializer methods anddealloc.”但是并沒(méi)有解釋為什么。網(wǎng)上搜索了幾篇國(guó)內(nèi)國(guó)外的文章和一些大V的博客，希望此文能詳盡大家的疑惑，未盡之處請(qǐng)留言指正。

為什么不能在init中調(diào)用accessor

案例一

下面這則代碼說(shuō)明了一種可能會(huì)引起錯(cuò)誤的情況：現(xiàn)有兩個(gè)類BaseClass和SubClass，SubClass繼承自BaseClass。父類有一個(gè)value屬性（子類自然也會(huì)集成該屬性）。如果在父類的init（或其他初始化構(gòu)造方法）中使用了value的setter，子類也重寫(xiě)了value的setter，那么就會(huì)出現(xiàn)問(wèn)題。原因如下：子類調(diào)用init（或其他初始化構(gòu)造方法）初始化對(duì)象時(shí)候，子類的init會(huì)首先調(diào)用父類的init（self = [super init]），這樣就會(huì)調(diào)到父類的init方法里，而我們?cè)诟割惖膇nit方法里調(diào)用了setter給value屬性賦值。父類會(huì)直接調(diào)用子類重寫(xiě)的那個(gè)setter(因?yàn)樽宇愔貙?xiě)了value的setter)。此時(shí)，子類對(duì)象還沒(méi)有初始化好，但子類value的setter先卻先于子類自己的init代碼調(diào)用(因?yàn)榇藭r(shí)子類的init方法還沒(méi)有return self)，就有可能會(huì)出現(xiàn)問(wèn)題。如果我們?cè)谧宇惖膕etter方法中做了其他操作，比如修改了某個(gè)實(shí)例變量的值，那么就會(huì)出錯(cuò)，因?yàn)榇藭r(shí)self還沒(méi)有初始化好。
造成這個(gè)問(wèn)題的原因有兩個(gè)：一就是在父類的init使用了setter；二是子類重寫(xiě)了setter，導(dǎo)致在父類init時(shí)就會(huì)調(diào)用子類重寫(xiě)的setter，萬(wàn)一重寫(xiě)的setter中進(jìn)行了一些子類特有的操作就可能會(huì)出現(xiàn)問(wèn)題，比如，給子類的某個(gè)屬性賦值失敗，因?yàn)榇藭r(shí)子類對(duì)象self還沒(méi)有初始化完成。

案例二

如果在父類的init方法中使用了value的setter，同時(shí)也在父類寫(xiě)了setter。當(dāng)子類初始化時(shí)會(huì)先調(diào)用父類的init方法，即self = [super init],由于父類中使用了value的setter，那么父類的init又會(huì)調(diào)到value的setter，如果setter中做了其他的操作，比如發(fā)送一個(gè)網(wǎng)絡(luò)請(qǐng)求，那么此時(shí)就有可能出現(xiàn)問(wèn)題。而當(dāng)子類對(duì)象通過(guò)setter給value賦值時(shí)，又會(huì)調(diào)用父類的setter。那么相當(dāng)于父類的setter被調(diào)用了兩次，發(fā)送了兩次相同的網(wǎng)絡(luò)請(qǐng)求。

init call accessor Example:

@interface BaseClass : NSObject @property(nonatomic) NSString* info; @end @implementation BaseClass - (instancetype)init { if ([super init]) { self.info = @"baseInfo"; } return self; } @end @interface SubClass : BaseClass @end @interface SubClass () @property (nonatomic) NSString* subInfo; @end @implementation SubClass - (instancetype)init { if (self = [super init]) { self.subInfo = @"subInfo"; } return self; } - (void)setInfo:(NSString *)info { [super setInfo:info]; NSString* copyString = [NSString stringWithString:self.subInfo]; NSLog(@"%@",copyString); } @end

當(dāng)執(zhí)行[[SubClass alloc]init]時(shí)會(huì)調(diào)用父類在Init方法。其中調(diào)用了accessor，去初始化父類部分的info屬性。看起來(lái)十分正常，但一旦子類重寫(xiě)了該方法，那么由于多態(tài)此時(shí)調(diào)用的就是子類的accessor方法！子類的accessor實(shí)現(xiàn)中的代碼都是以子類部分已初始化完全為前提編寫(xiě)，即子類部分已經(jīng)初始化完畢，完全可用，而現(xiàn)實(shí)情況是其init方法并沒(méi)有執(zhí)行完，對(duì)此假設(shè)并不成立，從而可能造成崩潰。以上例子有人造的痕跡，現(xiàn)實(shí)中更多的是某個(gè)方法被少調(diào)用一次，出現(xiàn)邏輯錯(cuò)誤。

為什么不能在dealloc中調(diào)用accessor

還是基于子類重寫(xiě)了父類的value屬性這一前提，在子類對(duì)象銷毀時(shí)，首先調(diào)用子類的dealloc，最后調(diào)用父類的dealloc（這與init初始化方法是相反的，且ARC中不需要我們手動(dòng)調(diào)用[super dealloc]）。如果父類在dealloc中調(diào)用了value的accessor且該accessor被子類重寫(xiě)，就會(huì)調(diào)到子類的accessor。但此時(shí)子類已經(jīng)釋放(因?yàn)橄日{(diào)用子類的dealloc，后調(diào)用父類的dealloc)，所以就會(huì)出現(xiàn)錯(cuò)誤甚至崩潰。
dealloc call accessor example

@interface BaseClass : NSObject @property(nonatomic) NSString* info; @end - (void)dealloc { self.info = nil; } @end @interface SubClass : BaseClass @property (nonatomic) NSString* debugInfo; @end @implementation SubClass - (instancetype)init { if (self = [super init]) { _debugInfo = @"This is SubClass"; } return self; } - (void)setInfo:(NSString *)info { NSLog(@"%@",[NSString stringWithString:self.debugInfo]); } - (void)dealloc { _debugInfo = nil; } @end

在SubClass的實(shí)例對(duì)象銷毀時(shí)，首先調(diào)用子類的dealloc，再調(diào)用父類的dealloc（這與init初始化是相反的，且ARC中不需要我們手動(dòng)調(diào)用[super dealloc]）。如果父類在dealloc時(shí)調(diào)用了accessor 并且該accessor被子類重寫(xiě)，就會(huì)調(diào)用到子類的accessor。而此時(shí)子類的dealloc已經(jīng)被調(diào)用了，基于其完整的假設(shè)已經(jīng)不成立，那么再執(zhí)行子類的代碼會(huì)存在一定風(fēng)險(xiǎn)，如上例就會(huì)崩潰。

另外，在《Effective Objective-C 2.0 編寫(xiě)高質(zhì)量iOS與OS X代碼的52個(gè)有效方法》的第31條——在dealloc方法中只釋放引用并解除監(jiān)聽(tīng)一節(jié)文中，作者也提到了下面一段話：在dealloc里不要調(diào)用屬性的存取方法，因?yàn)橛腥丝赡軙?huì)覆寫(xiě)這些方法，并于其中做一些無(wú)法再回收階段安全執(zhí)行的操作（上面已經(jīng)提到）。此外，屬性可能正處于“鍵值觀察”(Key-Value Observation，KVO)機(jī)制的監(jiān)控之下，該屬性的觀察者(Observer)可能會(huì)在屬性值改變時(shí)“保留”或使用這個(gè)即將回首的對(duì)象。這種做法會(huì)令運(yùn)行期系統(tǒng)的狀態(tài)完全失調(diào)，從而導(dǎo)致一些莫名其妙的錯(cuò)誤。

結(jié)論

綜上，不能在init和dealloc中使用accessor的原因是由于面向?qū)ο蟮睦^承、多態(tài)特性與accessor可能造成的副作用聯(lián)合導(dǎo)致的。繼承和多態(tài)導(dǎo)致在父類的實(shí)現(xiàn)中調(diào)用accessor可能導(dǎo)致調(diào)用到子類重寫(xiě)的accessor，而此時(shí)子類部分并未完全初始化或已經(jīng)銷毀，導(dǎo)致原有的假設(shè)不成立，從而出現(xiàn)一系列的邏輯問(wèn)題甚至崩潰。為了更清晰地闡述，以下分別從init和dealloc上舉例說(shuō)明。

結(jié)尾

在init和dealloc中使用accessor是存在風(fēng)險(xiǎn)的。但這并不代表百分之百的崩潰或者百分之百的錯(cuò)誤。從目前的實(shí)驗(yàn)來(lái)看，當(dāng)存在繼承時(shí)，在init或者dealloc方法中使用accessor會(huì)存在很高的風(fēng)險(xiǎn)，此時(shí)我們可要小心了。不過(guò)，在公司項(xiàng)目中，還是建議大家不要鋌而走險(xiǎn)，即使現(xiàn)在代碼沒(méi)有問(wèn)題，難保將來(lái)維護(hù)或擴(kuò)展時(shí)會(huì)出現(xiàn)問(wèn)題。只有將蘋(píng)果所說(shuō)的Don’t Use Accessor Methods in Initializer Methods and dealloc當(dāng)作一條編程規(guī)范，才能從根本上規(guī)避這個(gè)問(wèn)題。不過(guò)，有些情況我們必須破例，必須訪問(wèn)accessor，比如：待初始化的實(shí)例變量聲明在超類中，而我們又無(wú)法在子類中訪問(wèn)此實(shí)例變量的話，那么我們只能通過(guò)setter來(lái)對(duì)實(shí)例變量賦值。又比如：如果一個(gè)實(shí)例變量是lazy的（懶加載），這種情況必須通過(guò)getter方法訪問(wèn)屬性，否則無(wú)法給實(shí)例變量賦值。
所以，萬(wàn)事無(wú)絕對(duì)，我們只有理解了為什么不能在init和dealloc方法中使用accessor才能在各種情況下游刃有余。

文／VV木公子（簡(jiǎn)書(shū)作者）
PS:如非特別說(shuō)明，所有文章均為原創(chuàng)作品，著作權(quán)歸作者所有，轉(zhuǎn)載轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)，并注明出處，所有打賞均歸本人所有！
如果您是iOS開(kāi)發(fā)者，或者對(duì)本篇文章感興趣，請(qǐng)關(guān)注本人，后續(xù)會(huì)更新更多相關(guān)文章！敬請(qǐng)期待！

參考文章

《Effective Objective-C 2.0 編寫(xiě)高質(zhì)量iOS與OS X代碼的52個(gè)有效方法》
為什么不要在init和dealloc函數(shù)中使用accessor
Objective-C, 為什么不能在init或是dealloc方法中使用accessor方法
iOS中正確處理dealloc方法
為什么不要在init和dealloc函數(shù)中使用accessor
初始化和dealloc方法中不要調(diào)用屬性的存取方法，而要直接調(diào)用 _實(shí)例變量

轉(zhuǎn)載于:https://www.cnblogs.com/wsnb/p/6163377.html

總結(jié)

以上是生活随笔為你收集整理的为什么不能在init和dealloc函数中使用accessor方法的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。