面试中被问到KVO下常见的crash原因。转载了一下KVO使用陷阱
鉴于我自己对这块没有太多的认知。通过博主文章加深理解~。本文意在探究健壮的KVO实现方案。
在初始化方法中加入:
[_tableView addObserver:self forKeyPath:@"contentOffset" options:NSKeyValueObservingOptionNew context:nil];
执行默认回调
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary<NSKeyValueChangeKey,id> *)change context:(void *)context { }
在dealloc中移除
[_tableView removeObserver:self forKeyPath:@"contentOffset" context:nil];
我们普通写的代码可能就这样就完事了。甚至在dealloc中我们都不会进行removeObserve的操作。
事实上这样还远远不够。比如我的一个VC中有多个监听的话,这样肯定是不行的
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object
change:(NSDictionary *)change context:(void *)context
{
if (object == _tableView && [keyPath isEqualToString:@"contentOffset"]) {
[self doSomethingWhenContentOffsetChanges];
}
}
这样加入判断则 是哪个造成对象,然后触发响应。
但是这样还是不够的,因为可能当前类的父类也响应KVO。如果这么搞的话。KVO会在子类中断
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object
change:(NSDictionary *)change context:(void *)context
{
if (object == _tableView && [keyPath isEqualToString:@"contentOffset"]) {
[self doSomethingWhenContentOffsetChanges];
} else {
[super observeValueForKeyPath:keyPath ofObject:object change:change context:context];
}
}
在else的情况里面响应super的KVO.顺着响应链条去寻找。
这样仍然没有结束,潜在的问题是可能出现dealloc中KVO的注销。KVO的一种缺陷(其实不能称为缺陷,应该称为特性)是,当对同一个keypath进行两次removeObserver时会导致程序crash,这种情况常常出现在父类有一个kvo,父类在dealloc中remove了一次,子类又remove了一次的情况下。这种情况下context始终为空。 这个时候我们可以在父类在子类中的context 定义不同的名称。这样的话,可以进行区分防止removeObserve发生2次。