编译工程 on Last Stand

编译优化-Bazel方案

Sat, 02 May 2026 22:32:27 +0800

当 iOS 工程的规模突破 CocoaPods / Xcode 原生构建体系的舒适区，Bazel 就成为下一代构建系统的首选。字节跳动的头条、抖音、Airbnb、Uber、Lyft、Pinterest、Square、Bilibili 等都已把 iOS 工程迁到 Bazel。本文介绍 Bazel 的核心原理、在 iOS 上的生态（rules_apple / rules_swift / rules_xcodeproj）以及大厂落地实践。

为什么是 Bazel

CocoaPods + Xcode 在超大工程上的固有瓶颈：

粗粒度依赖：以 Pod / Target 为单位，增量编译颗粒粗
隐式依赖：Build Phases 隐含顺序，难以沙箱化
难以远程缓存：编译环境非 hermetic，hash 易变
难以远程执行：Xcode Build System 绑定本地 macOS

Bazel 针对这些问题从设计之初就提供了：

能力	Bazel	Xcode/CocoaPods
依赖粒度	文件级	Target 级
依赖显式化	必须声明	部分隐式
Sandbox	默认开启	无
远程缓存	原生	需第三方（ccache/Rugby）
远程执行	原生	不支持
跨语言	一流（Swift/OC/C++/Go/Rust/JS）	主要 Apple 平台
多平台	天生	iOS/macOS 为主

Bazel 核心概念

Workspace 与 Package

WORKSPACE # 仓库根，声明外部依赖
foo/
├── BUILD.bazel # package，本目录的构建声明
├── main.swift
└── util/
 └── BUILD.bazel # 子 package

Workspace：整个 Bazel 仓库，一个 WORKSPACE 文件一个仓
Package：任何包含 BUILD.bazel 的目录
Target：BUILD 文件里的一个 rule 调用，比如 swift_library(name = "foo")
Label：Target 的全局 ID，形如 //foo/util:util

Rule

Rule 是构建函数，输入 sources + deps，输出 artifacts：

编译优化-CocoaPods优化

Sat, 02 May 2026 22:32:27 +0800

在 iOS 生态中，CocoaPods 依然是大多数中大型工程的依赖管理工具。当 Pod 数量达到几百个子组件上千个时，pod install 的耗时会变成研发流程里的硬性卡点。抖音在其 seer-optimize 项目中系统化地优化了 CocoaPods 的整个生命周期，全量 Pod Install 耗时减少 50%、增量减少 65%。本文系统介绍这些优化背后的原理。

关于 CocoaPods 整体架构的深度介绍可以参考 CocoaPods源码导读-架构总览。

Pod Install 耗时构成

Installer#install! 的六个阶段：

flowchart LR
A[prepare] --> B[resolve_dependencies]
B --> C[download_dependencies]
C --> D[validate_targets]
D --> E[generate_pods_project]
E --> F[integrate_user_project]

抖音公开的典型耗时分布：

阶段	典型耗时	说明
prepare	< 0.01s	初始化
resolve_dependencies	数秒到数分钟	依赖决议，瓶颈
download_dependencies	数秒到数分钟	依赖下载，IO 密集
validate_targets	0.1s	校验
generate_pods_project	数秒到数十秒	生成 xcodeproj
integrate_user_project	0.01s	集成主工程

resolve_dependencies 优化

Source 仓库更新

默认 CocoaPods 在 pod install --repo-update 时会更新所有 source 仓库。抖音改造为：

编译优化-Explicit Modules

Tue, 05 May 2026 00:41:41 +0800

Apple 从 Xcode 15 开始在 Swift 上引入 Explicit Modules，Xcode 16 在 C/C++/Objective-C 上全面铺开，Xcode 17 进一步默认启用并与细粒度依赖追踪结合。这是近五年 Apple 构建系统最重要的一次变革，直接影响到大部分项目的编译模型。

模块（Module）基础

为什么需要模块

C 家族语言的 #include 机制有两个致命问题：

文本替换：头文件是纯文本替换，每个源文件都要重新解析一遍所有包含的头文件
宏污染：先引入的头文件宏会影响后续头文件的行为，没有隔离

Clang 在 2012 年引入 Clang Modules，用一个预编译的二进制模块（.pcm）替代文本包含，同一 module 在一次构建里只解析一次。Swift 的 .swiftmodule 从设计之初就是模块化的。

flowchart LR
A["源文件"] -->|"include 头文件"| B["Foundation.h 文本"];
B --> C["每次都重新解析"];
D["源文件"] -->|"@import Foundation"| E["Foundation.pcm 预编译"];
E --> F["一次解析，多次复用"];

模块的组成

