前言

  Objective-C的消息传递与消息转发是其动态特性的核心，基于运行时（Runtime）系统实现。本文将从底层机制出发，详细解析消息传递的完整流程及消息转发的三个关键阶段，并结合源码（如 objc/runtime）和汇编层面进行深入探讨。

一、消息传递：objc_msgSend 的“查字典+递归找家长”流程

当调用 OC 对象的方法时（如 [obj doSomething]），编译器会将其转换为 C 函数调用：

objc_msgSend(obj, @selector(doSomething));

objc_msgSend是 OC 消息传递的核心函数，其本质是在接收者的类及其父类的方法列表中查找目标方法（SEL）的实现（IMP），并执行该实现。我们下面以OC 中调用方法（如 [dog 叫]）为例子，本质是让系统帮我们找到方法的实现代码（IMP）并执行。这个过程由 objc_msgSend 函数完成，它的执行逻辑像“查字典+递归找家长”，分三步：

1. 第一步：查“最近调用记录”（方法缓存）—— 最快即快速查找！

OC 运行时会为每个类维护一个方法缓存（methodCache_t），用于加速方法查找。缓存的结构是一个哈希表，键为 SEL（方法选择子），值为 IMP（方法实现的指针）。

objc_msgSend首先检查接收者类的缓存：

• 若缓存中存在目标 SEL，直接跳转到对应的 IMP执行（零成本缓存命中）。
• 若缓存未命中，进入类方法列表查找

例如，每个类（如 Dog 类）都有一个 方法缓存（Method Cache），类似手机的“最近通话记录”：

• 作用：存“最近调用过的方法名（SEL）”和对应的“实现代码地址（IMP）”，下次调用直接查缓存，无需重复计算。
• 为什么快：哈希表结构，查找时间复杂度接近 O(1)（常数级）。

例子：
你上周让 dog 叫过 3 次，系统就把“叫”这个方法名（SEL）和对应的“汪汪汪”实现（IMP）记在 Dog 类的缓存里。这周再调用 [dog 叫]，objc_msgSend 直接查缓存，秒级找到 IMP 并执行。

2. 第二步：翻“自己的字典”（类方法列表查找）—— 较慢！

若缓存未命中，objc_msgSend会从接收者的当前类开始，逐级向上遍历继承链（直到 NSObject或根类），在每个类的方法列表（method_list_t）中查找目标 SEL。

每个类的方法列表存储了该类自身定义的方法（不包括父类）。若当前类未找到，继续查找其父类的方法列表，直到根类（如 NSObject）的父类为 nil，此时查找失败。

例子：
如果缓存里没找到（比如第一次调用 [dog 叫]），objc_msgSend 会去当前类的“字典”（方法列表）里找。每个类的方法列表存着自己定义的所有方法（类似字典的“正文”）。 Dog 类的字典里有 叫、跑 等方法的定义（SEL 是“叫”，IMP 是“汪汪汪”的代码）。objc_msgSend 遍历这个字典，找到“叫”对应的 IMP，执行。

3. 第三步：递归“找家长”（父类方法列表）—— 最慢！

如果当前类的字典里也没有（比如 Dog 类没写 叫 方法），objc_msgSend 会去父类的字典里继续找（类似“问爸爸有没有这个词的解释”）。一直找到根类（如 NSObject）的父类（nil），若最终找到目标 SEL的 IMP，则将该 SEL与 IMP的映射写入当前类的方法缓存（后续调用直接命中缓存），并跳转到 IMP执行方法逻辑；还没找到，就触发消息转发。

总结：消息传递的“三级跳”

调用 [dog 叫] → objc_msgSend 开始：

1.查 Dog 类的缓存 → 找到？直接执行（最快）。

2.没找到 → 查 Dog 类的方法列表 → 找到？执行（较快）。

3.没找到 → 递归查父类（Animal → NSObject）的方法列表 → 找到？执行（较慢）。

4.全没找到 → 触发消息转发（兜底逻辑）。

二、消息转发：快递送不到时的“三级补救方案”

