KVOController是目前OC上用的最多的KVO的第三方库，facebook出品。有以下特点：
- 提供
block方式和selector方式，不需要实现observeValueForKeyPath:ofObject:change:context: - 不需要关心
context，keyPath等参数来判断是哪个观察者的事件 - 在某些情况下，不需要手动移除观察者
本文主要探讨以下内容：
1. 类之间的引用关系
2. 什么情况可以自动移除观察者，不需要开发者关心
3. KVOControllerNonRetaining
4. 实际开发中怎么用更方便
类之间的引用关系
如下图所示：
- 调用者持有
KVOController，并调用KVOController中的observe:keyPath:options:block:方法注册观察者，并在block中处理自己的业务 -
_FBKVOInfo记录调用者的信息，并作为context上下文参数传递。当收到系统回调时取出该上下文，并回调给调用者 -
_FBKVOSharedController是一个单例，真正调用系统addObserver的观察者 -
NSObject+FBKVOController分类中提供两个属性，KVOController和KVOControllerNonRetaining
4.1 这两个属性都是strong引用，即调用者会强引用KVOController
4.2KVOController表示被观察者也是强引用的
4.3KVOControllerNonRetaining表示被观察者是弱引用
类引用关系.png
理想情况下的自动解除KVO
从上图可以看到，KVOController唯一被强引用的地方就是self(observer)。所以，只要self对象被释放，KVOController随后就会被释放。在KVOController的dealloc方法中，调用了unobserveAll，从而实现了自动移除所有观察者的功能。
但现实总是残酷的，总有可能不小心导致self对象释放不了，如：
-
block中使用了self，导致block强引用self，此时调用者就无法自动释放了 - 被观察者是
self，此时KVOController的_objectInfosMap属性中的key即为self，且是强引用的，所以调用者也无法释放
KVOControllerNonRetaining
在上面的被观察者是self的情况时，可能有人注意到了在 NSObject+FBKVOController分类中提供了一个属性：KVOControllerNonRetaining。是不是可以用这个属性就可以做到自动移除观察者了呢？
答案是否定的，这种情况依然无法移除观察者，而且会造成崩溃。
这是因为：
-
KVOControllerNonRetaining表示_objectInfosMap属性中的key为弱引用。 - 此时
observer == observed == self - 当
self被释放时，KVOControllerNonRetaining会执行dealloc中的unobserveAll，由于_objectInfosMap属性中的key为弱引用，NSMapTable会自动清除该键值对，所以永远移除不了观察者。而self对象，由于还依然存在着注册的观察者(_FBKVOSharedController)，最终导致崩溃。
回归实际
从我个人实际的开发角度而言，self通常既是我的观察者，也是我的被观察者，因为就算我观察的不是类本身的属性，也通常是我类的属性的属性。而此时我通常喜欢使用被观察者是self的原因是OC提供的Keypath方式，通过FBKVOKeyPath宏可以方便的进行点.操作，如FBKVOKeyPath(self.clock.date)。
所以FBKVOController对我而言，常用的方式是：
- 使用分类中的
KVOController属性 - 调用带
block的方法 - 手动移除观察者
