iOS大解密：玄之又玄的KVO (下)
首先我们看下 NSSetIntValueAndNotify_block_invoke 的汇编实现：
Foundation`___NSSetIntValueAndNotify_block_invoke:
-> 0x10bf27fe1 <+0>: pushq %rbp
0x10bf27fe2 <+1>: movq %rsp, %rbp
0x10bf27fe5 <+4>: pushq %rbx
0x10bf27fe6 <+5>: pushq %rax
0x10bf27fe7 <+6>: movq %rdi, %rbx
0x10bf27fea <+9>: movq 0x28(%rbx), %rax
0x10bf27fee <+13>: movq 0x30(%rbx), %rsi
0x10bf27ff2 <+17>: movq (%rax), %rdi
0x10bf27ff5 <+20>: callq 0x10c1422b2 ; symbol stub for: class_getMethodImplementation
0x10bf27ffa <+25>: movq 0x20(%rbx), %rdi
0x10bf27ffe <+29>: movq 0x30(%rbx), %rsi
0x10bf28002 <+33>: movl 0x38(%rbx), %edx
0x10bf28005 <+36>: addq $0x8, %rsp
0x10bf28009 <+40>: popq %rbx
0x10bf2800a <+41>: popq %rbp
0x10bf2800b <+42>: jmpq *%rax
___NSSetIntValueAndNotify_block_invoke 翻译成伪代码如下：
void ___NSSetIntValueAndNotify_block_invoke(SDTestStackBlock *block) {
SDTestKVOClassIndexedIvars *indexedIvars = block->captureVar2;
SEL methodSel = block->captureVar3;
IMP imp = class_getMethodImplementation(indexedIvars->originalClass);
id obj = block->captureVar1;
SEL sel = block->captureVar3;
int num = block->captureVar4;
imp(obj, sel, num);
}
这个 block 的内部实现其实就是从 KVO 类的 indexedIvars 里取到原始类，然后根据 sel 从原始类中取出原始的方法实现来执行并最终完成了一次 KVO 调用。我们发现整个 KVO 运作过程中 KVO 类的 indexedIvars 是一个贯穿 KVO 流程始末的关键数据，那么这个 indexedIvars 是何时生成的呢？indexedIvars 里又包含哪些数据呢？想要弄清楚这个问题，我们就必须从 KVO 的源头看起，我们知道既然 KVO 要用到 isa 交换那么最终肯定要调用到 object_setClass 方法，这里我们不妨以 object_setClass 函数为线索，通过设置条件符号断点来追踪 object_setClass 的调用，lldb 调试截图如下：
断点到 object_setClass 之后，我们再验证看下寄存器 rdi、rsi 里面的参数打印出来分别是<Test: 0x600003df01b0>、NSKVONotifying_Test
不错，我们现在已经成功定位到 KVO 的 isa 交换现场了，然而为了找到 KVO 类的生成的地方我们还需要沿着调用栈向前回溯，最终我们定位到 KVO 类的生成函数_NSKVONotifyingCreateInfoWithOriginalClass，其汇编代码如下：
Foundation`_NSKVONotifyingCreateInfoWithOriginalClass:
-> 0x10c557d79 <+0>: pushq %rbp
0x10c557d7a <+1>: movq %rsp, %rbp
0x10c557d7d <+4>: pushq %r15
0x10c557d7f <+6>: pushq %r14
0x10c557d81 <+8>: pushq %r12
0x10c557d83 <+10>: pushq %rbx
0x10c557d84 <+11>: subq $0x20, %rsp
0x10c557d88 <+15>: movq %rdi, %r14
0x10c557d8b <+18>: movq 0x2b463e(%rip), %rax ; (void *)0x000000011012d070: __stack_chk_guard
//篇幅限制删除一部分 .完整版在评论
翻译成伪代码如下：
typedef struct {
Class originalClass; // offset 0x0
Class KVOClass; // offset 0x8
CFMutableSetRef mset; // offset 0x10
CFMutableDictionaryRef mdict; // offset 0x18
pthread_mutex_t *lock; // offset 0x20
void *sth1; // offset 0x28
void *sth2; // offset 0x30
void *sth3; // offset 0x38
void *sth4; // offset 0x40
void *sth5; // offset 0x48
void *sth6; // offset 0x50
void *sth7; // offset 0x58
bool flag; // offset 0x60
} SDTestKVOClassIndexedIvars;
Class _NSKVONotifyingCreateInfoWithOriginalClass(Class originalClass) {
const char *clsName = class_getName(originalClass);
size_t len = strlen(clsName);
len += 0x10;
char *newClsName = malloc(len);
const char *prefix = "NSKVONotifying_";
__strlcpy_chk(newClsName, prefix, len);
__strlcat_chk(newClsName, clsName, len, -1);
Class newCls = objc_allocateClassPair(originalClass, newClsName, 0x68);
if (newCls) {
objc_registerClassPair(newCls);
SDTestKVOClassIndexedIvars *indexedIvars = object_getIndexedIvars(newCls);
indexedIvars->originalClass = originalClass;
indexedIvars->KVOClass = newCls;
CFMutableSetRef mset = CFSetCreateMutable(nil, 0, kCFCopyStringSetCallBacks);
indexedIvars->mset = mset;
CFMutableDictionaryRef mdict = CFDictionaryCreateMutable(nil, 0, nil, kCFTypeDictionaryValueCallBacks);
indexedIvars->mdict = mdict;
pthread_mutex_init(indexedIvars->lock);
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
bool flag = true;
IMP willChangeValueForKeyImp = class_getMethodImplementation(indexedIvars->originalClass, @selector(willChangeValueForKey:));
IMP didChangeValueForKeyImp = class_getMethodImplementation(indexedIvars->originalClass, @selector(didChangeValueForKey:));
if (willChangeValueForKeyImp == _NSKVONotifyingCreateInfoWithOriginalClass.NSObjectWillChange && didChangeValueForKeyImp == _NSKVONotifyingCreateInfoWithOriginalClass.NSObjectDidChange) {
flag = false;
}
indexedIvars->flag = flag;
NSKVONotifyingSetMethodImplementation(indexedIvars, @selector(_isKVOA), NSKVOIsAutonotifying, nil)
NSKVONotifyingSetMethodImplementation(indexedIvars, @selector(dealloc), NSKVODeallocate, nil)
NSKVONotifyingSetMethodImplementation(indexedIvars, @selector(class), NSKVOClass, nil)
});
} else {
// 错误处理过程省略......
return nil
}
return newCls;
}
通过_NSKVONotifyingCreateInfoWithOriginalClass 的这段伪代码你会发现我们之前频繁提到 indexedIvars 原来就是在这里初始化生成的。objc_allocateClassPair 在 runtime.h 中的声明为 Class _Nullable objc_allocateClassPair(Class _Nullable superclass, const char * _Nonnull name, size_t extraBytes) ，苹果对 extraBytes 参数的解释为“The number of bytes to allocate for indexed ivars at the end of the class and metaclass objects.”，这就是说当我们在通过 objc_allocateClassPair 来生成一个新的类时可以通过指定 extraBytes 来为此类开辟额外的空间用于存储一些数据。系统在生成 KVO 类时会额外分配 0x68 字节的空间，其具体内存布局和用途我用一个结构体描述如下：
typedef struct {
Class originalClass; // offset 0x0
Class KVOClass; // offset 0x8
CFMutableSetRef mset; // offset 0x10
CFMutableDictionaryRef mdict; // offset 0x18
pthread_mutex_t *lock; // offset 0x20
void *sth1; // offset 0x28
void *sth2; // offset 0x30
void *sth3; // offset 0x38
void *sth4; // offset 0x40
void *sth5; // offset 0x48
void *sth6; // offset 0x50
void *sth7; // offset 0x58
bool flag; // offset 0x60
} SDTestKVOClassIndexedIvars;
3. 如何解决 custom-KVO 导致的 native-KVO Crash
读到这里相信你对 KVO 实现细节有了大致的了解，然后我们再回到最初的问题，为什么“先调用 native-KVO 再调用 custom-KVO，custom-KVO 运行正常，native-KVO 会 crash”呢？我们还以上面提到过的 Test 类为例说明一下：
首先用 Test 类实例化了一个实例 test，然后对 test 的 num 属性进行 native-KVO 操作，这时 test 的 isa 指向了 NSKVONotifying_Test 类。然后我们再对 test 进行 custom-KVO 操作，这时我们的 custom-KVO 会基于 NSKVONotifying_Test 类再生成一个新的子类 SD_NSKVONotifying_Test_abcd，此时问题就来了，如果我们没有仿照 native-KVO 的做法额外分配 0x68 字节的空间用于存储 KVO 关键信息，那么当我们向 test 发送 setNum:消息然后 setNum:方法调用 super 实现走到了 KVO 的_NSSetIntValueAndNotify 方法时还按照 SDTestKVOClassIndexedIvars *indexedIvars = object_getIndexedIvars(cls)方式来获取 KVO 信息并尝试获取从中获取数据时发生异常导致 crash。
找到问题的根源之后我们就可以见招拆招，我们可以仿照 native-KVO 的做法在生成 SD_NSKVONotifying_Test_abcd 也额外分配 0x68 自己的空间，然后当要进行 custom-KVO 操作时将 NSKVONotifying_Test 的 indexedIvars 拷贝一份到 SD_NSKVONotifying_Test_abcd 即可，代码实现如下：
一般情况下在 native-KVO 的基础上再做 custom-KVO 的话拷贝完 native-KVO 类的 indexedIvars 到 custom-KVO 类上就可以了，而我们的 SDMagicHook 只做到这些还不够，因为 SDMagicHook 在生成的新类上以消息转发的形式来调度方法，这样一来问题瞬间就变得更为复杂。举例说明如下：
由于用到消息转发，我们会将 SD_NSKVONotifying_Test_abcd 的setNum:对应的实现指向_objc_msgForward，然后生成一个新的 SEL__sd_B_abcd_setNum:来指向其子类的原生实现，在我们这个例子中就是 NSKVONotifying_TestsetNum:实现的即void _NSSetIntValueAndNotify(id obj, SEL sel, int number)函数。当 test 实例收到setNum:消息时会先触发消息转发机制，然后 SDMagicHook 的消息调度系统会最终通过向 test 实例发送一个__sd_B_abcd_setNum:消息来实现对被 Hook 的原生方法的回调，而现在__sd_B_abcd_setNum:对应的实现函数正是void _NSSetIntValueAndNotify(id obj, SEL sel, int number)，所以__sd_B_abcd_setNum:就会被作为 sel 参数传递到_NSSetIntValueAndNotify函数。然后当_NSSetIntValueAndNotify函数内部尝试从 indexedIvars 拿到原始类 Test 然后从 Test 上查找__sd_B_abcd_setNum:对应的方法并调用时由于找不到对应函数实现而发生 crash。为解决这个问题，我们还需要为 Test 类新增一个__sd_B_abcd_setNum:方法并将其实现指向setNum:的实现，代码如下：
至此，“先调用 native-KVO 再调用 custom-KVO，custom-KVO 运行正常，native-KVO 会 crash”这个问题就可以顺利解决了。
4. 如何解决 native-KVO 导致 custom-KVO 失效的问题
目前还剩下一个问题“先调用 native-KVO 再调用 custom-KVO 再调用 native-KVO，native-KVO 运行正常，custom-KVO 失效，无 crash”。为什么会出现这个问题呢？这次我们依然以 Test 类为例，首先用 Test 类实例化了一个实例 test，然后对 test 的 num 属性进行 native-KVO 操作，这时 test 的 isa 指向了 NSKVONotifying_Test 类。然后我们再对 test 进行 custom-KVO 操作，这时我们的 custom-KVO 会基于 NSKVONotifying_Test 类再生成一个新的子类 SD_NSKVONotifying_Test_abcd，这时如果再对 test 的 num 属性进行 native-KVO 操作就会惊奇地发现 test 的 isa 又重新指向了 NSKVONotifying_Test 类然后 custom-KVO 就全部失效了。
WHY?!!原来 native-KVO 会持有一个全局的字典：_NSKeyValueContainerClassForIsa.NSKeyValueContainerClassPerOriginalClass 以 KVO 操作的原类为 key 和 NSKeyValueContainerClass 实例为 value 存储 KVO 类信息。
这样一来，当我们再次对 test 实例进行 KVO 操作时，native-KVO 就会以 Test 类为 key 从 NSKeyValueContainerClassPerOriginalClass 中查找到之前存储的 NSKeyValueContainerClass 并从中直接获取 KVO 类 NSKVONotifying_Test 然后调用 object_setclass 方法设置到 test 实例上然后 custom-KVO 就直接失效了。
想要解决这个问题，我想到了两种思路：1.修改 NSKVONotifying_Test 相关 KVO 数据 2.hook 拦截系统的 setclass 操作。然后仔细一想方案 1 是不可取的，因为 NSKVONotifying_Test 的相关数据是被所有 Test 类的实例在进行 KVO 操作时共享的，任何改动都有可能对 Test 类实例的 KVO 产生全局影响。所以，我们就需要借助 FishHook 来 hook 系统的 object_setclass 函数，当系统以 NSKVONotifying_Test 为参数对一个实例进行 setclass 操作时，我们检查如果当前的 isa 指针是 SD_NSKVONotifying_Test_abcd 且 SD_NSKVONotifying_Test_abcd 继承自系统的 NSKVONotifying_Test 时就跳过此次 setclass 操作。
但是这样做还不够，因为 custom-KVO 采用了特殊的消息转发机制来调度被 hook 的方法，如果先进行 custom-KVO 然后在进行 native-KVO 就会导致被观察属性被重复调用。所以，我们在对一个实例进行首次 custom-KVO 操作之前先进行 native-KVO，这样一来就可以保证我们的 custom-KVO 的方法调度正常工作了。代码如下：
总结
KVO 的本质其实就是基于被观察的实例的 isa 生成一个新的类并在这个类的 extra 空间中存放各种和 KVO 操作相关的关键数据，然后这个新的类以一个中间人的角色借助 extra 空间中存放各种数据完成复杂的方法调度。
系统的 KVO 实现比较复杂，很多函数的调用层次也比较深，我们一开始不妨从整个函数调用栈的末端层层向前梳理出主要的操作路径，在对 KVO 操作有个大致的了解之后再从全局的角度正向全面分析各个流程和细节。我们正是借助这种方式实现了对 KVO 的快速了解和认识。
至此，一个良好兼容 native-KVO 的 custom-KVO 就全部完成了。回头来看，这个解决方案其实还是过于 tricky 了，不过这也只能是在 iOS 系统的各种限制下的无奈的选择了。我们不提倡随意使用类似的 tricky 操作，更多是想要通过这个例子向大家介绍一下 KVO 的本质以及我们分析和解决问题的思路。如果各位读者可以从中汲取一些灵感，那么这篇文章“倒也算是不负恩泽”，倘若大家可以将这篇文章介绍到的思路和方法用于处理自己开发中的遇到的各种疑难杂症“那便真真是极好的了”！