若 objc_msgSend遍历完缓存、当前类、父类继承链仍未找到目标 SEL的 IMP，OC 运行时会触发**消息转发（Message Forwarding）**机制，尝试通过一系列回调让开发者有机会“补救”未处理的消息。消息转发分为三个阶段，按顺序执行且不可逆（前一阶段成功则后续阶段不再触发）。

阶段 1：动态方法解析（自己加方法）——“我马上补一个！”

Objective-C（OC）的消息传递与消息转发是其动态特性的核心，基于运行时（Runtime）系统实现。本文将从底层机制出发，详细解析消息传递的完整流程及消息转发的三个关键阶段，并结合源码（如 objc/runtime）和汇编层面进行深入探讨。

一、消息传递的本质：objc_msgSend的执行流程

当调用 OC 对象的方法时（如 [obj doSomething]），编译器会将其转换为 C 函数调用：

objc_msgSend(obj, @selector(doSomething));

objc_msgSend是 OC 消息传递的核心函数，其本质是在接收者的类及其父类的方法列表中查找目标方法（SEL）的实现（IMP），并执行该实现。整个过程可分为以下步骤：

1. 快速查找：方法缓存（Method Cache）

OC 运行时会为每个类维护一个方法缓存（methodCache_t），用于加速方法查找。缓存的结构是一个哈希表，键为 SEL（方法选择子），值为 IMP（方法实现的指针）。

objc_msgSend首先检查接收者类的缓存：

• 若缓存中存在目标 SEL，直接跳转到对应的 IMP执行（零成本缓存命中）。
• 若缓存未命中，进入类方法列表查找。

2. 类方法列表查找

若缓存未命中，objc_msgSend会从接收者的当前类开始，逐级向上遍历继承链（直到 NSObject或根类），在每个类的方法列表（method_list_t）中查找目标 SEL。

每个类的方法列表存储了该类自身定义的方法（不包括父类）。若当前类未找到，继续查找其父类的方法列表，直到根类（如 NSObject）的父类为 nil，此时查找失败。

3. 缓存更新与结果返回

若最终找到目标 SEL的 IMP，则将该 SEL与 IMP的映射写入当前类的方法缓存（后续调用直接命中缓存），并跳转到 IMP执行方法逻辑。

二、消息转发：当消息无法被处理时

若 objc_msgSend遍历完继承链仍未找到目标 SEL的 IMP，OC 运行时会触发**消息转发（Message Forwarding）**机制，尝试通过一系列回调让开发者有机会“补救”未处理的消息。消息转发分为三个阶段，按顺序执行且不可逆（前一阶段成功则后续阶段不再触发）。

阶段 1：动态方法解析（Dynamic Method Resolution）

运行时首先调用类的类方法 +resolveInstanceMethod:（针对实例方法）或 +resolveClassMethod:（针对类方法），允许开发者动态添加方法实现。系统先问当前类：“你能自己写一个这个方法吗？”（调用 +resolveInstanceMethod:）。这时候我们可以用 class_addMethod 动态添加方法实现，相当于“临时补字典条目”。

例子：
我们发现 Dog 类忘记实现 叫 方法，于是在 +resolveInstanceMethod: 里补上：

