探索KVO触发通知的过程

2017-03-17 本文已影响481人 Haven_ZN

这两天在研究KVO，首先要吐槽的当然是官方提供的api，用起来实在是麻烦，所以想着封装一下，增加一个block回调什么的。这是成果：ZNKVOManager

写完之后发现FB在几年前就已经写好了。。。

关于KVO的基本知识，这里就不介绍了，对KVO一窍不通的可以先看看苹果的官方文档。这几天研究的主要内容是：凭什么只要调用一下属性的set方法，观察者就能收到通知呢？

参考一下notification，起码还有一个NSNotificationCenter负责转发，KVO可什么都没有提供，这么想来，一定是：

- (void)addObserver:(NSObject *)observer forKeyPath:(NSString *)keyPath options:(NSKeyValueObservingOptions)options context:(nullable void *)context;

这个方法里面做了一些手脚，下面就是记录一下研究的过程。内容不多。

在看苹果的官方文档时，有这么一段话：

Automatic key-value observing is implemented using a technique called isa-swizzling.
...
When an observer is registered for an attribute of an object the isa pointer of the observed object is modified, pointing to an intermediate class rather than at the true class. As a result the value of the isa pointer does not necessarily reflect the actual class of the instance.

翻译：在addObserver的时候，会生成一个中间类，被观察对象的isa指针实际指向这个中间类。

中间类究竟是什么样？在KVO中起到什么作用？通过代码看一看。首先是被观察的对象，很简单，就一个属性：

// ZNObject.h
@interface ZNObject : NSObject
@property (nonatomic, copy) NSString *name;
@end

//ZNObject.m
@implementation ZNObject
@end

再看看具体测试的代码：

- (void)viewDidLoad {
    [super viewDidLoad];
    
    self.obj = [ZNObject new];
    NSLog(@"%p", self.obj);
    NSLog(@"%p", [ZNObject class]);

    self.kvoManager = [[ZNKVOManager alloc] initWithObserver:self];
    [self.kvoManager observe:self.obj
                  forKeyPath:@"name"
                    callBack:^(id observer, id object, NSString *keyPath, NSDictionary<NSKeyValueChangeKey,id> *change) {
                           NSLog(@"new value is: %@", change[NSKeyValueChangeNewKey]);
                           NSLog(@"old value is: %@", change[NSKeyValueChangeOldKey]);
                       }];

    NSLog(@"%@", [self.obj class]);
    NSLog(@"%@", object_getClass(self.obj));
    
    self.obj.name = @"haha";
}

这里使用了ZNKVOManager，实现代码可以参考文章开始给出的链接。

其中这个方法:

- (void)observe:(id)object
     forKeyPath:(NSString *)keyPath
       callBack:(ZNKVOCallBack)callBack;

内部调用了addObserver方法，所以在调用完之后，获取了一下className，看看中间类是什么。最后一行设置了name的值，会进入block中，打印出新值和旧值。

这里需要关注的是类名打印的结果：

...
2017-03-17 10:59:12.655055 TestOSX[88627:4489127] ZNObject
2017-03-17 10:59:12.655117 TestOSX[88627:4489127] NSKVONotifying_ZNObject
...

通过class方法获取到的类依然是ZNObject，但是通过runtime提供的object_getClass(id obj)方法获取到的却是一个叫做NSKVONotifying_ZNObject的类。看起来这就是所谓的中间类。

看看class方法的源码：

// class方法
- (Class)class {
    return object_getClass(self);
}

class方法内部就是调用的object_getClass(id obj)。这就引出了一个疑问：为什么通过class方法和object_getClass(id obj)方法获取到的类不同呢？

在这之前，先看看这个中间类的信息，根据上面的官方信息，对象的isa指针指向的就是这个中间类，把代码稍微修改一下，获取中间类的地址：

NSLog(@"%p", object_getClass(self.obj));

2017-03-17 11:23:54.737805 TestOSX[89053:4504224] 0x6000001033c0

先看看这个类有哪些方法：

如果这一段看不懂，请先看一看Runtime源码 —— 对象、类和isa以及Runtime源码 —— 方法加载的过程

(lldb) p (objc_object *)0x6000001033c0
(objc_object *) $0 = 0x00006000001033c0
(lldb) p (class_data_bits_t *)0x00006000001033e0
(class_data_bits_t *) $1 = 0x00006000001033e0
(lldb) p $1->data()
(class_rw_t *) $2 = 0x000060000007c080
(lldb) p (*$2).methods
(method_array_t) $3 = {
  list_array_tt<method_t, method_list_t> = {
     = {
      list = 0x000060000004b1c1
      arrayAndFlag = 105553116574145
    }
  }
}
(lldb) p $3.beginCategoryMethodLists()
(method_list_t **) $4 = 0x000060000004b1c8
(lldb) p $4[0][0]
(method_list_t) $5 = {
  entsize_list_tt<method_t, method_list_t, 3> = {
    entsizeAndFlags = 26
    count = 1
    first = {
      name = "setName:"
      types = 0x00000001000029eb "v24@0:8@16"
      imp = 0x00007fff980d4496 (Foundation`_NSSetObjectValueAndNotify)
    }
  }
}
(lldb) p $4[1][0]
(method_list_t) $6 = {
  entsize_list_tt<method_t, method_list_t, 3> = {
    entsizeAndFlags = 26
    count = 1
    first = {
      name = "class"
      types = 0x0000000100104da8 "#16@0:8"
      imp = 0x00007fff980bfcea (Foundation`NSKVOClass)
    }
  }
}
(lldb) p $4[2][0]
(method_list_t) $7 = {
  entsize_list_tt<method_t, method_list_t, 3> = {
    entsizeAndFlags = 26
    count = 1
    first = {
      name = "dealloc"
      types = 0x0000000100104d52 "v16@0:8"
      imp = 0x00007fff980dc5bf (Foundation`NSKVODeallocate)
    }
  }
}
(lldb) p $4[3][0]
(method_list_t) $8 = {
  entsize_list_tt<method_t, method_list_t, 3> = {
    entsizeAndFlags = 26
    count = 1
    first = {
      name = "_isKVOA"
      types = 0x00007fff983e2b70 "c16@0:8"
      imp = 0x00007fff981e0c68 (Foundation`NSKVOIsAutonotifying)
    }
  }
}
(lldb) p $4[4][0]
error: Couldn't apply expression side effects : Couldn't dematerialize a result variable: couldn't read its memory

