程序员

青少年一定要读的KVO指南

2016-07-29  本文已影响208人  nlpjoe

转载请必须注明出处：青少年一定要读的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

上一篇下一篇

猜你喜欢

热点阅读