青少年一定要读的KVO指南

转载请必须注明出处:青少年一定要读的KVO指南

入门篇

KVO是什么?

Key-value observing is a mechanism that allows objects to be notified of changes to specified properties of other objects.

KVO 是 Objective-C 对观察者模式(Observer Pattern)的实现。也是 Cocoa Binding 的基础。当被观察对象的某个属性发生更改时,观察者对象会获得通知,并且得知此时这个属性的具体值。

有点绕口。简单点说,比如你监视你老婆,你老婆跟老王跑了,你会立即知道你老婆是跟老王跑了,并且也会知道上次是跟张三跑的。

KVO如何使用?

最好的使用入门指南:Introduction to Key-Value Observing Programming Guide

基础篇

KVO实现原理 - In Apple Way

苹果的实现方式用猿哥这张经典的图理解起来还不错,但是可能不太适合新手。



KVO的实现是经典的添加中间层的思想,虽然用了isa-swizzling,但是很符合逻辑,并没有什么黑魔法。我们来个生活中的实例讲解下:


我们假设有一个叫Foo的女孩,有一个叫Bar的小伙。最初他俩素未谋面:



有一天小伙Bar去街上打酱油,遇到了美女老板Foo。Bar觉得Foo很漂亮,感觉喜欢上了Foo。于是他趁机要了Foo妹子的微信,说以后长期来打酱油。其实Bar是为了观察Foo妹子的票圈,随时点赞评论,说不定还有机会趁机表白。于是世界因为Bar的艳遇而运行了一段代码:

- (void)registerAsObserver {
    /*
     当girlFoo的wechat属性改变时通知boyBar
     */
    [girlFoo addObserver:boyBar
             forKeyPath:@"wechat"
                 options:(NSKeyValueObservingOptionNew |
                            NSKeyValueObservingOptionOld)
                    context:NULL];
}

然后他俩关系就变了:(画风陡变= =)


Foo因为被Bar关注,所以她一定不再是原来那个美女,而是和以前不一样的美女(note:还是继承了原来美女的属性和方法)。她还是拥有原来的容颜和生活习惯,但是现在她在微信上的一举一动都会被Bar所察觉到了。

现在女孩回了家,发了一条微信,内容是“哎,好想找个伴”。在最后

[self didChangeValueForKey:@"wechat"];

执行结束的时候小伙就会看到这条消息。

你看KVO的实现方式不是很符合逻辑吗。


有兴趣深入苹果实现方式的同学就看顾神这篇文章吧如何自己动手实现 KVO。他的思路是比较官方化的,只是回调用的block。

这里介绍他代码里runtime中关键点实现函数原型:

1.新类被创建并继承自父类:

objc_allocateClassPair(Class superclass, const char *name, size_t extraBytes)

2.在新类上重写setXXX方法

BOOL class_addMethod(Class cls, SEL name, IMP imp, const char *types)

3.女孩Foo的isa指向新类

Class object_setClass(id object, Class cls)

进阶篇

假如面试官问你KVO是怎么实现的,你如上回答可以勉强过关,但是你说出下面的点那就能让他十分满意了,说什么?吐槽。

KVO的缺点

AFNetworking作者Mattt Thompson在《Key-Value Observing》中说:

Ask anyone who’s been around the NSBlock a few times: Key-Value Observing has the worst API in all of Cocoa.

缺点1:所有的observe处理都放在一个方法里

假设我们要观察一个tableView的contentSize,看上去使用KVO是个不错的选择,因为没有其他方法去获知这个属性被改变。Ok,首先,添加观察者:

[_tableView addObserver:self forKeyPath:@"contentSize" options:0 context:NULL];  

很好,实现属性被改变的响应:

- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context {  
    [self configureView];  
}  

完成!Just kidding.考虑到该方法中可能有其他的observe事务,所以我们要这样修改:

- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context {  
    if (object == _tableView && [keyPath isEqualToString:@"contentSize"]) {  
        [self configureView];  
    }  
}  

如果KVO处理的事务繁多,就会造成该方法代码特别长,并且十分不优雅,我们还没辙。

缺点2:严重依赖于string

KVO严重依赖于string,换句话说如果KVO的keyPath如果错误编译器无法查出,比如我们可能会把@“contentSize”写成@“contentsize”,然后你就只能傻傻的找半个小时bug。

因此我们不得不使用NSStringFromSelector(@selector(contentSize))编译器就能判断是否存在这个属性,并且我们也好修改,但是代码这么长,逼死强迫症。

