入门篇
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一起撸并趁机要了Foo妹子的微信，并说以后带你飞。其实Bar是为了观察Foo妹子的票圈，随时点赞评论，说不定还有机会趁机表白。于是世界因为Bar的艳遇而运行了一段代码：
|
1
2
3
4
5
6
7
8
9
10
|
- (void)registerAsObserver { /* 当girlFoo的wechat属性改变时通知boyBar */ [girlFoo addObserver:boyBar forKeyPath:@"wechat" options:(NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld) context:NULL];} |
然后在地球上，他俩关系就变了：(画风陡变，前方高能= =)
Foo因为被Bar关注，所以她一定不再是原来那个美女，而是和以前不一样的美女(note:还是继承了原来美女的属性和方法)。她还是拥有原来的容颜和生活习惯，但是现在她在微信上的一举一动都会被Bar所察觉到了。
现在女孩回了家，发了一条微信，内容是“哎，好想找个伴”。在最后
|
1
|
[self didChangeValueForKey:@"wechat"]; |
执行结束的时候小伙就会看到这条消息。
你看KVO的实现方式不是很符合逻辑吗。
有兴趣深入苹果实现方式的同学就看顾神这篇文章吧《如何自己动手实现 KVO》。他的思路是比较官方化的，只是回调用的block。
这里介绍他代码里runtime中关键点实现函数原型：
1.新类被创建并继承自父类：
|
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指向新类
|
1
|
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，首先，添加观察者：
|
1
|
[_tableView addObserver:self forKeyPath:@"contentSize" options:0 context:NULL]; |
很好，实现属性被改变的响应：
|
1
2
3
|
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context { [self configureView];} |
完成！Just kidding.考虑到该方法中可能有其他的observe事务，所以我们要这样修改：
|
1
2
3
4
5
|
- (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来得到的。
因此上面的代码又得变成这样：
|
1
2
3
4
5
|
- (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事务，我们要这样做：
|
1
2
3
4
5
6
7
8
|
- (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都会有这句代码：
|
1
2
3
4
5
|
- (void)dealloc { ... [_tableView removeObserver:self forKeyPath:@"contentSize" context:NULL]; ...} |
那么当JZTableview的对象释放时，他和她父类的dealloc都会被调用，两次相同的removeObserve，自然就Crash了。
还有很多点，不过说出上面4个就差不多了。
那么如何改进？
首先列举缺点：
-
所有的observe处理都放在一个方法里
-
严重依赖于string
-
需要自己处理superclass的observe事务
-
多次相同KVO的removeObserve会导致crash
然后直接上肖哥的一篇博客：一句代码，更加优雅的调用KVO和通知
note：以下内容有兴趣读源码的同学可以看看，否则直接看下一小节吧。
他的代码架构图如下：
每个被观察的对象有一个自己的字典，key为被观察的keyPath，存的值为一个真正的观察者对象Target，即dict[keyPath] = target。一个keyPath对应一个target，每个target有一个KVOBlockSet存放该keyPath下的所有Block。
|
1
2
3
4
|
//监听_objA的name属性[_objA xw_addObserverBlockForKeyPath:@"name" block:^(id obj, id oldVal, id newVal) { NSLog(@"kvo，修改name为%@", newVal);}]; |
缺陷处理结果分析：
所有的observe处理都放在一个方法里。解决。因为回调被分散成块了，不再集中。顾神也是用的块实现的回调。但是用块也不是很统一，但个人觉得还是比原生的好点。
严重依赖于string。未解决。
需要自己处理superclass的observe事务。解决。所有执行了xw_addObserverBlockForKeyPath的块都会被放入KVOBlockSet，对应的keyPath值被改变时会回调对应的所有block，不存在调用super的问题。
多次相同KVO的removeObserve会导致crash。作者用的hook dealloc调剂remove方法达到自动移除功能，目前来看逻辑没问题。
THE END
上文说道Foo妹纸发了一条微信“哎，好想找个伴”。Bar小伙见时机成熟，微信上大胆表白“你看我风流倜傥，随手一敲就是一个十位数内计算器App，你看我做你的鸳鸯咋样？”，Foo妹纸沉默了10分钟回答道：“对不起，我可能更喜欢前端工程师”。
|
1
2
3
|
- (void)resignObserver { [girlFoo removeObserver:boyBar forKeyPath:@"wechat"];} |