13-10.【OC】【性能】在工程实践中，如何优化 OC / Swift 混编项目的性能？在工程实践中，OC/Swift

在工程实践中，OC/Swift 混编项目的性能优化不仅关乎算法，更关乎桥接成本（Bridging Cost） 、编译效率以及二进制体积。

以下是针对混编项目的五大核心优化维度：

1. 降低桥接层的调用开销

跨语言调用并非零成本。每一次 OC 调用 Swift（或反之）都可能触发 Thunk 函数、参数转换和引用计数重平衡。

减少跨语言频率：将高性能需求的逻辑（如复杂的循环、图形计算）完整保留在单一语言内。避免在 Swift 循环中频繁调用 OC 方法。
缓存 IMP 指针：如果必须从 OC 高频调用 Swift 方法，可以在初始化时通过 methodForSelector: 预先获取 Swift 方法的 IMP 指针，直接进行函数指针调用，绕过 objc_msgSend。
优化数据转换：
- 避免在桥接边界频繁传递庞大的 String 或 Data，因为它们可能在 NSString 与 String 之间发生拷贝。
- 尽量传递简单的基础类型（Int, Bool, Double）。

过度暴露 Swift 成员会显著增加二进制体积和运行时元数据负担。

禁用 @objcMembers：不要在整个类上使用该标记。仅在必要的属性和方法前添加 @objc。
利用 private 修饰符：默认情况下，private 成员不会生成桥接头文件，这可以减少生成的 -Swift.h 大小，提高 OC 端的编译速度。
死代码消除：定期使用工具（如 Periphery）扫描未使用的 @objc 方法。这些方法虽然 Swift 没调，但因为有 @objc 标记，编译器无法将其从二进制中剥离。

混编环境下，内存管理容易出现“两头不到岸”的性能空窗。

主动管理 Autoreleasepool：OC 方法返回的对象往往进入自动释放池。在 Swift 的 for 循环中调用 OC 接口时，务必手动包裹 autoreleasepool { ... }，防止内存峰值导致的系统频繁内存回收压力。
弱引用性能优化：
- OC 端的 __weak 依赖全局哈希表，而 Swift 的 weak 在 ABI 稳定后有更高效的 Inline 实现。
- 在混编模型中，如果确定生命周期，优先在 Swift 端持有强引用，OC 端仅做简单指针传递。

混编项目往往面临“全量编译”的困境。

模块化隔离：将稳定的 OC 代码封装成 Framework 或 Swift Package。这样 Swift 编译器只需读取二进制的 .swiftmodule，而无需每次都去解析庞大的 Bridging-Header.h。
精简 Bridging-Header：桥接头文件越重，Swift 编译每个文件的预处理时间就越长。只在里面放 Swift 必须访问的头文件，其他 OC 代码通过类的前向声明（@class）处理。
开启 Library Evolution：对于大型项目，开启组件的库演进支持，可以避免因 Swift 库底层修改导致的整个宿主项目全量重新编译。

避免 Protocol 的消息派发：
- 如果 Swift 协议标记了 @objc，它在 Swift 内部也会丧失 PWT (Protocol Witness Table) 的静态特性，转而使用 objc_msgSend。
- 策略：除非 OC 真的要遵循这个协议，否则不要加 @objc。
结构体与类包装：对于频繁在 OC 使用的 Swift Struct，为其编写一个单例或缓存池管理的 Class 包装器（Wrapper），避免频繁的包装/拆箱操作。

在混编项目中，性能优化往往是“反直觉”的。有时候为了性能，你可能需要将一个优雅的 Swift 特性（如带关联值的 Enum）降级为 OC 能理解的 Class。