类型	载体	描述
Clang Module	`.pcm`	C/OC 模块的序列化 AST
Swift Module	`.swiftmodule`	Swift 模块的接口 + SIL
Swift Interface	`.swiftinterface`	可被不同 Swift 版本解析的文本接口
Module Map	`module.modulemap`	描述哪些头文件构成某个 module

Implicit Modules 的问题

原理

在 Xcode 16 之前，Clang Modules 以隐式方式工作：

编译优化-Swift编译优化

Sat, 02 May 2026 22:32:27 +0800

Swift 的类型推导、泛型约束求解、WMO / CMO 是编译性能的核心影响因素。理解它们能让源码层面的小改动带来显著的编译加速。本文聚焦"代码写法 + 编译开关"两方面的优化。

Swift 编译流程速览

相比 C/OC，Swift 编译多出大量工作：

flowchart LR
A[Parse] --> B[Sema
类型检查]
B --> C[SILGen
生成 SIL]
C --> D[SIL Optimization]
D --> E[IRGen
LLVM IR]
E --> F[LLVM Optimization]
F --> G[CodeGen]

其中 Sema（语义分析） 阶段负责类型推导，是 Swift 特有的性能热点。-debug-time-compilation 看到的 “Type checking” 时间基本都集中在这里。

类型推导与 “Too Complex” 错误

约束求解

Swift 的类型系统比大多数语言复杂：

函数重载 + 运算符重载
隐式字面量类型（Int、Double、Float80…）
泛型 + 协议 + 关联类型
闭包参数类型推导
SwiftUI 风格的 ViewBuilder / Result Builders

遇到表达式 let x = a + b * c - d，编译器需要给 + * - 每个运算符枚举所有可能的重载，在多个候选里做约束传播。当候选组合爆炸时，Sema 会放弃并抛出：

编译优化-Xcode构建系统

Sat, 02 May 2026 22:32:27 +0800

Xcode 的构建系统由多个组件协同完成，从 Cmd+B 到生成 .app 经历了完整的任务图构建、依赖分析、并行调度流程。理解这套体系是后续一切优化的基础。

构建系统组成

Xcode 10 之后默认采用 Swift Build System（基于 llbuild），整体架构如下：

flowchart TD
A[Xcode IDE] --> B[XCBBuildService
Daemon]
B --> C[Build Description
任务图 JSON]
C --> D[llbuild
调度内核]
D --> E1[Swift Driver / swiftc]
D --> E2[clang]
D --> E3[ld / ld-prime]
D --> E4[actool / ibtool / 脚本]
E1 & E2 & E3 & E4 --> F[产物缓存]

组件	职责
`XCBBuildService`	独立进程，为 Xcode / xcodebuild 提供构建 RPC 服务
Build Description	根据 Scheme、Target、Build Settings 生成的任务图
`llbuild`	通用构建引擎，执行任务图、做增量与并行调度
`swift-driver`	Swift 编译驱动，生成 frontend job 并驱动 swiftc
`clang` / `swift-frontend`	真正的编译器前端
`ld` / `ld-prime`	链接器

XCBBuildService

Xcode 和 xcodebuild 都是客户端，真正的构建逻辑在 XCBBuildService 这个独立进程。它通过 XPC 接收请求，生成并执行任务。社区工具 XCBBuildServiceProxy 利用这一架构在中间插一层代理，实现自定义构建（Bazel、远程执行等）。字节 BitSky、Tuist Cloud 都基于此类模式。

编译优化-二进制化

Sat, 02 May 2026 22:32:27 +0800

二进制化是大型 iOS 工程编译加速的"银弹"：把组件从源码编译改成预编译产物链接，在本地无需再跑 Swift/Clang 前端，直接链接已有的 .a / .framework / .xcframework。美团在 cocoapods-hmap-prebuilt 之外，还通过二进制化把整体编译速度提升 50%+。本文系统介绍二进制化的原理、实现方式与工具链。

为什么能加速

典型项目的编译时间分布（抖音量级）：

pie title 冷编译耗时占比
"业务代码编译" : 25
"第三方依赖编译" : 50
"链接" : 15
"其他" : 10

超过一半的时间都花在编译 “不会改” 的依赖上。把依赖预编译成二进制，本地只需要链接，这部分耗时直接归零。再配合远程缓存，第一次拉代码的同学也能命中他人产物。

二进制产物形态

静态库（.a）

最传统的形态：

libSDWebImage.a
SDWebImage/Headers/
├── SDWebImage.h
└── ...

特点：

最小体积，Mach-O 里没有 LC_SEGMENT_64 / LC_LOAD_DYLIB 负担
启动最快，无 dyld 成本
静态链接时整合到主可执行
不支持资源文件（需要单独管理 bundle）

Framework（.framework）

Apple 推荐的打包形态：

