本文为大地瓜原创，欢迎知识共享，转载请注明出处。
虽然你不注明出处我也没什么精力和你计较。
作者微信号：christgreenlaw

---

本文的原文。本文只对其进行翻译。

---

What Is It? 这是个啥玩意？

很多读者早就知道这个东西了，但是我们还是要简单的回忆一下：KVO是Cocoa Bindings底层的技术，让某些对象能够在其他对象的属性被更改时获得通知。一个对象观察（observe)另一个对象的key。当被观察的对象更改了这个key 的值时，观察者就得到了通知。挺好理解的是吧？牛逼的地方在于：KVO一般不需要给被观察者写任何的代码。

OverView 概览

所以说到底这是怎么做到的？竟然不需要给被观察者写代码？其实秘密就在OC runtime里。当你第一次观察一个特定类的一个对象时，KVO就在运行时创建一个全新的类，这个类其实继承了你所观察的类。在这个新类中，它会将你所观察的属性（key）的setter重写。然后它修改你这个对象的isa指针（也就是告知OC runtime某一块内存到底是什么类型的对象的指针），这样你的对象就成了这个新类的实例。

被重写的方法执行了通知观察者的工作。所以这个逻辑就是：对一个key 的修改必须经过key 的set方法。对set方法的修改使得set方法可以截获修改，并在set方法被调用时向观察者发送通知。（当然，如果你直接修改实例变量的话，你也可能不经过set方法就进行修改。KVO要求进行KVO的类要么决不能这样做（也就是决不能直接修改实例变量），要么必须将对ivar的直接访问包装在手动的通知调用中。）

有点棘手的是：Apple实际上不希望别人知道这个技术原理。不仅仅是setter，动态继承（dynamic subclass）也重写了-class方法来欺骗你，返回原始的类！如果你不仔细观察的话，KVO观察的对象就和其他没有被观察的部分一模一样。

Digging Deeper 再挖掘一下

不多废话了，我们来看看到底是怎样工作的。我写了一个程序，它展示了KVO背后的原理。由于动态KVO继承（dynamic KVO subclass）希望隐藏自己的存在，我主要使用了OC runtime'方法来获得我们希望获得的信息。

以下是代码：

// gcc -o kvoexplorer -framework Foundation kvoexplorer.m
    
    #import <Foundation/Foundation.h>
    #import <objc/runtime.h>
    
    
    @interface TestClass : NSObject
    {
        int x;
        int y;
        int z;
    }
    @property int x;
    @property int y;
    @property int z;
    @end
    @implementation TestClass
    @synthesize x, y, z;
    @end
    
    static NSArray *ClassMethodNames(Class c)
    {
        NSMutableArray *array = [NSMutableArray array];
        
        unsigned int methodCount = 0;
        Method *methodList = class_copyMethodList(c, &methodCount);
        unsigned int i;
        for(i = 0; i < methodCount; i++)
            [array addObject: NSStringFromSelector(method_getName(methodList[i]))];
        free(methodList);
        
        return array;
    }
    
    static void PrintDescription(NSString *name, id obj)
    {
        NSString *str = [NSString stringWithFormat:
            @"%@: %@\n\tNSObject class %s\n\tlibobjc class %s\n\timplements methods <%@>",
            name,
            obj,
            class_getName([obj class]),
            class_getName(obj->isa),
            [ClassMethodNames(obj->isa) componentsJoinedByString:@", "]];
        printf("%s\n", [str UTF8String]);
    }
    
    int main(int argc, char **argv)
    {
        [NSAutoreleasePool new];
        
        TestClass *x = [[TestClass alloc] init];
        TestClass *y = [[TestClass alloc] init];
        TestClass *xy = [[TestClass alloc] init];
        TestClass *control = [[TestClass alloc] init];
        
        [x addObserver:x forKeyPath:@"x" options:0 context:NULL];
        [xy addObserver:xy forKeyPath:@"x" options:0 context:NULL];
        [y addObserver:y forKeyPath:@"y" options:0 context:NULL];
        [xy addObserver:xy forKeyPath:@"y" options:0 context:NULL];
        
        PrintDescription(@"control", control);
        PrintDescription(@"x", x);
        PrintDescription(@"y", y);
        PrintDescription(@"xy", xy);
        
        printf("Using NSObject methods, normal setX: is %p, overridden setX: is %p\n",
              [control methodForSelector:@selector(setX:)],
              [x methodForSelector:@selector(setX:)]);
        printf("Using libobjc functions, normal setX: is %p, overridden setX: is %p\n",
              method_getImplementation(class_getInstanceMethod(object_getClass(control),
                                       @selector(setX:))),
              method_getImplementation(class_getInstanceMethod(object_getClass(x),
                                       @selector(setX:))));
        
        return 0;
    }

大地瓜注：这段代码似乎在Xcode9下无法正确执行，会提示obj->isa这一行有问题。

我们来重头到尾分析一下。

首先我们定义了一个TestClass类，有三个属性。（KVO对非@property的key也有效，但是这样最容易定义setter和getter）。

接下来定义了一组功能函数。ClassMethodNames使用了OC运行时方法遍历一个类然后得到其实现的所有方法的列表。要注意：它只是获得了在class中直接实现的方法，并不获取超类的方法。PrintDescription把传入的对象的详细描述打印，展示了通过-class方法获得的对象的类，也展示了通过OCruntime函数获得的对象的类以及这个类上实现的方法。

接下来我们开始试验这些功能。我们创建了TestClass的四个实例，每一个都用不同的方法进行观察。x实例观察x的key，y也类似，xy将会同时观察x和y的key。z 的key不进行观察以进行对比。最后control实例作为一个实验中的控制变量，将不会进行观察。

