<!doctype html>
KVOController 是由 facebook 开源的 kvo 组件，其特点是简单易用且安全。
KVO现状
kvo 全称 key-value observing，由 cocoa 框架提供的支持观察者模式的技术，结合 Objective-C 非常易用，在很多场合都可以有效地替换 NSNotificationCenter。但其也有一些致命的缺点，导致很容易引发 crash。其使用规则如下：
- addObserver 和 removeObserver 必须配对出现。
仅支持以下用法：
[observee addObserver...]; //do something [observee removeObserver...];以下用法很大可能会出引起 crash，
[observee addObserver...]; //do something [observee removeObserver...]; [observee addObserver...];[observee addObserver...]; //do something [observee removeObserver...]; [observee removeObserver...];[observee removeObserver...];[observee addObserver...]; - addObserver 和 removeObserver 按照先后次序调用。
其调用顺序如下所示：
[observee addObserver...]; //do something [observee removeObserver...];必须先添加观察者，然后处理业务，最后完成后移除观察者，释放掉观察者。以下用法将导致 Crash：
[observee removeObserver...]; //do something [observee addObserver...];
可以看出，kvo 的使用要求很多，稍有不慎就会导致crash。甚至很多时候明明代码已经做到了配对出现且按次序调用，可是还是发现有相关的 crash，就原因来分，有以下几类：
- 多线程导致软件运行时环境复杂化。
- 观察者意外地过早释放。
这些情况都会导致代码的实际运行情况跟我们预期的差别很多，从而产生令人讨厌的却不可避免的 crash。根据以上分析可知，kvo 导致的 crash 有两大类：
- 多次添加或者移除同一观察者消息，或者在添加之前移除。
- 发送回调消息到已释放的观察者。
KVOController
面对 cocoa 提供的 kvo 技术存在的各种坑，大家各显神通，提供了各种各样的替代方案，包括作者本人几年前也实现过一个，直到 KVOController 问世。该方案不仅简单易用，且实现也相对简单。
KVOController 优势
实现单例 _FBKVOSharedController 注册和转发 kvo 消息，作为事实的观察者和消息中转站，避免发送消息给已释放的观察者。并且可以做一些检查和过滤操作，避免观察者多次添加和移除针对同一消息的关注，从而避免 crash 问题。KVOController 具有以下特点：
- 提供更加安全的借口。
通过解决addObserver 和 removeObserver 必须配对且按次序调用的问题，提供了一套更安全的接口。并在观察者释放时释放掉对应的 KVOController，避免发消息给已释放观察者。
- 提供更易用的接口。
提供对 block 回调和自定义 selector 的支持，保持了灵活和强大。
- 提供线程安全的接口。
KVOController 探究
KVOController 用法
KVOController 使用方式如下(本文采用ARC方式编写代码，如采用MRR请自行管理对象生命期)：
FBKVOController *KVOController = [FBKVOController controllerWithObserver:self];
_KVOController = KVOController;
//observe clock.date property
[_KVOController observe:clock keyPath:@"date" options:NSKeyValueObservingOptionInitial|NSKeyValueObservingOptionNew block:^(ClockView *clockView, Clock *clock, NSDictionary *change) {
clockView.date = change[NSKeyValueChangeNewKey];
}];
这便是 KVOController 的一个完整用法，甚至不需要移除观察者，使用相当方便。_KVOController 为观察者对象的一个实例变量。
KVOController 甚至提供了一种更简便的用法，简化使用方式，如下：
[self.KVOController observe:clock keyPath:@"date" options:NSKeyValueObservingOptionInitial|NSKeyValueObservingOptionNew action:@selector(updateClockWithDateChange:)];
甚至不需要创建 KVOController，直接使用 KVOController 提供的扩展属性即可。如何实现的呢？大家都猜到了，KVOController 为 NSObject 添加了一个包含 KVOController 方法的 category，采用 lazy creation 方式创建一个 KVOController 对象。其实现如下：
- (FBKVOController *)KVOController {
id controller = objc_getAssociatedObject(self, NSObjectKVOControllerKey);
// lazily create the KVOController
if (nil == controller) {
controller = [FBKVOController controllerWithObserver:self];
self.KVOController = controller;
}
return controller;
}
KVOController 实现方式
KVOController 消息流
那么问题来了，KVOController是如何做到如此简便的使用方式且同时还保证了安全性？这就要从KVOController的实现分析，其UML类图如下：
从图中可知，其工作流程如下：
- observer 调用 FBKVOController 的 observe 方法注册观察者。
- FBKVOController 处理观察者信息，并将其封装为
_FBKVOInfo。FBKVOController过滤重复的或者未注册过的观察消息 。_FBKVOInfo 定义如下：@interface _FBKVOInfo : NSObject @end @implementation _FBKVOInfo { @public __weak FBKVOController *_controller; NSString *_keyPath; NSKeyValueObservingOptions _options; SEL _action; void *_context; FBKVONotificationBlock _block; }可以看出
_FBKVOInfo定义了跟观察者相关的一些信息，包括 消息、回调函数以及维护对 FBKVOController 的弱引用，_FBKVOInfo与观察者消息一一对应，即每一个观察者注册信息对应一个 _FBKVOInfo 实例。这样可以做到观察者释放时不再向其发送消息，避免 crash。 - FBKVOController 调用中转站 _FBKVOSharedController 的 observe 方法。
- _FBKVOSharedController 向 observee 完成真正的观察者注册。
- 关注的 keyPath 发生改变时，observee 向 _FBKVOSharedController 发送 kvo 通知。
_FBKVOSharedController根据 _FBKVOInfo 判断观察者是否存活，若存活，回调 observer。否则吞没该消息。- observer 根据收到的回调完成对应的操作。
observer 与 FBKVOController 为一一对应关系，即一个观察者实例对应一个 FBKVOController 实例，而所有的观察者注册和回调工作都有 _FBKVOSharedController 这个单例完成，其将在软件的整个生命周期内存活。
弱引用
如何避免发送消息给已释放未移除观察者信息的观察者呢？答案就是弱引用！以下代码为 KVOController 的实现片段：
@interface FBKVOController : NSObject
@property (atomic, weak, readonly) id observer;
@end
@implementation FBKVOController
- (void)dealloc {
[self unobserveAll];
}
@end
从中可明显地看出：
- KVOController 维护了一个对观察者的弱引用。
- KVOController 释放时会移除其注册的观察者消息。
结合 _FBKVOInfo 维护的指向 FBKVOController 的弱引用，即使观察者已释放而 KVOController 未释放，由于其维护的是一个指向观察者的弱引用，可以有效地避免发消息给已经释放掉的观察者。由于观察者与 KVOController 一一对应的关系，通常观察者释放时，也会释放掉 KVOController 实例，则会隐式地移除观察者消息。
消息过滤
那么 KVOController 针对多次注册或者移除同一观察者消息的问题又是如何解决的呢？答案就是消息过滤！
如下所示，为 FBKVOController 的 observe 代码片段，通过 _FBKVOInfo *existingInfo = [infos member:info];可知，首先判断是否已经包含对应观察者消息，如果包含则直接返回。
- (void)_observe:(id)object info:(_FBKVOInfo *)info {
OSSpinLockLock(&_lock);
NSMutableSet *infos = [_objectInfosMap objectForKey:object];
_FBKVOInfo *existingInfo = [infos member:info];
if (nil != existingInfo) {
NSLog(@"observation info already exists %@", existingInfo);
OSSpinLockUnlock(&_lock);
return;
}
且 FBKVOController 内部采用 NSMapTable 作为容器存储被观察者和对应的观察者信息，NSMapTable 类似于 NSDictionary，但更加灵活和强大，支持添加 NULL 指针、void * 以及 weak 对象等，即允许指定加入容器中项的内存管理方式和类型行为，比如可以指定内存管理方式采用 copy、weak 和 strong 中的一种，还可以设定加入项的相等判断方式，比如指针或者 isEqual: 方法。类似 NSMapTable 的容器还有 NSHashTable 和 NSPointerArray，分别对应于 NSSet 和 NSArray。
FBKVOController 中 NSMapTable的构造方式如下：
NSPointerFunctionsOptions keyOptions = retainObserved ? NSPointerFunctionsStrongMemory|NSPointerFunctionsObjectPointerPersonality : NSPointerFunctionsWeakMemory|NSPointerFunctionsObjectPointerPersonality;
_objectInfosMap = [[NSMapTable alloc] initWithKeyOptions:keyOptions valueOptions:NSPointerFunctionsStrongMemory|NSPointerFunctionsObjectPersonality capacity:0];
根据传入参数retainObserved可以决定是否对被观察者维持一个强引用，对 NSPointerFunctionsStrongMemory 等的详细解释参考 Pointer Function Options。NSPointerFunctionsStrongMemory 表示对加入的项维持强引用，NSPointerFunctionsWeakMemory 则相反。而 NSPointerFunctionsObjectPointerPersonality 通过指针判断加入的项是否相等，NSPointerFunctionsObjectPersonality 则通过加入对象的 isEqual: 方法判断。其中 key 为被观察者，value 为 _FBKVOInfo 实例，也即观察者消息信息。
KVOController通过提供 _FBKVOSharedController 注册和转发消息，避免观察者直接使用 kvo，通过这个中间层达到了隔离的效果。并且提供一个跟观察者一一对应的 FBKVOController，过滤掉容易出错的注册和移除消息的请求，且 FBKVOController 生命周期跟观察者绑定，则观察者释放时，由 FBKVOController 生成的实例也被释放，从 _FBKVOSharedController 移除对应的观察者信息，避免发消息给已释放观察者导致的crash。