在iOS开发的日常工作中，我们经常与KVO和KVC打交道。对于hen多开发者来说会用它们只是基本功，但要是被问到“它们底层到底是怎么运作的？”，恐怕不少人心里会打鼓。今天我们就抛开那些枯燥的文档，像拆解一台精密的仪器一样，把这两者的底层原理彻底摊开来kankan。

一、 KVO：不仅仅是“监听”那么简单

KVO，全称Key-Value Observing，也就是我们常说的“键值监听”。它提供了一种机制，允许当某个对象的属性发生变化时Neng够通知到观察者。虽然用起来hen方便，但它的效率其实比代理模式要低一些。为什么这么说呢？因为KVO为了实现这个功Neng，需要在运行时动态地创建一个新的类，这个过程本身是需要消耗资源的。

1.1 动态生成的子类：NSKVONotifying_

当你对一个对象添加了观察者之后系统并没有直接在这个对象上Zuo文章，而是悄悄地在Runtime运行时创建了一个全新的类。这个类的命名规则非常有意思，通常是`NSKVONotifying_`加上原类名，比如`NSKVONotifying_Person`。

我们Ke以通过一段代码来验证这个有趣的现象。假设我们有两个对象，`person1`被添加了KVO监听，而`person2`没有：

- viewDidLoad {
    ;
    self.person1 =  init];
    self.person1.age = 10;
    self.person2 =  init];
    self.person2.age = 10;
    NSLog(@"监听之前 - person1: %p, person2: %p",
          ,
          );
    // 对person1开启监听
    NSKeyValueObservingOptions options = NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld;
    ;
    NSLog(@"监听之后 - person1: %p, person2: %p",
          ,
          );
}

运行这段代码，你会发现日志输出中，`person1`的`setAge:`方法地址发生了变化。在LLDB调试窗口中打印这个地址，你会发现它指向了一个名为`_NSSetIntValueAndNotify`的内部函数，而不是原本的`Person`类中的实现。这就证明了系统在背后搞了鬼。

geng有趣的是Ru果我们打印这两个对象的类对象：

NSLog, object_getClass);

你会发现，`person1`的类对象Yi经变成了`NSKVONotifying_Person`，而`person2`依然是`Person`。这就是KVO的核心黑魔法：ISA指针欺骗。系统在运行时修改了`person1`的isa指针，让它指向了那个动态生成的子类。

1.2 NSKVONotifying子类到底Zuo了什么？

这个动态生成的子类主要Zuo了三件事：

重写Setter方法这是Zui关键的一步。它重写了被监听属性的setter方法。

重写class方法为了掩人耳目，这个子类重写了`class`方法，让它返回原本的类名。这样开发者在调用``时根本察觉不到类Yi经被替换了。

调用内部通知函数在重写的setter中，它会调用Foundation框架中的`_NSSetXXXValueAndNotify`函数。

1.3 _NSSetXXXValueAndNotify的内部逻辑

这个神秘的内部函数到底干了啥？其实它的逻辑非常清晰，主要分为四步：

调用`willChangeValueForKey:`;

调用父类的setter方法，真正去修改成员变量的值;

调用`didChangeValueForKey:`;

在`didChangeValueForKey:`内部，系统会自动通知观察者，触发`observeValueForKeyPath:ofObject:change:context:`方法。

为了验证这个流程，我们Ke以在`Person`类中重写`willChangeValueForKey`和`didChangeValueForKey`：

@implementation Person
- setAge:age {
    _age = age;
}
- willChangeValueForKey:key {
    ;
    NSLog;
}
- didChangeValueForKey:key {
    NSLog;
    ;
    NSLog;
}
@end

当你触发修改时日志会清晰地打印出“即将改变”、“原setter执行”、“值Yi经改变”的顺序。这就像是一个精密的接力赛，每一步dou环环相扣。

1.4 几个常见的“坑”

了解了原理，hen多问题就迎刃而解了。

Q1: 直接修改成员变量会触发KVO吗？ 答案是：不会。因为KVO的本质是重写setter方法，Ru果你直接通过`_age = 20`或者`self.person1->_age = 20`去修改，这就绕过了setter方法，自然也就不会触发`willChangeValueForKey`和`didChangeValueForKey`，观察者收不到通知。

Q2: 如何手动触发KVO？ 有时候我们需要在 setter 之外触发通知，这时候Ke以手动调用那两个核心方法：

;
;

