KVO是OC对观察者设计模式的一种实现。
KVO提供一种机制，指定一个被观察对象，当对象某个属性发生改变时，对象会获取通知，并作出相应的处理。
在MVC设计架构下的项目，KVO机制很适合实现mode模型和view视图之间的通讯。
实现原理：
KVO就是基于runtime机制实现的，当某个类的对象第一次被观察时，系统就会在运行期动态地创建该类的一个派生类，在这个派生类中重写基类中任何被观察属性的setter方法。
派生类在被重写的setter方法实现真正的通知机制。
1.与KVC的不同：
KVC键值编码，一个的Protocol，使用字符串(键)访问一个对象实例变量的机制。而不是通过调用setter，getter方法等显示的存取方式去访问。
KVO键值监听，它提供一种机制，当指定的对象的属性被修改后，对象就会接受到通知，前提是执行了setter方法，或者使用了KVC赋值。
2.与notification的区别？
notification比KVO多了发送通知的一步。
两者都是一对多，但是对象之间直接的交互，notification明显得多，需要notificationCenter来做为中间交互。而KVO是设置观察者->处理属性变化，至于中间通知这一环，则隐秘多了。
notification的有点是监听不局限于属性的变化，还可以对多种多样的状态变化进行监听，监听范围广，例如键盘，前后台等系统通知的使用也更显灵活方便。
3.与delegate的不同？
和delegate一样，KVO和NSNotification的作用都是类与类之间的通信。
但是与delegate不同的是：
这两个都是负责发送接收通知，剩下的事情有系统处理，所以
不用返回值；而delegate则需要通信的对象通过代理联系；
delegate只是一对一，而这两个可以一对多
总结:
对比其他的回调方式，KVO机制的运行时的实现，更多的由系统支持，相比notification、delegate等更简洁些，并且能够提供观察属性的最新值以及原始值；但是相应的在创建子类、重写方法等等方面的内存消耗是很巨大的。所以对于两个类之间的通信，我们可以根据实际开发的环境采用不同的方法，使得开发的项目更加简洁实用。
另外需要注意的是，由于这种继承方式的注入是在运行时而不是编译时实现的，如果给定的实例没有观察者，那么KVO不会有任何开销，因为此时根本就没有KVO代码存在。但是即使没有观察者，委托和NSNotification还是得工作，这也是KVO此处零开销观察的优势。
