关于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对象,如下图所示:
此时让程序继续往下走，跳过42行我们再次打印 可以发现此时p1对象的isa指针已经悄悄的指向了另外一个对象 NSKVONotifying_Person，而p2对象的isa指针依然指向Person对象，如下图所示:
也就是说正是因为p1对象的isa指针指向了另外一个对象，这才导致了p1对象和p2对象在调用setAge方法时候的差异.
除了上述打断点的方法查看，我们还可以通过Runtime中的object_getClass来分析下在添加KVO前后的变化，如下图所示:
我们可以看到在添加了KVO监听之后，p1对象的isa指针依然是指向了
NSKVONotifying_Person对象，也验证了我们上面的推断:
接下来我们来仔细分析一下这个过程:
首先我们来分析一下没有添加KVO监听的p2对象: 正如上面我们断点所看到的，因为p2对象没有添加KVO监听，所以p2对象内部的isa指针依然是指向Person对象。所以当我们调用p2.age = 30; // [p2 setAge:30];的时候它内部其实是先根据实例对象(instance对象)的isa指针找到它对应的类对象(Class对象)Person，然后调用它里面的setAge方法,并无异常,如下图所示:
接下来我们再来分析一下添加了KVO监听的p1对象。从上文我们可以得知，添加了KVO之后p1对象的isa指针已经指向了NSKVONotifying_Person对象。其实该对象是iOS在运行时通过Runtime自动创建的Person对象的子类，并且在该类中重写了setAge方法 大概执行流程如下:
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其实是OC利用观察者模式来实现的一个技术。当一个对象使用了KVO监听之后，iOS系统会在运行时阶段通过Runtime动态创建该类的子类对象，并且会修改这个对象的isa指针指向该子类对象(isa混写技术 isa-swizzling)。在该子类对象内部拥有自己的set方法实现，同时内部会调用willChangeValueForKey、 父类对象的setter方法 、didChangeValueForKey方法。在didChangeValueForKey方法中又调用了observeValueForKeyPath方法。
具体的逻辑图如下所示：
如何手动去触发KVO?
因为p1对象添加了KVO监听之后，它的内部大概就是执行了下面的三个方法，所以我们可以大胆的猜测一下。肯定是willChangeValueForKey和didChangeValueForKey这两个方法来触发了KVO操作
[self willChangeValueForKey:@"age"];
[super setAge:age];
[self didChangeValueForKey:@"age"];
为了验证我们的判断,我们还是通过代码来说明问题:
通过调用上面我们说的那两个方法，手动的触发了observeValueForKeyPath方法，这也验证了我们的判断，那么你可能会问只调用其中的一个方法可不可以手动触发KVO？ 答案是否，必须是这两个方法一起调用才会触发KVO操作，不信你可以试一试哦~
直接修改成员变量会触发KVO么?
通过以上分析我相信你肯定知道答案了，直接修改成员变量不会触发Set方法 自然也就不会触发KVO了。当然你手动调用的除外了~~
通过KVC修改属性会触发KVO么?
通过KVC修改成员变量的值，系统内部帮助我们调用了willChangeValueForKey和didChangeValueForKey这两个方法，从而触发了KVO，具体分析参考KVC内部执行过程分析
总结：
什么是KVO？
是观察者模式的一种实现，同时是利用isa混写技术来实现的。也就是在运行时阶段通过Runtime动态创建该类的子类对象，并且会修改这个对象的isa指针指向该子类对象， 在子类对象中重写setter方法。
- 使用setter方法改变值KVO才会生效
- 使用setValue:forKey:改变值KVO才会生效
- 直接修改成员变量不会触发KVO，需要手动调用才会触发。
完结.....