只要调用了这对组合拳，观察者就会收到回调。

Q3: KVC赋值Neng触发KVO吗？ 答案是：Neng。因为KVC在查找赋值路径时Zui终也会找到并调用属性的setter方法。既然调用了setter，那么KVO的流程自然就被激活了。

二、 KVC：灵活的“键值编码”

说完了KVO，我们来kankan它的好基友KVC。KVC允许开发者通过字符串的名字来访问对象的属性，而不需要通过明确的存取方法。这是一种非常灵活、甚至有点“暴力”的访问方式。

2.1 KVC的赋值流程：一场精密的搜索

当你调用``时OC底层并不是简单地去找`age`变量，而是有一套极其复杂的查找逻辑。我们Ke以把它想象成系统在玩一场“寻宝游戏”。

第一步：按顺序查找Setter方法 系统会依次尝试寻找以下两个方法： 1. `setAge:` 2. `_setAge:` 只要找到了其中一个，系统就会直接调用它，传递参数，任务结束。

我们Ke以写代码验证一下。假设`Person`类里只有`_setAge:`方法：

@implementation Person
- _setAge:age {
    NSLogage);
}
@end

当你使用KVC赋值时日志会显示`_setAge`被调用了。这证明了KVC对方法名的宽容度hen高。

第二步：检查accessInstanceVariablesDirectly Ru果上面两个setter方法dou没找到，系统会去检查类方法`+ accessInstanceVariablesDirectly`。这个方法默认返回`YES`，意思是“允许直接访问成员变量”。Ru果它返回`NO`，系统就会直接抛出异常`NSUnknownKeyException`，游戏结束。

第三步：按顺序查找成员变量 Ru果允许直接访问，系统就会开始在这个类的成员变量列表里找。查找的顺序非常严格，不Neng乱： 1. `_age` 2. `_isAge` 3. `age` 4. `isAge` 一旦找到对应的成员变量，就直接赋值。Ru果这四个dou没找到，那就只Neng抛出异常了。

2.2 KVC的取值流程：同样的逻辑，反向操作

取值的逻辑也差不多，只不过找的是Getter方法。

第一步：按顺序查找Getter方法 系统会依次尝试： 1. `getAge` 2. `age` 3. `isAge` 4. `_age` 只要找到，就调用并返回值。

第二步：检查accessInstanceVariablesDirectly Ru果没找到方法，同样检查这个标志位。

第三步：按顺序查找成员变量 Ru果允许，就按照 `_age` -> `_isAge` -> `age` -> `isAge` 的顺序去读取成员变量的值。

2.3 Key与KeyPath的区别

在使用KVC时hen容易混淆Key和KeyPath。

Key通常指当前对象的一个属性名，比如`@"frame"`、`@"age"`。它只Neng接受当前类拥有的属性。

KeyPath这是一个geng强大的概念，它支持“点语法”式的路径，Ke以访问属性的属性。比如你想修改一个View的圆角，Ke以直接用`layer.cornerRadius`作为KeyPath。这就像是在文件系统中指定一个深层目录一样。

// Swift示例，OC同理
view.setValue

三、 与面试避坑指南

通过上面的分析，我们Ke以kan到KVO和KVC的设计精妙之处。KVO利用Runtime的动态特性，通过ISA指针的“偷天换日”实现了非侵入式的监听；而KVC则通过一套严谨的查找顺序，实现了灵活的属性访问。

在面试中，Ru果遇到相关问题，记住以下几个核心点，基本就Neng稳住阵脚：

KVO的本质动态生成子类`NSKVONotifying_X`，重写setter，修改isa指针。

KVO内部调用`willChangeValueForKey` -> 原setter -> `didChangeValueForKey`。

成员变量修改不触发KVO因为绕过了setter。

KVC赋值顺序`setKey:` -> `_setKey:` -> 检查`accessInstanceVariablesDirectly` -> 查找成员变量。

KVC取值顺序`getKey`, `key`, `isKey`, `_key`。

Zui后别忘了在控制器销毁的时候移除观察者，否则hen可Neng会因为向Yi释放的对象发送消息而导致Crash。虽然现在的ARC环境有所改善，但养成良好的习惯总是没错的。

理解这些底层原理，不仅Neng帮我们通过面试，gengNeng在遇到一些奇怪的Bug时让我们拥有上帝视角，一眼kan穿问题的本质。这就是iOS开发的魅力所在——在封装与底层之间游走，探索未知的边界。

---