在 Swift 编译中，Whole Module Optimization (WMO, 全模块优化) 是一种将整个模块（Module）作为一个整体进行分析和优化的编译模式，而非默认的逐文件编译。
它是 Swift 性能优化的“黑科技”，能够让编译器在全局视角下进行更大胆的代码裁减和内联。
1. 默认编译模式：增量/逐文件编译 (Single File)
默认情况下，Swift 编译器采用**单文件（Single File）**模式：
- 工作方式：编译器每次只看一个
.swift文件，将其编译为对应的.o目标文件。 - 局限性：由于编译器不知道其他文件里具体写了什么，它必须假设其他文件可能会修改当前代码的行为。
- 后果：这限制了内联（Inlining）和泛型特化。如果文件 A 调用了文件 B 的函数，编译器通常只能生成一个动态调用（Dynamic Call），因为它在处理文件 A 时，看不见文件 B 的函数实现细节。
2. Whole Module Optimization (WMO) 的工作原理
开启 WMO 后，编译器会一次性读取模块内所有的源文件：
- 全局分析：编译器此时拥有了“上帝视角”。它知道某个类是否被继承，某个方法是否被重写，以及某个泛型函数在整个项目中具体被传入了哪些类型。
- SIL 合并：它将所有文件的 SIL（中间语言） 合并在一起进行统一优化，然后再交给 LLVM 生成机器码。
3. WMO 的核心优势
开启 WMO 后，编译器可以执行以下三种极具杀伤力的优化：
A. 激进的内联 (Aggressive Inlining)
在单文件模式下，编译器只能内联同一个文件里的函数。开启 WMO 后，它可以跨文件将函数实现直接插入调用处。
- 性能提升：消除函数调用开销（如压栈、跳转、出栈）。
B. 函数去虚化 (Devirtualization)
在单文件模式下，为了安全，编译器通常通过 V-Table 或 Witness Table 执行动态派发。
- WMO 的作用：如果编译器发现某个
public方法在整个模块中从未被重写（Override），它会自动将其视为final，并将动态派发优化为直接调用。
C. 泛型特化 (Generic Specialization)
这是 WMO 提升性能最显著的地方。
- 场景：文件 A 定义了
func process<T>(item: T)，文件 B 调用了process(item: 42)。 - WMO 优化：编译器能看到这个调用，于是专门为文件 A 的函数生成一个高效的
Int版本（特化），而不是使用开销巨大的通用泛型路径。
4. 权衡：编译速度 vs 运行性能
| 维度 | 单文件编译 (Incremental) | 全模块优化 (WMO) |
|---|---|---|
| 编译速度 | 快（仅重新编译修改过的文件） | 慢（即使改一个字也要全模块重跑） |
| 运行效率 | 一般 | 极高（通常提升 2x~5x） |
| 使用建议 | 开发调试阶段（Debug） | 正式发布阶段（Release） |
5. 为什么 WMO 对 Swift 如此重要？
Swift 是一门高度依赖协议和泛型的语言。这些特性在运行时通常需要大量的查找表（Table Lookups）。如果没有 WMO 提供的全局视角，编译器就无法在编译时移除这些抽象层。
这就是为什么在 Debug 模式下运行缓慢的代码，一旦切到 Release（默认开启 WMO）就会变得飞快。
如何在 Xcode 中设置？
- 选择项目 Target -> Build Settings。
- 搜索 Compilation Mode。
- Debug 通常设置为
Incremental（增量）。 - Release 通常设置为
Whole Module。