SDWebImage.framework/
├── SDWebImage # 二进制（静态或动态）
├── Headers/ # 公开头文件
├── Modules/ # modulemap、swiftmodule
│ ├── module.modulemap
│ └── SDWebImage.swiftmodule/
│ ├── arm64-apple-ios.swiftmodule
│ └── arm64-apple-ios.swiftinterface
└── Info.plist

通过 Mach-O Type 设置决定内部是静态还是动态库：

编译优化-二进制化实现原理

Fri, 08 May 2026 22:56:38 +0800

本文结合 cocoapods-bin（社区最成熟的二进制化插件）拆解"Pod 二进制化"背后的工程机制：集成时如何透明替换 spec、打包时如何还原 Xcode 产物、调试时如何跳回源码。文末给出"自研一套二进制系统"的落地 checklist。

想先了解二进制化的整体背景、坑点和适用场景，可以先看编译优化-二进制化；想了解 pod install 阶段本身的优化（HMap、并发下载等）见编译优化-CocoaPods优化。

总体架构

一套完整的 Pod 二进制化系统由三层组成：

flowchart TB
subgraph CI[打包 CI]
A1[源码 podspec] --> A2[壳工程 pod install]
A2 --> A3[xcodebuild 双 SDK 编译]
A3 --> A4[lipo / create-xcframework]
A4 --> A5[上传 OSS]
A5 --> A6[生成 binary podspec]
A6 --> A7[push 到二进制仓]
end
subgraph Dev[开发机 pod install]
B1[Podfile 声明 plugin] --> B2[Resolver/LazySpecification Hook]
B2 --> B3{二进制仓
是否有该版本?}
B3 -- 是 --> B4[替换为 binary spec]
B3 -- 否 --> B5[回退源码 spec]
B4 --> B6[pod download zip]
B5 --> B6
B6 --> B7[Xcode 链接]
end
subgraph Debug[调试]
C1[dwarfdump 读取
DW_AT_comp_dir] --> C2[下载源码]
C2 --> C3[软链到 DWARF 路径]
C3 --> C4[LLDB 自动跳转源码]
end
A7 --> B3
A3 -.DWARF 路径信息.-> C1

关键设计点：

编译优化-头文件与HMap

Sat, 02 May 2026 22:32:27 +0800

对以 Objective-C 为主或混编的 iOS 大型工程，头文件查找是一个被严重低估的编译开销点。美团的统计显示，400+ Pod 组件的工程会产生近 5 万个头文件，导致海量的 IO 操作和编译参数膨胀。Header Map（HMap）技术能把头文件查找从 O(n) 的目录扫描退化为 O(1) 的哈希查表。

头文件查找的代价

Clang 的查找流程

当 Clang 遇到 #import <AFNetworking/AFNetworking.h> 时：

