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"]; }

 

原文地址:http://www.cocoachina.com/ios/20160803/17265.html