KVO的内部实现原理
关于KVO,首先我们来看两道面试题
KVO的本质是什么?
如何手动去触发KVO?
直接修改成员变量会触发KVO么?
怎么样? 如果你你能够很好的回答这两道面试题我相信你对KVO的使用以及内部原理已经非常熟悉了,也就不用再继续往下看了,如果对KVO的内部实现原理还是一知半解那么请跟我来,我将为你一一剖析
KVO的简单使用
首先我们来看一下KVO的简单使用步骤:
- (void)viewDidLoad {
[super viewDidLoad];
Person *p1 = [[Person alloc] init];
p1.age = 18;
self.p1 = p1;
Person *p2 = [[Person alloc] init];
p2.age = 18;
/**
1. p1：要监听的对象
2. 参数说明：
* @param addObserver 观察者，负责处理监听事件的对象
* @param forKeyPath 要监听的属性
* @param options 观察的选项
* @param context 上下文，用于传递数据
*/
[self.p1 addObserver:self forKeyPath:@"age" options:NSKeyValueObservingOptionOld|NSKeyValueObservingOptionNew context:nil];
p1.age = 20; // [p1 setAge:20];
p2.age = 30; // [p2 setAge:30];
}
//2.0 当属性值发生改变的时候会自动触发该方法
-(void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary<NSKeyValueChangeKey,id> *)change context:(void *)context{
NSLog(@"监听到%@对象的%@属性改变---%@",object,keyPath,change);
}
//3.0 当该控件被销毁的时候要移除该监听
-(void)dealloc{
[self.p1 removeObserver:self forKeyPath:@"age"];
}
@end
上述代码运行起来之后,执行结果:
监听到<Person: 0x60000000e9f0>对象的age属性改变---{
kind = 1;
new = 20;
old = 18;
}
不知道大家注意到没有,在上面的代码中我们同时改变了p1和p2的age的值,
p1.age = 20; // [p1 setAge:20];
p2.age = 30; // [p2 setAge:30];
但是却只监听到了p1的改变?你可能会说那不是废话么.....因为你只给p1 添加了 'addObserver'啊,是啊,对于编译器来说,p1和p2对象是一样的,唯一的区别就是我们为p1对象添加了一个监听,既然这样那为什么我们添加了监听之后 苹果就自动帮助我们去监听了p1的age属性值的改变的呢?至少在编译阶段这两个对象都是一样的,那肯定是在程序运行阶段苹果利用运行时RunTime动了手脚.....
KVO的内部实现
首先我们将程序跑起来,当程序运行到42行的时候,也就是没有添加任何监听之前,我们在打印一下p1对象和p2对象的isa指针,可以发现他们都是指向了同一个类对象也就是Person对象,如下图所示:
image
此时,让程序继续往下走,跳过42行我们再次打印 可以发现此时p1对象的isa指针已经悄悄的指向了另外一个对象 NSKVONotifying_Person,而p2对象的isa指针依然指向Person对象,如下图所示:
image
也就是说正式因为p1对象的isa指针指向了另外一个对象,这才导致了p1对象和p2对象在调用setAge方法时候的差异.
除了上述打断点的方法查看,我们还可以通过Runtime中的object_getClass来分析下在添加KVO前后的变化,如下图所示:
image
我们可以看到在添加了KVO监听之后,p1对象的isa指针依然是指向了
NSKVONotifying_Person对象,也验证了我们上面的推断:
接下来我们来仔细分析一下这个过程:
首先我们来分析一下没有添加KVO监听的p2对象: 正如上面我们断点所看到的,因为p2对象没有添加KVO监听,所以p2对象内部的isa指针依然是指向Person对象的,所以当我们调用p2.age = 30; // [p2 setAge:30];的时候它内部其实是先根据实例对象(instance对象)的isa指针找到它对应的类对象(Class对象)Person,然后调用它里面的setAge方法,并无异常,如下图所示:
image
接下来我们再来分析一下添加了KVO监听的p1对象,从上文我们可以得知,添加了KVO之后p1对象的isa指针已经指向了NSKVONotifying_Person对象,其实该对象是iOS在运行时通过Runtime自动创建的Person对象的子类,并且在该类中重写了setAge方法,大概执行流程如下:
image
NSKVONotifying_Person类中的setAge方法大概执行情况如下代码:
@implementation NSKVONotifying_MJPerson1
- (void)setAge:(int)age
{
__NSSet*ValueAndNotify();
}
void __NSSet*ValueAndNotify()
{
[self willChangeValueForKey:@"age"];
[super setAge:age];
[self didChangeValueForKey:@"age"];
}
- (void)didChangeValueForKey:(NSString *)key
{
[observer observeValueForKeyPath:@"age" ofObject:self change:@{} context:nil];
}
@end
所以通过以上分析我们可以看出在程序编译阶段p1对象和p2对象的表面都是调用setAge方法,但是在程序运行阶段他们内部的执行却是不一样的
看到这里我相信你已经可以很好地回答上面的两道面试题目了:
KVO的本质是什么?
当一个对象使用了KVO监听之后,iOS系统会在运行时阶段通过Runtime动态创建该类的子类对象,并且会修改这个对象的isa指针指向该子类对象,在该子类对象内部拥有自己的set方法实现,内部会调用willChangeValueForKey、 父类对象的setter方法 、didChangeValueForKey方法,同时在didChangeValueForKey方法中又调用了observeValueForKeyPath方法
如何手动去触发KVO?
因为p1对象添加了KVO监听之后,它的内部大概就是执行了下面的三个方法,所以我们可以大胆的猜测一下肯定是willChangeValueForKey和didChangeValueForKey这两个方法来触发了KVO操作,
[self willChangeValueForKey:@"age"];
[super setAge:age];
[self didChangeValueForKey:@"age"];
为了验证我们的判断,我们还是通过代码来说明问题:
image
通过调用上面我们说的那两个方法,手动的触发了observeValueForKeyPath方法,这也验证了我们的判断,那么你可能会问只调用其中的一个方法可不可以手动触发KVO? 答案是否,必须是这两个方法一起调用才会触发KVO操作,不信你可以试一试哦~
直接修改成员变量会触发KVO么?
通过以上分析我相信你肯定知道答案了,直接修改成员变量不会触发Set方法,自然也就不会触发KVO了,当然你手动调用的除外了~~
完结.....