接下来我们打印出四个对象的描述。

接下来我们更深入的挖掘一下重写的setter，将control对象的和被观察对象的-setX:方法的实现的地址打印出来，进行对比。我们做两次这个操作，因为使用-methodForSelector:不能展示出重写。KVO期望隐藏动态继承，甚至希望用这个技术隐藏重写的方法！但是使用OCruntime函数却可以输出合理的结果。

运行代码

所以说以上就是代码所做的事。我们来看一下运行的结果：

    control: <TestClass: 0x104b20>
        NSObject class TestClass
        libobjc class TestClass
        implements methods <setX:, x, setY:, y, setZ:, z>
    x: <TestClass: 0x103280>
        NSObject class TestClass
        libobjc class NSKVONotifying_TestClass
        implements methods <setY:, setX:, class, dealloc, _isKVOA>
    y: <TestClass: 0x104b00>
        NSObject class TestClass
        libobjc class NSKVONotifying_TestClass
        implements methods <setY:, setX:, class, dealloc, _isKVOA>
    xy: <TestClass: 0x104b10>
        NSObject class TestClass
        libobjc class NSKVONotifying_TestClass
        implements methods <setY:, setX:, class, dealloc, _isKVOA>
    Using NSObject methods, normal setX: is 0x195e, overridden setX: is 0x195e
    Using libobjc functions, normal setX: is 0x195e, overridden setX: is 0x96a1a550

首先打印出了control对象。与期望相符的是，它所属的类是TestClass，并且也实现了我们从类的属性所同步来的六个方法。

接下来打印了三个被观察的对象。注意到：尽管-class方法还是显示TestClass，使用object_getClass却展现这个对象的真实面貌：它是一个NSKVONotifying_TestClass对象。这就是动态继承的子类！

来看一下它是怎么实现两个被观察的setter的。你会注意到不重写-setZ:是很聪明的，因为即使它也是一个setter，但是并没有人观察它。我们可以推测，如果我们给z也添加一个观察者，那么NSKVONotifying_Class也会给-setZ:进行重写。同时也要注意三个实例同属一个类，也就是说它们都重写了两个setter，尽管他们两个都只被观察了一个属性。即使对于未观察的属性也调用被观察的setter，这样会有性能损耗，但是Apple显然觉得：如果每个对象都有一组不同的key被观察，不生成多个动态继承的子类是更合适的。我也觉得这样是对的。

你也会观察到三个其他的方法。这就是前面提到的被重写的-class方法，这个方法希望隐藏掉这个动态子类的存在。还有一个-dealloc方法来进行清理。另外还有一个神秘的-_isKVOA方法，这个方法看起来像是一个私有方法，Apple的代码可以使用这个方法来确定一个独享是不是服从动态继承。

接下来我们打印出了-setX:的实现。使用-methodForSelector:给两者返回了相同的值。既然在动态子类中不存在这个方法的重写，这肯定意味着-methodForSelector:使用了-class作为内部实现的一部分，也因此获得了错误的结果。

所以我们当然就略过这些东西，使用了OCruntime来打印出了实现，然后我们就能看到不同了。原始的方法和-methodForSelector:相同，但第二个完全不同。

作为优秀的探索者，我们在debugger中运行，这样我们可以清晰的看到第二个函数是什么：

(gdb) print (IMP)0x96a1a550
$1 = (IMP) 0x96a1a550 <_NSSetIntValueAndNotify>

这是某种私有方法，实现了观察的通知工作。通过使用Foundation中的nm -a，我们能够得到私有方法的完整列表。

0013df80 t __NSSetBoolValueAndNotify
    000a0480 t __NSSetCharValueAndNotify
    0013e120 t __NSSetDoubleValueAndNotify
    0013e1f0 t __NSSetFloatValueAndNotify
    000e3550 t __NSSetIntValueAndNotify
    0013e390 t __NSSetLongLongValueAndNotify
    0013e2c0 t __NSSetLongValueAndNotify
    00089df0 t __NSSetObjectValueAndNotify
    0013e6f0 t __NSSetPointValueAndNotify
    0013e7d0 t __NSSetRangeValueAndNotify
    0013e8b0 t __NSSetRectValueAndNotify
    0013e550 t __NSSetShortValueAndNotify
    0008ab20 t __NSSetSizeValueAndNotify
    0013e050 t __NSSetUnsignedCharValueAndNotify
    0009fcd0 t __NSSetUnsignedIntValueAndNotify
    0013e470 t __NSSetUnsignedLongLongValueAndNotify
    0009fc00 t __NSSetUnsignedLongValueAndNotify
    0013e620 t __NSSetUnsignedShortValueAndNotify

这个列表中我们可以发现很多有趣的东西。首先你可能看到了Apple不得不为它们想支持的每一个原始类型都实现了独立的函数。它们对于OC对象（_NSSetObjectValueAndNotify）只需要一个方法，但是需要对其余的部分实现一整套方法。这套方法好像不太完整，其中不包含long double _Bool的方法。甚至对普通指针类型也没有方法，就比如CFTypeDef的。尽管对于不同的常见Cocoa structs有几个函数，显然这里并没有其他特别多的structs的函数。这意味着这些类型的属性不能进行自动的KVO通知，一定要记住！！！

KVO是一个很强大的技术，有时候可能有点过于强大了，尤其是当涉及到自动通知的时候。现在你很清楚它内部是怎么工作的了，这个认知会帮助你决定怎么使用它（KVO），或者在出错的时候帮助你进行debug。

如果你准备在你自己的应用中使用KVO，你也许想看看我的文章Key-Value Observing Done Right。

总结

以下并非关键内容，大地瓜不翻译了。