iOS KVO原理解析

一，KVO的概念

KVO 是(Key-valueObserve) Objective-C 对观察者模式（Observer Pattern）的实现。也是 Cocoa Binding 的基础。当被观察对象的某个属性发生更改时，观察者对象会获得通知。

有意思的是，你不需要给被观察的对象添加任何额外代码，就能使用 KVO 。这是怎么做到的？

二，KVO的底层实现原理

KVO 是基于Runtime机制实现的，KVO是运用了一个isa-swizzling 技术. isa-swizzling
就是类型混合指针机制, 将2个对象的isa指针互相调换, 就是俗称的黑魔法.

• 当某个类的属性对象第一次被观察时，系统就会在运行期动态地创建该类的一个派生类，在这个派生类中重写基类中任何被观察属性的setter 方法。派生类在被重写的setter方法内实现真正的通知机制
• 如果原类为Person，那么生成的派生类名为NSKVONotifying_Person
• 每个类对象中都有一个isa指针指向当前类，当一个类对象的第一次被观察，那么系统会偷偷将isa指针指向动态生成的派生类，从而在给被监控属性赋值时执行的是派生类的setter方法
• 键值观察通知依赖于NSObject 的两个方法: willChangeValueForKey: 和 didChangevlueForKey:；在一个被观察属性发生改变之前， willChangeValueForKey:一定会被调用，这就 会记录旧的值。而当改变发生后，didChangeValueForKey:会被调用，继而 observeValueForKey:ofObject:change:context: 也会被调用。

• 补充：KV0的这套实现机制中苹果还偷偷重写了class方法，让我们误认为还是使用的当前类，从而达到隐藏生成的派生类

  
  
  

  image

三，代码的实现过程

首先创建一个新的工程，然后新建一个类对象Person,其中包含一个属性name,然后利用Person创建两个对象p1和p2，对p1添加监听，代码如下

- (void)viewDidLoad {
    [super viewDidLoad];
    
    // Do any additional setup after loading the view.
    
    Person *p1 = [[Person alloc]init];
    Person *p2 = [[Person alloc]init];
    
    [p1 addObserver:self forKeyPath:@"name" options:NSKeyValueObservingOptionNew context:nil];
    
    p1.name = @"zhangsan";
    p2.name = @"lisi";
    
    
    
}

