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<NSKeyValueChangeKey,id> *)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<count; i++) {
        
        Method method = methods[i];
        SEL sel = method_getName(method);
        [methodlist appendFormat:@"%@",NSStringFromSelector(sel)];
        [methodlist appendString:@"\n"];
 
    }
    
     [methodlist appendFormat:@"]"];
     free(methods);
    return methodlist;
}

在此调用相关的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 去告诉监听器属性值发生了改变 .

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 194,242评论 5赞 459
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 81,769评论 2赞 371
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 141,484评论 0赞 319
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 52,133评论 1赞 263
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 61,007评论 4赞 355
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 46,080评论 1赞 272
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 36,496评论 3赞 381
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 35,190评论 0赞 253
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 39,464评论 1赞 290
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,549评论 2赞 309
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,330评论 1赞 326
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 32,205评论 3赞 312
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 37,567评论 3赞 298
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,889评论 0赞 17
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,160评论 1赞 250
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 41,475评论 2赞 341
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 40,650评论 2赞 335