+ (BOOL)resolveInstanceMethod:(SEL)sel {if (sel == @selector(叫)) { // 动态添加方法：SEL 是“叫”，IMP 是“汪汪汪”的代码class_addMethod(self, sel, (IMP)叫的实现, "v@:"); return YES; // 返回YES，表示消息已经被处理，即告诉系统：“我自己解决了！”，objc_msgSend会重新尝试发送消息（此时缓存已更新）。}return [super resolveInstanceMethod:sel];
}// 方法实现（IMP）
void 叫的实现(id self, SEL _cmd) {NSLog(@"汪汪汪！");
}

如果成功，系统会把新方法加入缓存，下次调用直接命中。

阶段 2：快速转发（转交给其他对象）——“我找朋友帮忙！”

如果动态解析失败（+resolveInstanceMethod:返回 NO），运行时会调用实例方法 -forwardingTargetForSelector:，允许开发者指定一个备用接收者（Forwarding Target），将消息转发给该对象处理。动态解析失败比如你不想自己加方法，系统问：“你能找个朋友（其他对象）帮我处理吗？”（调用 -forwardingTargetForSelector:）。你返回一个能处理该消息的对象，相当于“把快递转交给邻居”。

例子：
Dog 类发现自己不会“叫”，但它的朋友 Cat 类会，于是返回 Cat 的实例：

- (id)forwardingTargetForSelector:(SEL)aSelector {if (aSelector == @selector(叫)) {return [Cat new]; // 找 Cat 帮忙}return [super forwardingTargetForSelector:aSelector];
}

若返回非 nil对象，消息会被发送给该对象（相当于“代理”模式）；若返回 nil，进入下一阶段。上述代码中系统会把 [dog 叫] 转发给 Cat 对象，如果 Cat 会“叫”，消息就被正确处理。

阶段 3：完整转发（自定义处理流程）——“我自己写个转单系统！”

若前两阶段均失败（一般是快速转发未提供备用接收者），运行时会触发完整的消息转发流程，核心是构造一个 NSInvocation对象封装消息信息，并调用 -forwardInvocation:方法让开发者自定义处理。就例如你找不到能帮忙的对象，系统启动“完整转发”：把消息（谁发的、方法名、参数）打包成 NSInvocation 对象，调用 -forwardInvocation: 让你自定义处理。你需要自己决定如何处理这个消息（比如转给其他对象、修改参数、记录日志）。

例子：
你重写 -forwardInvocation:，把消息转给 Cat，并记录日志：

- (void)forwardInvocation:(NSInvocation *)invocation {// 1. 获取原消息的信息（方法名、参数）SEL sel = invocation.selector;id target = [Cat new]; // 临时目标// 2. 修改消息目标为 Cat[invocation setTarget:target]; // 改成转给 Cat[invocation invoke]; // 重新发送消息// 3. （可选）获取返回值并处理id result;[invocation getReturnValue:&result];NSLog(@"转发成功，结果是：%@", result);
}// 必须实现：获取目标方法的签名（NSMethodSignature），用于描述方法的参数、返回值类型等信息。若未实现此方法，会直接抛出 unrecognized selector异常。
- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector {if (aSelector == @selector(叫)) {return [NSMethodSignature signatureWithObjCTypes:"v@:"]; // 无参数，返回 void}return [super methodSignatureForSelector:aSelector];
}

若 -methodSignatureForSelector:未实现或返回 nil，运行时会直接抛出 NSInvalidArgumentException（unrecognized selector sent to instance）。

关键注意点：

• 如果 -methodSignatureForSelector: 没实现或返回 nil，系统会直接抛出 unrecognized selector sent to instance 崩溃（常见错误）。

---

三、底层原理：用汇编看 objc_msgSend 的“高效魔法”

objc_msgSend 是用 ARM64 汇编 写的，核心逻辑用几行伪代码概括：

objc_msgSend:// 1. 检查接收者是否为 nil（OC 允许向 nil 发消息）cbz x0, LReturnNil  // 如果 receiver 是 nil，直接返回 0// 2. 查缓存：从 receiver 的 isa 指针找到类，然后在缓存里找 SELldr x1, [x0]        // x1 = receiver->isa（类的地址）CacheLookup         // 汇编指令：在类的缓存里查 SEL 对应的 IMP// 3. 缓存命中：直接跳转到 IMP 执行br x2               // x2 是缓存的 IMP 地址，跳转执行LReturnNil:mov x0, #0          // 返回 0（对应 nil 消息的处理）ret

为什么快：缓存查找是汇编级别的优化，几乎无额外开销；方法列表查找是递归遍历，但仅在缓存未命中时触发。

四、总结

OC 的消息传递与转发机制，本质是 “运行时动态性” 的体现：

• 高效性：通过缓存和方法列表的层级查找，平衡了“首次调用”和“重复调用”的性能。
• 灵活性：消息转发的三阶段设计，允许开发者在运行时动态修复未处理的方法（如 KVO、动态代理）。

一句话总结：objc_msgSend 像一个“智能快递员”，先查最近记录（缓存），再翻自己家抽屉（方法列表），最后递归问家长（父类）；找不到时，系统给你三次“补救机会”（动态解析→快速转发→完整转发），确保消息“不轻易丢失”。**