flowchart TD
A[遇到 #import] --> B{是否系统头?}
B -- 是 --> C[SYSTEM_HEADER_SEARCH_PATHS]
B -- 否 --> D[USER_HEADER_SEARCH_PATHS]
C --> E[按顺序遍历 HEADER_SEARCH_PATHS]
D --> E
E --> F{路径下有吗?}
F -- 否 --> G[下一个路径]
G --> E
F -- 是 --> H[stat + open]
H --> I[解析头文件]

每一次查找都要对所有 HEADER_SEARCH_PATHS 执行 stat(2) 系统调用，当路径数量达到数千时，光 stat 就是显著开销。

编译优化-编译缓存

Fri, 08 May 2026 13:07:14 +0800

“已经编译过的东西不再编译一遍”——这是编译优化的基础原理。Xcode 的增量编译、CocoaPods 的二进制缓存、Bazel 的 Action Cache 都是不同层次的编译缓存。本文聚焦 ccache、Clang/Swift module cache、远程缓存等通用方案的原理与 iOS 落地。

缓存分层

缓存按命中粒度可以分为三个层次：

flowchart TD
A[编译缓存] --> B[编译器内部缓存
PCH/PCM/module cache]
A --> C[Action 级缓存
ccache/sccache]
A --> D[产物级缓存
framework/xcframework]
B --> B1[进程内复用模块]
C --> C1[按 .o 粒度缓存]
D --> D1[按 Pod/module 缓存]

层次	粒度	代表	命中率
编译器内部	frontend 解析结果	Clang ModuleCache、Swift Module Cache	高（本地）
Action	源文件 → 目标文件	ccache、sccache、Bazel	中（取决于参数稳定性）
产物	整个 Pod 或 module	cocoapods-bin、Rugby	高（版本号稳定）

Clang Module Cache

原理

Clang 的 @import / @_exported import 会把外部模块预编译成 .pcm，缓存到 ModuleCachePath：

编译优化-观测

Tue, 05 May 2026 00:41:41 +0800

“无法度量就无法优化”。在开始任何编译优化动作之前，必须先建立一套可重复、可对比的观测手段，否则改动的真实收益无从谈起。本文介绍 iOS 编译耗时观测的主要工具链和原理。

观测目标分层

不同层次的观测工具回答不同的问题：

flowchart TD
A[编译耗时观测] --> B[整体耗时]
A --> C[阶段耗时]
A --> D[任务级耗时]
A --> E[函数/表达式级]
B --> B1[xcodebuild 总耗时]
C --> C1[Build Timing Summary]
C --> C2[Pod Install 阶段计时]
D --> D1[Build Timeline]
D --> D2[XCLogParser]
E --> E1[-debug-time-compilation]
E --> E2[-warn-long-expression]

观测层次	典型问题	工具
整体	一次构建花了多久？	`time xcodebuild`、MetricKit
阶段	哪个阶段最慢？	`-showBuildTimingSummary`、Build Timing Summary
任务	哪个文件/目标最慢？	Xcode Build Timeline、XCLogParser
函数级	哪个函数/表达式让前端卡住？	`-debug-time-function-bodies`、`-warn-long-expression-type-checking`

整体耗时

xcodebuild 命令行计时

最简单也最稳定的方式是直接给 xcodebuild 加 time：

编译优化-链接优化

Sat, 02 May 2026 22:32:27 +0800

链接是 iOS 编译的最后一个阶段，也是大型工程里经常被忽略的瓶颈。Apple 在 WWDC22 的 “Link fast: Improve build and launch times” 演讲中公开：Xcode 14 新的 ld-prime 链接器比 ld64 快 2 倍。随着 Xcode 17、ThinLTO、Mergeable Libraries 等改进，链接优化已经成为编译加速的重要一环。

链接器的职责

链接器把多个 .o 合并成最终可执行文件或库：

flowchart TD
A[若干 .o] --> L[链接器]
B[静态库 .a] --> L
C[动态库 .dylib / framework] --> L
L --> D[符号解析]
D --> E[dead_strip]
E --> F[ObjC runtime fix-up]
F --> G[生成 LC_* 加载命令]
G --> H[写入 Mach-O]

关键任务：

符号解析：所有 undefined symbol 必须在某个 .o / .a / .dylib 里找到
重定位：把符号引用的偏移写入正确位置
Dead Strip：去掉未被使用的代码/数据
ObjC 元数据修复：把分散的类、分类信息合并成 ObjC runtime 能识别的结构
生成 Mach-O：写 Load Commands、__LINKEDIT 等段

链接器对比

ld64（经典）

ld64 是 Apple 长期使用的经典链接器，源代码在 apple-oss-distributions/ld64。单线程为主，在大工程上明显偏慢。

编译优化

Wed, 27 May 2026 22:24:03 +0800

大型 iOS 工程的编译耗时往往是研发效能最突出的瓶颈之一。以抖音、今日头条、美团为代表的一线团队，工程代码量通常在数百万到千万行级，本地全量编译耗时 10 分钟以上、CI 上半小时起步已是常态。编译等待不仅直接压缩研发时间，还会打断心流、降低人均产出。

本系列文章从 iOS 编译系统的原理出发，结合社区最新实践（Xcode 16/17 Explicit Modules、rules_xcodeproj、seer-optimize、cocoapods-hmap-prebuilt、Rugby 等），系统性介绍编译优化的各类手段与背后的原理。

编译流程概述

理解iOS编译原理是编译优化的前提。一次典型的 iOS 编译流程可以划分为以下阶段：

flowchart TD
A[Parse Podfile / 生成工程] --> B[Pod Install / 依赖解析]
B --> C[Xcode Build System 调度]
C --> D[Dependency Scan / 模块依赖扫描]
D --> E[Swift/Clang 前端编译]
E --> F[生成 .o / .swiftmodule / .pcm]
F --> G[链接 ld64 / ld-prime / lld]
G --> H[签名 / 打包 / 资源处理]
H --> I[产出 .app / .ipa]

阶段	主要工作	常见瓶颈
依赖管理	Pod Install、SPM 解析	Source 更新慢、Specification 解析重复、沙盒拷贝
工程生成	生成 Pods.xcodeproj、xcconfig、hmap	Target 数量多、pbxproj 膨胀
构建调度	Build System 解析任务图、并行调度	依赖粒度过粗、并行度不足
模块扫描	Clang/Swift 依赖扫描	隐式模块重复编译
源码编译	Swift/Clang 前端、类型检查、SIL/IR 生成	类型推导爆炸、WMO 关闭、PCH 失效
链接	符号解析、LTO、dead-strip	链接参数过长、ThinLTO 串行
收尾	签名、资源拷贝、dSYM	串行脚本阻塞

优化思路全景

编译优化的核心思路只有三条：减少需要做的工作、让必须做的工作更快、让做过的工作可复用。所有社区实践都可以归入这三类。