而且,我们也不能用KVO观察多值路径,比如我们观察一个viewController并且想获得scrollView的contentOffset,我们是不能用这样的keyPath:scrollview.contentOffset来得到的。

因此上面的代码又得变成这样:

- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context {  
    if (object == _tableView && [keyPath isEqualToString:NSStringFromSelector(@selector(contentSize))]) {  
        [self configureView];  
    }  
}  

缺点3:需要自己处理superclass的observe事务

对于Objective-C,很多时候runtime系统都会自动帮忙处理superClass的方法,比如dealloc。在ARC下,调用子类的dealloc方法,runtime会自动调用父类的dealloc。但是KVO不会,或者说是不行,因为runtime并不知道父类有没有observe事务,并且由于它是用协议实现的,一次只能触发一个observeValueForKeyPath:ofObject:change:context:方法,所以如果子类和父类都有observe事务,我们要这样做:

- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context {  
    if (object == _tableView && [keyPath isEqualToString:@"contentSize"]) {  
        [self configureView];  
    } else {  
    // 如果我们忘记这句,那么父类不会收到通知
        [super observeValueForKeyPath:keyPath ofObject:object change:change context:context];  
    }  
}  

缺点4:多次相同KVO的removeObserve会导致crash

写过KVO代码的人都知道,对同一个对象执行两次removeObserver操作会导致程序crash。

在同一个文件中执行两次相同的removeObserver属于粗心,比较容易debug出来;但是跨文件执行两次相同的removeObserver就不是那么容易发现了。

我们一般会在dealloc中进行removeObserver操作(这也是Apple所推荐的)。

思考这样一个场景:一个JZTableView继承自UITableview,他们都监听了tableView的contentSize属性,那么UItableview和JZTableView的dealloc都会有这句代码:

- (void)dealloc {
    ...
    [_tableView removeObserver:self forKeyPath:@"contentSize" context:NULL];
    ...
}

那么当JZTableview的对象释放时,他和她父类的dealloc都会被调用,两次相同的removeObserve,自然就Crash了。

还有很多点,不过说出上面4个就差不多了。

那么如何改进?

首先列举缺点:

  1. 所有的observe处理都放在一个方法里
  2. 严重依赖于string
  3. 需要自己处理superclass的observe事务
  4. 多次相同KVO的removeObserve会导致crash

然后直接上肖哥的一篇博客:一句代码,更加优雅的调用KVO和通知


note:以下内容有兴趣读源码的同学可以看看,否则直接看下一小节吧。

他的代码架构图如下:


每个被观察的对象有一个自己的字典,key为被观察的keyPath,存的值为一个真正的观察者对象Target,即dict[keyPath] = target。一个keyPath对应一个target,每个target有一个KVOBlockSet存放该keyPath下的所有Block。

//监听_objA的name属性
[_objA xw_addObserverBlockForKeyPath:@"name" block:^(id obj, id oldVal, id newVal) {
    NSLog(@"kvo,修改name为%@", newVal);
}];

缺陷处理结果分析:

  1. 所有的observe处理都放在一个方法里。

    解决。因为回调被分散成块了,不再集中。顾神也是用的块实现的回调。但是用块也不是很统一,但个人觉得还是比原生的好点。

  2. 严重依赖于string。

    未解决。

  3. 需要自己处理superclass的observe事务。

    解决。所有执行了xw_addObserverBlockForKeyPath的块都会被放入KVOBlockSet,对应的keyPath值被改变时会回调对应的所有block,不存在调用super的问题。

  4. 多次相同KVO的removeObserve会导致crash。

    作者用的hook dealloc调剂remove方法达到自动移除功能,目前来看逻辑没问题。


THE END

上文说道Foo妹纸发了一条微信“哎,好想找个伴”。Bar小伙见时机成熟,微信上大胆表白“你看我风流倜傥,随手一敲就是一个十位数内计算器App,你看我做你的鸳鸯咋样?”,Foo妹纸沉默了10分钟回答道:“对不起,我可能更喜欢前端工程师”。

- (void)resignObserver {
    [girlFoo removeObserver:boyBar forKeyPath:@"wechat"];
}

Done

参考资料:

如何自己动手实现 KVO
张不坏-深入理解KVO
KVO Considered Harmful
一句代码,更加优雅的调用KVO和通知
Introduction to Key-Value Observing Programming Guide

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

推荐阅读更多精彩内容