• iOS用什么方式实现对一个对象的KVO？(KVO的本质是什么？)

利用RuntimeAPI动态生成一个子类(NSKVONotifying_XXX对象)，并且让instance对象的isa指向这个全新的子类，并且这个类继承于原有的类，比如MJPerson。
当修改instance对象的属性时，会调用Foundation的_NSSetXXXValueAndNotify函数 （可以窥探Foundation里面的内容）

willChangeValueForKey:
父类原来的setter
didChangeValueForKey:

  1. //KVO生成的伪代码
  2. @implementation NSKVONotifying_MJPerson
  4. - (void)setAge:(int)age
  5. {
  6.     _NSSetIntValueAndNotify();
  7. }
  9. // 伪代码
  10. void _NSSetIntValueAndNotify()
  11. {
  12.     [self willChangeValueForKey:@"age"];
  13.     [super setAge:age];
  14.     [self didChangeValueForKey:@"age"];
  15. }
  17. - (void)didChangeValueForKey:(NSString *)key
  18. {
  19.     // 通知监听器，某某属性值发生了改变
  20.     [oberser observeValueForKeyPath:key ofObject:self change:nil context:nil];
  21. }
  23. @end

内部会触发监听器（Oberser）的监听方法( observeValueForKeyPath:ofObject:change:context:）

KVO - 图1

  • 如何手动触发KVO？

手动调用willChangeValueForKey:和didChangeValueForKey:

  • 直接修改成员变量会触发KVO么？

类似self.person1->age = 2是不会触发KVO的，KVO的本质是调用set方法。

不会触发KVO

  • addObserver:forKeyPath:options:context:各个参数的作用分别是什么，observer中需要实现哪个方法才能获得KVO回调？

  1. // 添加键值观察
  2. /*
  3. 1 观察者，负责处理监听事件的对象
  4. 2 观察的属性
  5. 3 观察的选项
  6. 4 上下文
  7. */
  8. [self.person addObserver:self forKeyPath:@"name" options:NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld context:@"Person Name"];
  9. observer中需要实现一下方法：
  11. // 所有的 kvo 监听到事件，都会调用此方法
  12. /*
  14. 观察的属性
  15. 观察的对象
  16. change 属性变化字典（新／旧）
  17. 上下文，与监听的时候传递的一致
  18. */
  20. (void)observeValueForKeyPath:(NSString )keyPath ofObject:(id)object change:(NSDictionary )change context:(void *)context;

  • 如何自己动手实现 KVO

《如何自己动手实现 KVO》
KVO for manually implemented properties

  • apple用什么方式实现对一个对象的KVO？

Apple 的文档对 KVO 实现的描述：

Automatic key-value observing is implemented using a technique called isa-swizzling… When an observer is registered for an attribute of an object the isa pointer of the observed object is modified, pointing to an intermediate class rather than at the true class …

从Apple 的文档可以看出：Apple 并不希望过多暴露 KVO 的实现细节。不过，要是借助 runtime 提供的方法去深入挖掘，所有被掩盖的细节都会原形毕露：

当你观察一个对象时，一个新的类会被动态创建。这个类继承自该对象的原本的类，并重写了被观察属性的 setter 方法。重写的 setter 方法会负责在调用原 setter 方法之前和之后，通知所有观察对象：值的更改。最后通过 isa 混写（isa-swizzling） 把这个对象的 isa 指针 ( isa 指针告诉 Runtime 系统这个对象的类是什么 ) 指向这个新创建的子类，对象就神奇的变成了新创建的子类的实例。我画了一张示意图，如下所示：

enter image description here

KVO 确实有点黑魔法：

Apple 使用了 isa 混写（isa-swizzling）来实现 KVO 。

下面做下详细解释：

键值观察通知依赖于 NSObject 的两个方法: willChangeValueForKey: 和 didChangevlueForKey: 。在一个被观察属性发生改变之前， willChangeValueForKey: 一定会被调用，这就会记录旧的值。而当改变发生后， observeValueForKey:ofObject:change:context: 会被调用，继而 didChangeValueForKey: 也会被调用。可以手动实现这些调用，但很少有人这么做。一般我们只在希望能控制回调的调用时机时才会这么做。大部分情况下，改变通知会自动调用。

比如调用 setNow: 时，系统还会以某种方式在中间插入 wilChangeValueForKey: 、 didChangeValueForKey: 和 observeValueForKeyPath:ofObject:change:context: 的调用。大家可能以为这是因为 setNow: 是合成方法，有时候我们也能看到有人这么写代码:

  2. (void)setNow:(NSDate *)aDate {
  3.     [self willChangeValueForKey:@"now"]; // 没有必要
  4.     _now = aDate;
  5.     [self didChangeValueForKey:@"now"];// 没有必要
  6. }

这完全没有必要，不要这么做，这样的话，KVO代码会被调用两次。KVO在调用存取方法之前总是调用 willChangeValueForKey: ，之后总是调用 didChangeValueForkey: 。怎么做到的呢?答案是通过 isa 混写（isa-swizzling）。第一次对一个对象调用 addObserver:forKeyPath:options:context: 时，框架会创建这个类的新的 KVO 子类，并将被观察对象转换为新子类的对象。在这个 KVO 特殊子类中， Cocoa 创建观察属性的 setter ，大致工作原理如下:

  1. (void)setNow:(NSDate *)aDate {
  2.     [self willChangeValueForKey:@"now"];
  3.     [super setValue:aDate forKey:@"now"];
  4.     [self didChangeValueForKey:@"now"];
  5. }

这种继承和方法注入是在运行时而不是编译时实现的。这就是正确命名如此重要的原因。只有在使用KVC命名约定时，KVO才能做到这一点。

KVO 在实现中通过 isa 混写（isa-swizzling） 把这个对象的 isa 指针 ( isa 指针告诉 Runtime 系统这个对象的类是什么 ) 指向这个新创建的子类，对象就神奇的变成了新创建的子类的实例。这在Apple 的文档可以得到印证：

Automatic key-value observing is implemented using a technique called isa-swizzling… When an observer is registered for an attribute of an object the isa pointer of the observed object is modified, pointing to an intermediate class rather than at the true class …

然而 KVO 在实现中使用了 isa 混写（ isa-swizzling） ，这个的确不是很容易发现：Apple 还重写、覆盖了 -class 方法并返回原来的类。 企图欺骗我们：这个类没有变，就是原本那个类。。。

但是，假设“被监听的对象”的类对象是 MYClass ，有时候我们能看到对 NSKVONotifying_MYClass 的引用而不是对 MYClass 的引用。借此我们得以知道 Apple 使用了 isa 混写（isa-swizzling）。具体探究过程可参考 这篇博文 。

那么 wilChangeValueForKey: 、 didChangeValueForKey: 和 observeValueForKeyPath:ofObject:change:context: 这三个方法的执行顺序是怎样的呢？

wilChangeValueForKey: 、 didChangeValueForKey: 很好理解，observeValueForKeyPath:ofObject:change:context: 的执行时机是什么时候呢？

先看一个例子：

  1. (void)viewDidLoad {
  2.     [super viewDidLoad];
  3.     [self addObserver:self forKeyPath:@"now" options:NSKeyValueObservingOptionNew context:nil];
  4.     NSLog(@"1");
  5.     [self willChangeValueForKey:@"now"]; // “手动触发self.now的KVO”，必写。
  6.     NSLog(@"2");
  7.     [self didChangeValueForKey:@"now"]; // “手动触发self.now的KVO”，必写。
  8.     NSLog(@"4");
  9.     }
  10.     (void)observeValueForKeyPath:(NSString )keyPath ofObject:(id)object change:(NSDictionary<NSString ,id> )change context:(void )context {
  11.     NSLog(@"3");
  12. }

顺序似乎是 wilChangeValueForKey: 、 observeValueForKeyPath:ofObject:change:context: 、 didChangeValueForKey: 。

其实不然，这里有一个 observeValueForKeyPath:ofObject:change:context: , 和 didChangeValueForKey: 到底谁先调用的问题：如果 observeValueForKeyPath:ofObject:change:context: 是在 didChangeValueForKey: 内部触发的操作呢？ 那么顺序就是： wilChangeValueForKey: 、 didChangeValueForKey: 和 observeValueForKeyPath:ofObject:change:context:
不信你把 didChangeValueForKey: 注视掉，看下 observeValueForKeyPath:ofObject:change:context: 会不会执行。

了解到这一点很重要。