KVO原理

当你观察一个对象时，一个新的类会动态被创建。这个类继承自该对象的原本的类，并重写了被观察属性的 setter 方法。自然，重写的 setter 方法会负责在调用原 setter 方法之前和之后，通知所有观察对象值的更改。最后把这个对象的 isa 指针 ( isa 指针告诉 Runtime 系统这个对象的类是什么 ) 指向这个新创建的子类，对象就神奇的变成了新创建的子类的实例。原来，这个中间类，继承自原本的那个类。不仅如此，Apple 还重写了 -class 方法，企图欺骗我们这个类没有变，就是原本那个类。更具体的信息，去跑一下 Mike Ash 的那篇文章里的代码就能明白，这里就不再重复。

1.KVO是基于runtime机制实现的

2.当某个类的属性对象第一次被观察时，系统就会在运行期动态地创建该类的一个派生类，在这个派生类中重写基类中任何被观察属性的setter 方法。派生类在被重写的setter方法内实现真正的通知机制

3.如果原类为Person，那么生成的派生类名NSKVONotifying_Person

4.每个类对象中都有一个isa指针指向当前类，当一个类对象的第一次被观察，那么系统会偷偷将isa指针指向动态生成的派生类，从而在给被监控属性赋值时执行的是派生类的setter方法

5.键值观察通知依赖于NSObject 的两个方法:willChangeValueForKey:和didChangevlueForKey:；在一个被观察属性发生改变之前，willChangeValueForKey:一定会被调用，这就 会记录旧的值。而当改变发生后，didChangeValueForKey:会被调用，继而observeValueForKey:ofObject:change:context:也会被调用。

6.补充：KVO的这套实现机制中苹果还偷偷重写了class方法，让我们误认为还是使用的当前类，从而达到隐藏生成的派生类

重点缺陷：KVO 很强大，没错。知道它内部实现，或许能帮助更好地使用它，或在它出错时更方便调试。但官方实现的 KVO 提供的 API 实在不怎么样。

比如，你只能通过重写-observeValueForKeyPath:ofObject:change:context:方法来获得通知。想要提供自定义的selector，不行；想要传一个block，门都没有。而且你还要处理父类的情况 - 父类同样监听同一个对象的同一个属性。但有时候，你不知道父类是不是对这个消息有兴趣。虽然context这个参数就是干这个的，也可以解决这个问题 - 在-addObserver:forKeyPath:options:context:传进去一个父类不知道的context。但总觉得框在这个 API 的设计下，代码写的很别扭。至少至少，也应该支持block吧。

有不少人都觉得官方 KVO 不好使的。Mike Ash 的Key-Value Observing Done Right，以及获得不少分享讨论的KVO Considered Harmful都把 KVO 拿出来吊打了一番。所以在实际开发中 KVO 使用的情景并不多，更多时候还是用 Delegate 或 NotificationCenter。

请参考：https://www.jianshu.com/p/829864680648