对于有iOS开发经验的同学来说KVO不在陌生，但是有好多同学只是停留在会用的基础上，但是对于其的深层原理还是不怎么了解，接下来我们来深入的认识一下KVO的本质。
KVO被我们经常称之为：键值监听，可以用于监听某个对象的属性值的改变。接下来我们创建工程先实使用一下：
#import "ViewController.h"
@interface Person :NSObject
@property (assign, nonatomic)int age;
@end
@implementation Person
- (void)setAge:(int)age{ _age =age;}
@end
@interface ViewController ()
@end
@implementation ViewController
- (void)viewDidLoad {
[super viewDidLoad];
Person *person =[Person new];
person.age =10;
[person addObserver:self forKeyPath:@"age" options:NSKeyValueObservingOptionNew |NSKeyValueObservingOptionOld context:nil];
person.age =12;}
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context{
NSLog(@"keyPath :%@----change:%@",keyPath,change);
}
@end
创建了Person对象，一个age属性，将person对象被添加为controller监听age属性的变化，打印出来：
2018-04-21 22:33:44.652460+0800 kvo[5397:332335] keyPath :age----change:{
kind = 1;
new = 12;
old = 10;
}
上边就是一个KVO使用的全部过程，接下来我们分析：在person的age属性被改变的时候其实是调用了它的set方法，但是set方法里面又没有额外的代码执行，那么它是什么时候对controller对象进行通知的呢？有基础的同学可能就知道那么它肯定是在运行时做了一些事情，在runtime的时候对person对象做了一些东西才会被监听的。接下来我们对程序打两个个断点看：
那么看到这幅图，相信了解OC对象实质的同学都已经看到了现在person对象的isa的指向在第一个断点和第二个断点发生了变化，而且person对象的地址也发生了变化，我靠好神奇啊！是不是觉得背后有一双手在person对象添加键值监听的时候把的person对象给改变了变成了NSKVONotifying_Person类，答案是确实这样！
来分析：在person为被加入监听的时候其实它的调用时这样的：
而被添加监听之后其实是这样的：
从上图和我们的断点中看出person对象在添加监听之后就衍生出了一个Person的子类NSKVONotifying_Person，它的内部信息如图所示，所以调用赋值的过程其实是调用的NSKVONotifying_Person的set方法，它的内部调用了一个C语言的私有函数_NSSstIntValueAndNotify()（中间int会根据你的属性的类型做改变如：_NSSstCharValueAndNotify()...）这个函数，但是这个函数其实内部会调用：
只有当will...和didChange...都调用的时候就会通知监听者，但是是在didChange...中通知的，而且如果在controller中直接实现这两个方法，在属性值不改变的情况下也会出发监听回调，可以作为手动出发监听的回调。
接下来我们验证一下上边的结论，查看一下添加监听之后两个对象的类对象的方法都有什么？
Person *p1 = [[Person alloc] init];
p1.age = 1;
Person *p2 = [[Person alloc] init];
p2.age = 2; //创建了两个对象做对比
// self监听p1的age属性//
NSKeyValueObservingOptions options = NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld;//
[p1 addObserver:self forKeyPath:@"age" options:options context:@"123"];
[self printMethods:object_getClass(p2)];
[self printMethods:object_getClass(p1)];
//该方法是mj老师写的打印一个类对象里面的方法信息
- (void)printMethods:(Class)cls{
unsigned int count;
Method *methods = class_copyMethodList(cls, &count);
NSMutableString *methodNames = [NSMutableString string];
[methodNames appendFormat:@"%@ - ", cls];
for (int i = 0; i < count; i++) {
Method method = methods[i];
NSString *methodName = NSStringFromSelector(method_getName(method)); [methodNames appendString:methodName];
[methodNames appendString:@" "]; }
NSLog(@"%@", methodNames);
free(methods);//C语言的对象需要释放
}
打印的结果如下：
Person - setAge: age
NSKVONotifying_Person - setAge: class dealloc _isKVOA
由此可见这是两个类对象的信息，所以被添加监听的person对象调用set方法时候是调用的NSKVONotifying_Person里面的方法的，还有个验证如图：
由图看见新建的p1和p2对象，p1被添加了KVO监听前后所使用的set方法地址发生了改变，而p2没被添加监听所以没有发生改变，由此说明p1被添加前后的set调用确实发了改变。然后我们程序上打上断点通过LLDB指令看一下到底发生了什么改变，如图：
注意：Interview05-KVO是建立的项目名字，是当前项目的可执行文件，图是借用的mj老师的
我们可以看出，p1没被添加监听之前的set是执行的目前建立的项目的可执行文件，而被添加之后是执行的Foundation的这个可执行文件，而且执行的是：_NSSetIntValueAndNotify这个函数，所以证明了之前的结论，另外还可以通过反编译oc的Foundation库查看一下，找下这个函数不再演示。
最后还有个小说明：为什么person对象被添加监听之后虽然类型改变了但是通过
[person class]；
这个方法获取的类还是Person呢，这个其实apple做了个掩护，不想让开发者知道内部做了些什么。剩下的咱们可以猜一下，其实在NSKOVNotifying_Person这个类中的class的get方法中做了如下操作：
- (Class)class{
return class_getSuperclass(object_getClass(self));
}
所以person对象在我们添加了监听之后返回的class还是Person这个类，一切都是假象啦！哈哈
还有在文章中涉及到OC对象本质的东西，可以看我的另外一篇文章：OC的对象本质
ps：这个文章其实是我的学习笔记了，在小码哥学习李明杰老师的iOS底层网络班授课做得笔记，所以用了好多mj老师的东西包括老师的思路和证明方法，感谢mj老师在it界的耕耘！
