虽然 Objective-C 的消息机制带来了极大的灵活性，但在某些对性能、安全或确定性有极致要求的场景下，开发者会选择“跳过” objc_msgSend，转而使用 C 函数或 C++ 静态方法。
以下是你会刻意避免使用 Objective-C 方法调用的典型场景：
1. 高频循环与实时渲染
在处理音频采样、图形渲染（如 CADisplayLink 回调）或大规模数据处理时，哪怕 objc_msgSend 只有几十个时钟周期的开销，累积起来也会非常惊人。
-
场景： 在一个每秒执行 60 次的循环中处理成千上万个点。
-
做法： * 使用 C 函数 处理核心算法。
- 或者通过
method_getImplementation提前获取 IMP（函数指针） ，在循环中直接调用 C 指针，跳过消息查找流程。
- 或者通过
2. 编写底层库或被多语言调用的模块
如果你在编写一个可能被 C、C++ 或 Swift 共同调用的底层工具库（如加密库、图片解码器），使用 Objective-C 方法会引入不必要的依赖和互操作成本。
- 场景： 跨平台的底层核心逻辑。
- 理由： C 函数具有最通用的 ABI，不需要 Objective-C Runtime 即可运行。这使得代码更容易移植到非 Apple 平台，或者在 Swift 中直接调用而无需经过桥接开销。
3. 避免“动态性”带来的安全隐患（逆向与 Hook）
Objective-C 的动态性是一把双刃剑。由于方法可以通过 Method Swizzling 被轻易拦截，敏感逻辑（如安全校验、支付验证）如果写在 Obj-C 方法里，很容易被黑客 Hook。
- 场景： 越狱检测、签名校验、核心加解密逻辑。
- 做法： 使用 C 函数 或 静态内联函数 (
static inline) 。 - 理由： C 函数的符号可以被
strip（剥离），且地址在编译期或链接期相对固定，逆向分析者很难像定位 Obj-C 选择子那样轻松地拦截它们。
4. 解决“初始化顺序”与“死锁”问题
Objective-C 的方法调用依赖于 Runtime 的初始化。在某些极早期的启动阶段（如 __attribute__((constructor)) 动态库加载阶段），Obj-C 的运行环境可能尚未完全就绪。
- 场景： 底层监控组件、性能日志记录器。
- 理由： 在复杂的并发环境下，特别是涉及线程锁或底层信号处理时，调用 Obj-C 方法可能导致重入冲突或死锁。C 函数不依赖类对象的
isa查找，行为更可控。
5. 极致的编译器优化（内联需求）
如果你希望某个非常简单的方法（如返回一个坐标、计算两个数的最大值）能够被编译器**内联（Inlining）**以彻底消除调用开销。
- 场景： 数学运算、状态检查。
- 做法： 使用
static inline函数。 - 理由： Objective-C 方法永远无法被内联。使用 C 的内联函数可以减少函数调用的压栈开销，并允许编译器进行跨行指令优化。
总结建议
| 需求 | 推荐方式 | 理由 |
|---|---|---|
| 极致性能 (循环内) | IMP 指针调用 | 保留 Obj-C 逻辑但跳过 msgSend 查找 |
| 算法/数据处理 | C 函数 / C++ 静态方法 | 编译器可内联，无隐式参数开销 |
| 防 Hook/防逆向 | C 静态函数 | 符号隐藏，调用关系静态化 |
| 跨平台通用 | 标准 C 函数 | 兼容性最强，无 Runtime 依赖 |
