KVO进阶（二）

转载自：

前言

这篇文章主要写KVO的内部通知

正文

先上代码

0-0

0-1

经测试，person.name = @"Jack"和[person setValue:@"Jack" forKey:@"name"]均可触发KVO，而[person changeName:@"Jack"]不能。前两种方式会访问setter，第三种直接访问成员变量，可以猜测KVO内部是在setter中触发的。
在Foundation/NSKeyValueObserving.h可以找到以下方法

- (void)willChangeValueForKey:(NSString *)key;
- (void)didChangeValueForKey:(NSString *)key;
+ (BOOL)automaticallyNotifiesObserversForKey:(NSString *)key;

+(BOOL)automaticallyNotifiesObserversForKey:(NSString *)key控制是否自动发送通知，如果返回NO，KVO无法自动运作，需手动触发。因为前两个方法默认是在setter中实现的（用KVO做键值观察后，系统会在运行时重写被观察对象属性的setter），即：

- (void)setName:(NSString *)name {
    [self willChangeValueForKey:@"name"];
    _name = name;
    [self didChangeValueForKey:@"name"];
}

那么如果把这两个方法移植到- (void)changeName:(NSString *)name中会怎样？

- (void)changeName:(NSString *)name {
    [self willChangeValueForKey:@"name"];
    _name = name;
    [self didChangeValueForKey:@"name"];
}

运行结果

 

看吧，KVO又跑起来了。

再来看一下他们的调用顺序

1-0

显然和我们猜测的顺序没有出入，完全正确

这里重写
+ (BOOL)automaticallyNotifiesObserversForKey:(NSString *)key
没有什么卵用，只是方便查看调用顺序。因为auto这个方法只和setter相关，而现在是调用自定义方法并且内部直接访问成员变量。
至于内部设置的那个name拦截，纯属为了娱乐?

自己出发KVO通知会生成中间类吗？（关于中间类，且听下回分解。。）当然会！

关于手动触发的例子很多，比如主流三方框架SDWebImage中的SDWebImageDownloaderOperation.h和MJRefesh中的UIScrollView+MJRefresh.h，有兴趣可以看下源码，这里不做解析。

如果两次设置的值相同会怎样？

2-0

WTF！相同的值干嘛还要监听？把代码改进一下

+ (BOOL)automaticallyNotifiesObserversForKey:(NSString *)key {
    if ([key isEqualToString:@"name"]) {
        return NO;
    }
    return [super automaticallyNotifiesObserversForKey:key];
}

- (void)setName:(NSString *)name {
    if ([_name isEqualToString:name]) {
        return;
    }
    [self willChangeValueForKey:@"name"];
    _name = name;
    [self didChangeValueForKey:@"name"];
}

再来看一下结果

3-0

多几次尝试，总会有意外的收获。成文匆忙，有错误的地方还请指正、包涵。