8.1: kvo 与 kvc 展开
1:KVO
KVO(Key-Value-Observing)键值观察，其技术原理就是通过 isa waizzle 技术添加被观察对象中间类，并重新写相应的方法来监听键值变化。当被观察的对象属性被修改后，则对象回接收到通知，即每次指定的被观察对象的属性被修改后，kvo就会自动通知相应的观察者。
isa swizzle 不同于method swizzle,其交换的是isa，对象的isa 指针式定义了它的类，所以ISA swizzling 指修改对象所指向的类，KVO则是使用该技术实现的,还有zombie objects检测也用到了该技术，而method swizzle交换的是method
2:KVO引起的crash 情况如下
2.1* observer 已销毁，但是未及时移除监听；
2.2* addObserver 与 removeObserver 不匹配
1:移除了未注册的观察者，但是未及时移除监听
2:重复移除多次，移除次数多于添加次数，导致崩溃。
3:重复添加多次，虽然不会崩溃，但是发生改变时，也同时会被观察多次。
2.3*添加了观察者，但未实现observerValueForKeyPath:ofObject:change:context: 方法，导致崩溃.
2.4*添加或移除时 keypath == nil ，导致崩溃.
通过如上场景就可以发现其实kvo 崩溃的主要原因是观察者管理混乱，特别是观察者关系复杂时，开发者容易导致混乱。
如下图所示:
那如何管理呢？ 既然观察者都是开发者来管理，由人来管理必然会出现失误的时候，那我们是否能通过一个代理对象来管理？
答案：yes！
3:具体实现如下:
1:通过Method Swizzle方法调配交换KVO相应的方法到NSObject基类，如下：
2: 然后在观察者和被观察者之间建立一个 KVODelegate 对象，
两者之间通过 KVODelegate 对象 建立联系。然后在添加和移除操作时，
将 KVO 的相关信息例如 observer、keyPath、options、context 保存为 KVOInfo 对象，并添加到 KVODelegate 对象 中对应 的 关系哈希表 中，对应原有的添加观察者。
3: 在添加和移除操作的时候，
利用 KVODelegate 对象 做转发，
把真正的观察者变为 KVODelegate 对象，
而当被观察者的特定属性发生了改变(会被调用到observeValueForKeyPath:ofObject)，
再由 KVODelegate 对象分发到原有的观察者上。
4:为了避免被观察者提前被释放，
被观察者在 dealloc 时仍然注册着 KVO 导致崩溃。
BayMax 系统还利用 Method Swizzling 实现了自定义的 dealloc，
在系统 dealloc 调用之前，将多余的观察者移除掉。
8.1.2:KVC
KVC(Key Value Coding)键值编码，提供一种机制来间接访问对象的属性，而不是通过Setter/Getter方法进行访问。
通常导致崩溃的原因不外乎键值设置不正确，如下：
1. key 不是对象的属性
2. keyPath 不正确
3. value 为 nil，为非对象设值
4. key 为 nil
那如何防护呢，熟悉KVC机制的同学肯定清楚：runtime提供了相应的补救措施来避免应用崩溃，包括如下：
setValue:forKey: 找不到相应的key会调用 setValue: forUndefinedKey: 方法；
valueForKey: 找不到相应的keyPath会调用 valueForUndefinedKey: 方法；
setValue:forKey:添加value为nil方法，会调用setNilValueForKey方法来避免；
因此，针对上面崩溃的前3中场景，就可以通过分辨实现上述三种方法来避免，但对于key为nil的情况该如何防护呢？
这里直接告诉答案：毅然是通过熟悉的Method Swizzle来替换原有的
setValue:forKey:方法，
并判断传入的key是否为nil。具体代码如下：
