关于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一起撸并趁机要了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"]; }