一共有4个方法，分别是setName，class，dealloc，_isKVOA.

到这里其实已经可以做出一些猜测了。

之前那个疑问应该就是中间类重写了class方法导致的，因为这个class方法的imp是：Foundation`NSKVOClass。在这个方法内部肯定做了一些事情。
中间类重写了setName方法，所以KVO应该在这个方法的imp：Foundation`_NSSetObjectValueAndNotify中做了一些事情来实现通知的功能。

那这个中间类和原有的类有什么关系呢？继续测试一下：

// 中间类的地址是0x6000001033c0，superclass的地址在此基础上偏移8
(lldb) p (objc_class *)0x00006000001033c8
(objc_class *) $10 = 0x00006000001033c8
(lldb) p *$10
(objc_class) $11 = {
  isa = ZNObject
}

中间类的superclass就是原类，这么一想还是很合理的。中间类重写了一些方法，对这些方法的调用会使用重写之后的版本。而调用其他的方法，在中间类中查找不到就会到父类中查找，所以原类中的方法依然可以正常调用。

关于方法调用的顺序，可以看这篇：Runtime源码 —— 方法调用的过程

现在对中间类已经有一些了解了，再来看看文章开始的那个问题：set方法究竟如何触发KVO的通知？

先回顾一下中间类的setName方法：

name = "setName:"
types = 0x00000001000029eb "v24@0:8@16"
imp = 0x00007fff980d4496 (Foundation`_NSSetObjectValueAndNotify)

实现是Foundation框架的_NSSetObjectValueAndNotify方法，没法看到源码，但是可以通过watchpoint看看调用栈：

添加watchpoint

继续运行到命中：

watchpoint命中

对name的设置最终还是通过原类(ZNObject)的set方法来进行的，在_NSSetObjectValueAndNotify方法之后，调用了NSObject一个分类中的方法：

-[NSObject(NSKeyValueObservingPrivate) _changeValueForKeys:count:maybeOldValuesDict:usingBlock:]

看这个方法的时候，我发现这么一个方法：

调用NSKeyValueDidChange

这个方法后面会调用NSKeyValueDidChange这个方法，这个方法名字看起来有点眼熟，有点像NSObject提供的这个方法：

// Informs the observed object that the value of a given property has changed.
- (void)didChangeValueForKey:(NSString *)key;

那么NSKeyValueDidChange是不是起这个作用呢？进入这个方法看一看：

NSKeyValueDidChange内部

在这个方法内部又有新发现，有这么一个方法名字引起了我的注意：
NSKeyValueNotifyObserver，看起来就是用来通知观察者的。

这个时候在这个方法中添加一个断点，这个方法就是观察者收到通知的地方，应该都很熟悉：

- (void)observeValueForKeyPath:(NSString *)keyPath
                      ofObject:(id)object
                        change:(NSDictionary<NSKeyValueChangeKey,id> *)change
                       context:(void *)context

结果如下图：

观察者收到通知

果然，上面那个方法在NSKeyValueNotifyObserver方法内部被调用了。这就完成了整个通知的过程。

总结

稍微总结一下KVO方法的调用顺序，就是这个样子的：

self.obj.name = @"haha";
_NSSetObjectValueAndNotify
-[NSObject(NSKeyValueObservingPrivate) _changeValueForKeys:count:maybeOldValuesDict:usingBlock:]
- [ZNObject setName]
NSKeyValueDidChange
NSKeyValueNotifyObserver
- observeValueForKeyPath:ofObject:change:context:

之前还有个疑问，调用class方法和object_getClass(id obj)方法为什么返回结果不同。可以仿照上面的流程，研究class方法的调用顺序，结果是这样的：

[self.obj class]
NSKVOClass
object_getClass(id obj)
_NSKVONotifyingOriginalClassForIsa
_isKVOA
NSKVOIsAutonotifying
[ZNObject class]
+ [NSObject class]

最后还是会调用ZNObject的class方法，所以返回的结果是ZNObject也就不奇怪了。

如果直接使用object_getClass(id obj)，并没有那么复杂的逻辑，就只调用了这个方法，也就是获取obj的isa，所以返回的是中间类。

最后再说一下这几个方法的用法吧：

- (void)willChangeValueForKey:(NSString *)key;
- (void)didChangeValueForKey:(NSString *)key;

正常情况下是不需要使用的，因为前面也看到了，中间类的set方法会帮我们调用NSKeyValueDidChange来触发通知。

如果不想自动触发，可以使用上面这两个方法来手动触发，但是需要注意的是，如果仅仅是把set方法修改为这个样子：

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

这样会触发两次通知，第一次是手动触发，第二次是中间类自动触发，这个时候需要关闭自动触发机制，很简单，只要配套使用这个方法就可以了：

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

将想要手动触发的key返回NO就可以了，这个方法默认返回YES。

探索KVO触发通知的过程

总结

猜你喜欢

热点阅读