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。