-(void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context
{
    NSLog(@"改变&&&&change   %@",change);
    
}

对p1和p2进行赋值操作后，相应的监听回调会显示以下内容

图片.png

通过对象的类别分析数据显示如下，我们分别在添加监听的前后打印相关的类信息

    Person *p1 = [[Person alloc]init];
    Person *p2 = [[Person alloc]init];
    
    
    NSLog(@"添加监听之前的类   %@  ， %@",[p1 class],[p2 class]);
    
    [p1 addObserver:self forKeyPath:@"name" options:NSKeyValueObservingOptionNew context:nil];
    
    NSLog(@"添加监听之后的类   %@  ， %@",[p1 class],[p2 class]);
    
    p1.name = @"zhangsan";
    p2.name = @"lisi"

打印的相关日志如下

图片.png

两个对象的类信息显示完全相同，这对我们分析这个原理好像没什么区别啊，那为什么p1能有监听p2却没有呢？，继续往下研究吧,只要功夫深不愁没收获,我们把获取对象类型实例的方法换成object_getClassName(id)看看效果，

    Person *p1 = [[Person alloc]init];
    Person *p2 = [[Person alloc]init];
    

   
    NSLog(@"添加监听之前的类   %s  ， %s",object_getClassName(p1),object_getClassName(p2));
    
    [p1 addObserver:self forKeyPath:@"name" options:NSKeyValueObservingOptionNew context:nil];

    NSLog(@"添加监听之后的类   %s  ， %s",object_getClassName(p1),object_getClassName(p2));
    
    p1.name = @"zhangsan";
    p2.name = @"lisi";

结果打印的日志是

图片.png

为了研究对象的内存地址发生什么变化，我们把两个监听之前和之后的内存地址分别打印出来，进行相关的研究

    Person *p1 = [[Person alloc]init];
    Person *p2 = [[Person alloc]init];
    
    SEL sel = @selector(setName:);
    
    IMP imp1 = [p1 methodForSelector:sel];
    IMP imp2 = [p2 methodForSelector:sel];


    NSLog(@"添加监听之前的地址是   %p  ， %p",imp1,imp2);
    
    [p1 addObserver:self forKeyPath:@"name" options:NSKeyValueObservingOptionNew context:nil];
    
    imp1 = [p1 methodForSelector:sel];
    imp2 = [p2 methodForSelector:sel];
    
    NSLog(@"添加监听之后的地址是   %p  ， %p",imp1,imp2);
    
    p1.name = @"zhangsan";
    p2.name = @"lisi";

显示的内存地址分配如下情况

图片.png

最后发现连 setName方法都不一样了 , 为了一探究竟 小编绝对对上边的 NSKVONotifying_Person 和 添加 KVO 之后的 imp 指针进行进一步研究.
在控制台打印相关的对象类型

图片.png

发现了 imp1 方法实现在 Foundation 框架里的 _NSSetObjectValueAndNotify 函数中 ,而 imp2 则调用了 Person setName 方法
也就是说添加了 KVO 之后 p1 修改 name 值之后 不再调用 Person 的 setName方法 ,而 p2没有添加 kvo 监听 依然正常调用 setName:方法 ,由此可以得出 p1 添加完 KVO 监听后 系统修改了默认方法实现,那么既然没有调用 setName: 方法 为什么 p1.name 的值也发生了改变?

接下来我们准备对刚才 NSKVONotifying_Person 类进行下一步研究, NSKVONotifying_Person 和 Person 有没有内在的联系呢?

    id cls1 = objc_getClass(object_getClassName(p1));
    id cls2 = objc_getClass(object_getClassName(p2));


    NSLog(@"添加监听之前的地址是   cls1 = %@  ， cls2 = %@",cls1,cls2);
    
    [p1 addObserver:self forKeyPath:@"name" options:NSKeyValueObservingOptionNew context:nil];
    
    cls1 = objc_getClass(object_getClassName(p1));
    cls2 = objc_getClass(object_getClassName(p2));

    NSLog(@"添加监听之后的地址是  cls1 =  %@  ，cls2 =  %@",cls1,cls2);
    
    id superClass1 = class_getSuperclass(cls1);
    id superClass2 = class_getSuperclass(cls2);
    
    
    NSLog(@"superclass 的对象是  superclass1 = %@    superclass2 = %@",superClass1,superClass2);

    
    p1.name = @"zhangsan";
    p2.name = @"lisi";
    

图片.png

通过打印 NSKVONotifying_Person 的 superclass 和 Person 的 superclass 可以得出, NSKVONotifying_Person是一个 Person 子类,那么为什么苹果会动态创建这么一个 子类呢? NSKVONotifying_Person 这个子类 跟 Person 内部有哪些不同呢 ?

这个时候 我们去输出下 Person 和 NSKVONotifying_Person 内部的方法列表 和 属性列表 ,看看NSKVONotifying_Person 子类都添加了那些方法和属性.

先定义一个打印内部方法的方法，

-(NSString *)printPersonMethords:(id)obj{
    
    unsigned int count = 0;
    Method *methods = class_copyMethodList([obj class], &count);
    NSMutableString *methodlist = [NSMutableString string];
    [methodlist appendString:@"[\n]"];
    for (int i = 0; i

在此调用相关的cls1 和cls2 的方法答应，出相关数据

   id cls1 = objc_getClass(object_getClassName(p1));
    id cls2 = objc_getClass(object_getClassName(p2));


    NSLog(@"添加监听之前的地址是   cls1 = %@  ， cls2 = %@",cls1,cls2);
    
    [p1 addObserver:self forKeyPath:@"name" options:NSKeyValueObservingOptionNew context:nil];
    
    cls1 = objc_getClass(object_getClassName(p1));
    cls2 = objc_getClass(object_getClassName(p2));

    NSLog(@"添加监听之后的地址是  cls1 =  %@  ，cls2 =  %@",cls1,cls2);
    
    
    NSString *methordList1 = [self printPersonMethords:cls1];
    NSString *methordList2 = [self printPersonMethords:cls2];
    
    NSLog(@"methordlist1 = %@",methordList1);
    NSLog(@"methordlist2 = %@",methordList2);

控制台显示的内容如下

图片.png

从输出结果可以看出来 NSKVONotifying_Person 内部也有一个 setName:方法 还重写了 class 和 dealloc 方法 , _isKVOA, 那么我们可以大致的得出, p1添加 kVO 后 runtime 动态的生成了一个 NSKVONotifying_Person子类 并重写了 setName 方法 ,那么 setName 内部一定是做了一些事情,才会触发 observeValueForKeyPath 监听方法.

继续探究 NSKVONotifying_Person 子类 重写 setName 都做了什么?
其实 setName 方法内部 是调用了 Foundation 的 _NSSetObjectValueAndNotify 函数 ,在 _NSSetObjectValueAndNotify 内部

1首先会调用 willChangeValueForKey
2然后给 name 属性赋值
3 最后调用 didChangeValueForKey
4最后调用 observer 的 observeValueForKeyPath 去告诉监听器属性值发生了改变 .