为什么不能在init和dealloc函数中使用accessor方法

前言

为什么不要在init和dealloc方法中调用getter和setter:
Apple在Mac与iOS中关于内存管理的开发文档中,有一节的题目为:“Don’tUse Accessor Methods in Initializer Methods and dealloc”,文中说:“Theonly places you shouldn’t use accessor methods to set an instancevariable are in initializer methods anddealloc.”但是并没有解释为什么。网上搜索了几篇国内国外的文章和一些大V的博客,希望此文能详尽大家的疑惑,未尽之处请留言指正。

为什么不能在init中调用accessor

案例一

下面这则代码说明了一种可能会引起错误的情况:现有两个类BaseClass和SubClass,SubClass继承自BaseClass。父类有一个value属性(子类自然也会集成该属性)。如果在父类的init(或其他初始化构造方法)中使用了value的setter,子类也重写了value的setter,那么就会出现问题。原因如下:子类调用init(或其他初始化构造方法)初始化对象时候,子类的init会首先调用父类的init(self = [super init]),这样就会调到父类的init方法里,而我们在父类的init方法里调用了setter给value属性赋值。父类会直接调用子类重写的那个setter(因为子类重写了value的setter)。此时,子类对象还没有初始化好,但子类value的setter先却先于子类自己的init代码调用(因为此时子类的init方法还没有return self),就有可能会出现问题。如果我们在子类的setter方法中做了其他操作,比如修改了某个实例变量的值,那么就会出错,因为此时self还没有初始化好。
造成这个问题的原因有两个:一就是在父类的init使用了setter;二是子类重写了setter,导致在父类init时就会调用子类重写的setter,万一重写的setter中进行了一些子类特有的操作就可能会出现问题,比如,给子类的某个属性赋值失败,因为此时子类对象self还没有初始化完成。

案例二

如果在父类的init方法中使用了value的setter,同时也在父类写了setter。当子类初始化时会先调用父类的init方法,即self = [super init],由于父类中使用了value的setter,那么父类的init又会调到value的setter,如果setter中做了其他的操作,比如发送一个网络请求,那么此时就有可能出现问题。而当子类对象通过setter给value赋值时,又会调用父类的setter。那么相当于父类的setter被调用了两次,发送了两次相同的网络请求。

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

当执行[[SubClass alloc]init]时会调用父类在Init方法。其中调用了accessor,去初始化父类部分的info属性。看起来十分正常,但一旦子类重写了该方法,那么由于多态此时调用的就是子类的accessor方法!子类的accessor实现中的代码都是以子类部分已初始化完全为前提编写,即子类部分已经初始化完毕,完全可用,而现实情况是其init方法并没有执行完,对此假设并不成立,从而可能造成崩溃。以上例子有人造的痕迹,现实中更多的是某个方法被少调用一次,出现逻辑错误。

为什么不能在dealloc中调用accessor

还是基于子类重写了父类的value属性这一前提,在子类对象销毁时,首先调用子类的dealloc,最后调用父类的dealloc(这与init初始化方法是相反的,且ARC中不需要我们手动调用[super dealloc])。如果父类在dealloc中调用了value的accessor且该accessor被子类重写,就会调到子类的accessor。但此时子类已经释放(因为先调用子类的dealloc,后调用父类的dealloc),所以就会出现错误甚至崩溃。
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的实例对象销毁时,首先调用子类的dealloc,再调用父类的dealloc(这与init初始化是相反的,且ARC中不需要我们手动调用[super dealloc])。如果父类在dealloc时调用了accessor 并且该accessor被子类重写,就会调用到子类的accessor。而此时子类的dealloc已经被调用了,基于其完整的假设已经不成立,那么再执行子类的代码会存在一定风险,如上例就会崩溃。

另外,在《Effective Objective-C 2.0 编写高质量iOS与OS X代码的52个有效方法》的第31条——在dealloc方法中只释放引用并解除监听一节文中,作者也提到了下面一段话:在dealloc里不要调用属性的存取方法,因为有人可能会覆写这些方法,并于其中做一些无法再回收阶段安全执行的操作(上面已经提到)。此外,属性可能正处于“键值观察”(Key-Value Observation,KVO)机制的监控之下,该属性的观察者(Observer)可能会在属性值改变时“保留”或使用这个即将回首的对象。这种做法会令运行期系统的状态完全失调,从而导致一些莫名其妙的错误。

结论

综上,不能在init和dealloc中使用accessor的原因是由于面向对象的继承、多态特性与accessor可能造成的副作用联合导致的。继承和多态导致在父类的实现中调用accessor可能导致调用到子类重写的accessor,而此时子类部分并未完全初始化或已经销毁,导致原有的假设不成立,从而出现一系列的逻辑问题甚至崩溃。为了更清晰地阐述,以下分别从init和dealloc上举例说明。

结尾

在init和dealloc中使用accessor是存在风险的。但这并不代表百分之百的崩溃或者百分之百的错误。从目前的实验来看,当存在继承时,在init或者dealloc方法中使用accessor会存在很高的风险,此时我们可要小心了。不过,在公司项目中,还是建议大家不要铤而走险,即使现在代码没有问题,难保将来维护或扩展时会出现问题。只有将苹果所说的Don’t Use Accessor Methods in Initializer Methods and dealloc当作一条编程规范,才能从根本上规避这个问题。不过,有些情况我们必须破例,必须访问accessor,比如:待初始化的实例变量声明在超类中,而我们又无法在子类中访问此实例变量的话,那么我们只能通过setter来对实例变量赋值。又比如:如果一个实例变量是lazy的(懒加载),这种情况必须通过getter方法访问属性,否则无法给实例变量赋值。
所以,万事无绝对,我们只有理解了为什么不能在init和dealloc方法中使用accessor才能在各种情况下游刃有余。

文/VV木公子(简书作者)
PS:如非特别说明,所有文章均为原创作品,著作权归作者所有,转载请联系作者获得授权,并注明出处,所有打赏均归本人所有!
如果您是iOS开发者,或者对本篇文章感兴趣,请关注本人,后续会更新更多相关文章!敬请期待!

如果有技术问题,欢迎加入QQ群进行交流,群聊号码:194236752。

参考文章

《Effective Objective-C 2.0 编写高质量iOS与OS X代码的52个有效方法》
为什么不要在init和dealloc函数中使用accessor
Objective-C, 为什么不能在init或是dealloc方法中使用accessor方法
iOS中正确处理dealloc方法
为什么不要在init和dealloc函数中使用accessor
初始化和dealloc方法中不要调用属性的存取方法,而要直接调用 _实例变量

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

推荐阅读更多精彩内容