【一】 KVO过程：

1、新建了一个Person类，包含一个garde属性

2、在需要检测改属性变化的地方添加监听：

3、使用-点击屏幕改变改属性值，可以看到触发了observeValueForKeyPath：方法。

【二】分析：

可以看到整个过程最重要是addObserver：方法，并且这是一个对象方法，也就是说系统内部应该是对这个对象（instance）做了一些处理。

控制台打印看，从对象的isa，类型都看不出什么问题。我们知道KVO的实现过程本来就是利用了Runtime动态性。所以只能引入<objc/runtime.h>再试下。

（为了做比较，我多创建了一个person2，没有添加KVO）

这里就可以看出来了。person1的isa指向的基类已经不再是Person了，而是一个我们不认识的NSKVONotifying_Person。

NSKVONotifying_Person这个类怎么来的？为什么刚才用[self.person1 class]又不行？

【三】过程：

带着疑问手动去创建了NSKVONotifying_Person这个类,结果发现他不行了。

这就说明NSKVONotifying_Person这个类是系统动态创建的，如果我们强行创建，会影响到系统本来的方法、功能。

但是这也说明了整个KVO的实现过程是在NSKVONotifying_Person这个类里面，而刚才我们属性的改变，也只是调用了一下set方法，所以NSKVONotifying_Person肯定重写了set方法。

这个NSKVONotifying_Person跟我们Person有什么关系？ ——这个NSKVONotifying_Person其实是上面我们实例对象person1的isa所指向基类的派生子类（也就是Person的子类）

如何去验证？

我们知道实例对象的isa指向基类，基类的isa指向元类，元类的isa指向基类的元类。

所以可以通过person1的isa找到其基类（前面我们已经试过是NSKVONotifying_Person），再看其基类的superclass,如果其基类的superclass值为Person。就可以验证到NSKVONotifying_Person是Person的子类。

过程：

这里可以看到perosn1的isa就是NSKVONotifying_Person也就是打印的p1的值。

按道理，只要知道p1的superclass是什么就可以了。

但是：p1是Class类型的结构体，直接访问是访问不了。

这里对应查看了苹果的objc库源码，看到Class结构体里面包含的信息字段有这些：

那么也就说，可以尝试自行创建一个类似的结构体，然后将isa、superclass这些暴露出来，将p1强行转为我们自定义的结构体。目的：为了能够访问、查看isa、superclass的值。

这里可以清晰的看到类对象p1的基类是NSKVONotifying_Person，NSKVONotifying_Person的父类就是Person。也就验证了上面的说法。

【四】NSKVONOtifyingPerson做的大概过程：

整个重写的大概过程引用网上的说明：

1、重写监听属性的set方法，set方法里面调用 _NSSetIntValueAndNotify

2、_NSSetIntValueAndNotify里面做三件事情：调用willChangeValueForKey: 、调用原来的setter实现、调用didChangeValueForKey

3、而didChangeValueForKey内部会调用observer的observeValueForKeyPath:ofObject:change:context:方法

关于调用顺序的问题，这里在Person类验证了一下：

这里可以看到在打印了didChangeValueForKey---begin:之后，就已经通知到值改变了，然后再是打印didChangeValueForKey---end:，说明的确是在

[super didChangeValueForKey:key];

这里通知observeValueForKeyPath:ofObject:change:context的

【五】问题

 那么众观整个KVO的流程，核心方法就是这个set方法，也就是说如果属性根本没有set方法，那就应该触发不了kvo。

 结果也像预期一样，就算修改了grade属性的值，也不会有打印，kvo不会触发

 另外，知道了这个过程，想要手动去触发这个kvo，也是可以的。

结果：这里我并没有修改grade的值，只是调用了willChangeValueForkey、didChangeValueForkey，可以看到同样也触发了KVO

 前面说到了是在didChangeValueForkey方法里面去通知observeValueForKeyPath:ofObject:change:context的。那如果单单只调用didChangeValueForkey这个方法会触发KVO吗？

结果：这里可以看到如果只是调用了didChangeValueForkey并不会触发KVO，猜测在didChangeValueForkey里面去调用observeValueForKeyPath:ofObject:change:context之前系统也会验证willChangeValueForkey是否被调用过，如果willChangeValueForkey调用了，才会触发KVO

 在最开始的时候，有一个问题：[person1 class]、object_getClass(self.person1)打印出来的结果是不一样的：

一个是NSKVONotifying_Person、一个Person。

这是因为在NSKVONotifying_Person里面也重写了class这个方法，而且是直接返回[super class]，所以我们通过

【self.person1 class】拿到的就是Person了，其实就是为了隐藏NSKVONotifying_Person的存在。

注意：以上的NSKVONotifying_Person其实是NSKVONotifying_XXX的一个例子。具体需要看你监听属性的基类的类名