iOS_kvo

KVO，全称为Key-Value Observing，是iOS中的一种设计模式，用于检测对象的某些属性的实时变化情况并作出响应.KVO是实现Cocoa Bindings的基础。在其他语言中，这种观察者模式通常需要单独实现，而在Objective-C中，通常无须增加额外代码即可使用。

这是怎么实现的呢？其实这都是通过Objective-C强大的运行时(runtime)实现的。当你第一次观察某个object 时，runtime会创建一个新的继承原先class的subclass。在这个新的class中，它重写了所有被观察的key，然后将object的isa指针指向新创建的class（这个指针告诉Objective-C运行时某个object到底是哪种类型的object）。所以object神奇地变成了新的子类的实例。

这些被重写的方法实现了如何通知观察者们。当改变一个key时，会触发setKey方法，但这个方法被重写了，并且在内部添加了发送通知机制。（当然也可以不走setXXX方法，比如直接修改iVar，但不推荐这么做）。

有意思的是：苹果不希望这个机制暴露在外部。除了setters，这个动态生成的子类同时也重写了-class方法，依旧返回原先的class！如果不仔细看的话，被KVO过的object看起来和原先的object没什么两样。

但是里面有多个地方存在crash的危险。

首先，假设我们的目标是在一个UITableViewController内对tableview的contentOffset进行实时监测，很容易地使用KVO来实现为：

1	在初始化方法中加入：[_tableView addObserver:self forKeyPath:@"contentOffset" options:NSKeyValueObservingOptionNew context:nil];

1	在dealloc中移除通知：[_tableView removeObserver:self forKeyPath:@"contentOffset" context:nil];

添加默认的响应回调方法：

1 2 3 4 5

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

好了，KVO实现就到此完美结束了，拜拜。。。开个玩笑，肯定没这么简单的，这样的代码太粗糙了，当你在controller中添加多个KVO时，所有的回调都是走同上述函数，那就必须对触发回调函数的来源进行判断。判断如下：

1 2 3 4

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

1	[self doSomethingWhenContentOffsetChanges];

1

} }

你以为这样就结束了吗？答案是否定的！我们假设当前类(在例子中为UITableViewController)还有父类，并且父类也有自己绑定了一些其他KVO呢？我们看到，上述回调函数体中只有一个判断，如果这个if不成立，这次KVO事件的触发就会到此中断了。但事实上，若当前类无法捕捉到这个KVO，那很有可能是在他的superClass，或者super-superClass...中，上述处理砍断了这个链。合理的处理方式应该是这样的：

1 2 3 4

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

1	[self doSomethingWhenContentOffsetChanges];

1	} else { <br>        [super observeValueForKeyPath:keyPath ofObject:object change:change context:context]; <br>}<br>}

这样就结束了吗？答案仍旧是否定的。潜在的问题有可能出现在dealloc中对KVO的注销上。KVO的一种缺陷(其实不能称为缺陷，应该称为特性)是，当对同一个keypath进行两次removeObserver时会导致程序crash，这种情况常常出现在父类有一个kvo，父类在dealloc中remove了一次，子类又remove了一次的情况下。不要以为这种情况很少出现！当你封装framework开源给别人用或者多人协作开发时是有可能出现的，而且这种crash很难发现