iOSiOS干货iOS 技术

KVO进阶(二)

2015-10-17  本文已影响1188人  01_Jack

前言

这篇文章主要写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.hMJRefesh中的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

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

上一篇下一篇

猜你喜欢

热点阅读