13-8.【OC】【性能】Runtime 动态特性（消息转发 / Swizzle）对性能有何影响？Runtime 的动态

Runtime 的动态特性是 Objective-C 的灵魂，但从性能角度来看，它们本质上是用“预测性”换取“灵活性” 。无论是消息转发还是方法交换（Swizzle），都会在不同程度上破坏 CPU 的执行效率。

以下是这些动态特性对性能影响的深度量化分析：

1. 消息转发（Message Forwarding）的性能代价

消息转发是 Objective-C 动态性的最后一道防线。当 objc_msgSend 在缓存和方法列表中都找不到方法时，会进入转发流程。

动态方法解析 (resolveInstanceMethod:) ：中等开销。涉及一次运行时的系统调用来尝试添加方法。
快速转发 (forwardingTargetForSelector:) ：较高开销。虽然只是更换了对象，但它需要重新发起一轮全新的 objc_msgSend。
完全转发 (forwardInvocation:) ：极高开销（性能杀手）。
- 原因：系统必须在堆上创建一个 NSInvocation 对象，将所有的参数从寄存器拷贝到内存中，并构建完整的堆栈帧信息。
- 量化：完全转发的耗时通常是普通消息发送的 100 到 500 倍。

Swizzling 本质上是修改类对象的 method_list，将 Selector 指向一个新的 IMP（函数指针）。

一旦 Swizzle 完成，调用该方法依然是一次标准的 objc_msgSend。只要新的 IMP 被填入缓存，后续调用的速度与普通方法无异。

缓存失效（Cache Flushing） ：当你调用 method_exchangeImplementations 时，为了保证正确性，Runtime 会强制清空该类及其所有子类的方法缓存。
- 影响：如果在一个高频操作期间（如 App 启动或列表滚动）进行 Swizzling，会导致大量后续方法调用被迫走“慢速路径”（查找方法列表），造成瞬间的 CPU 抖动。
优化破坏：Swizzling 会彻底阻止编译器的内联优化和类型推断。

现代 CPU 极度依赖分支预测（Branch Prediction） 。

静态代码：CPU 可以预测下一条指令的地址并提前加载（Pipeline Prefetching）。
动态特性：
- 消息转发导致跳转目标极其不稳定，容易引发 分支预测失败（Branch Misprediction） 。
- 频繁的动态查找会导致 指令缓存（I-Cache） 频繁换入换出，增加指令加载的延迟。

特性	性能量化 (相对单位)	对性能的影响程度	主要开销来源
直接 IMP 调用	1.0x	极低	仅跳转
标准 objc_msgSend	2.5x - 3.0x	低	哈希查找
Method Swizzle	2.5x - 3.0x	低 (但增加维护成本)	同消息发送，但可能导致缓存失效
快速转发	10x - 20x	中	二次消息派发
完全转发	150x - 500x	极高	堆内存分配、参数拷贝、栈重构

慎用完全转发：如果只是为了重定向消息，优先使用 forwardingTargetForSelector:，它避免了 NSInvocation 的创建。
Swizzling 选时：尽量在 +load 方法中完成 Swizzling，避免在 App 运行中途动态交换，以减少缓存清空带来的冲击。
避免逻辑下沉：不要在底层的紧密循环（如 for 循环内部）依赖动态特性。如果必须动态，考虑在循环外获取 IMP 指针再进入循环。

Runtime 动态特性是强大的工具，但它们不应该是“免费”的午餐。消息转发适合作为容错机制或高级架构解耦，而不应作为高频业务逻辑的常态。