前言
KVO键值观察,我们再熟悉不过了。但是大部分人对它的关注点可能都在对观察某一个keyPath,会动态创建一个继承该类的带前缀NSKVONotifying_原类名的子类,并且在子类中重写该key的setter方法这一逻辑。今天我们来看一些可能平时不太注意的地方,并且讨论一下KVO键值观察为什么要创建子类来实现。
触发通知方式;
(1)自动通知,这种应该是比较常见的,原因在于NSObject类实现了NSKeyValueCoding协议,因此只要是继承了NSObject类的对象通过KVC进行操作就可以自动的通知到观察者。
(2)手动通知,这就需要让你的类重写+ (BOOL)automaticallyNotifiesObserversForKey:(NSString *)key或者是+ (BOOL)automaticallyNotifiesObserversOf<key>方法,对于想要手动触发通知的,可以根据keyPath返回NO,而其对于其他位置的keyPath,要返回父类的这个方法。例如属性observingStr;
+ (BOOL)automaticallyNotifiesObserversForKey:(NSString *)key
{
if ([key isEqualToString:@"observingStr"]) {
return NO;
}
return YES;
}
+ (BOOL)automaticallyNotifiesObserversOfObservingStr
{
return NO;
}
手动触发;
(1)要实现手动通知,你需要在值改变前调用 willChangeValueForKey: 方法,在值改变后调用 didChangeValueForKey: 方法。你可以在发送通知前检查值是否改变,如果没有改变就不发送通知。关键在于willChangeValueForKey:以及didChangeValueForKey:这两个方法,自动通知应该就是在子类重写的setter中封装好触发通知的逻辑。
(2)其实手动触发通知有一个细节的地方,不知道有没有人注意到,就是当你设置某个键值需要手动通知时,系统并没有去动态创建带前缀NSKVONotifying_原类名,你可以通过rumtime的object_getClass(self),去验证self的isa是否指向新类,答案是没有。
KVO键值观察为什么要创建子类来实现?
(1)上文也说了触发键值观察的关键方法willChangeValueForKey:和didChangeValueForKey:,我们做个假设,假设苹果KVO机制并没有通过创建子类实现,而是在当前类实现。那么会存在一个问题,就是开发者重写该属性的setter方法,并且并没有去执行willChangeValueForKey:和didChangeValueForKey:两个方法,就不会触发通知观察者。
(2)有可能跟类设计的单一责任原则有关,子类自负责封装触发通知逻辑,其他的一概不管(例如获取旧值以及赋值新值都会执行父类的方法)。例如;
- (void)setObservingStr:(NSString *)observingStr
{
[self willChangeValueForKey:@"observingStr"];
NSLog(@"%@", NSStringFromClass(object_getClass(self)));
//_observingStr = observingStr;
//[self didChangeValueForKey:@"observingStr"];
}
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary<NSKeyValueChangeKey,id> *)change context:(void *)context
{
if ([keyPath isEqualToString:@"observingStr"]) {
NSLog(@"newStr -- %@", change[NSKeyValueChangeNewKey]);
} else {
[super observeValueForKeyPath:keyPath ofObject:object change:change context:context];
}
}
由于重写的setter方法没有赋值新值,输出newStr -- <null>;这也说明子类重写的setter方法取值和赋值是通过父类的setter方法。
总结
本文所讲的内容只是KVO的一部分,用于记录平时研究一些技术的心得,了解更多的内容可以查看这篇文章或者是上网查询更多内容。