编译

当 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： ...

在 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 仓库。抖音改造为： ...

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 的类型推导、泛型约束求解、WMO / CMO 是编译性能的核心影响因素。理解它们能让源码层面的小改动带来显著的编译加速。本文聚焦"代码写法 + 编译开关"两方面的优化。 Swift 编译流程速览 相比 C/OC，Swift 编译多出大量工作： flowchart LR A[Parse] --> B[Sema类型检查] B --> C[SILGen生成 SIL] C --> D[SIL Optimization] D --> E[IRGenLLVM 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 的构建系统由多个组件协同完成，从 Cmd+B 到生成 .app 经历了完整的任务图构建、依赖分析、并行调度流程。理解这套体系是后续一切优化的基础。 构建系统组成 Xcode 10 之后默认采用 Swift Build System（基于 llbuild），整体架构如下： flowchart TD A[Xcode IDE] --> B[XCBBuildServiceDaemon] 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 都基于此类模式。 ...

二进制化是大型 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 设置决定内部是静态还是动态库： ...

本文结合 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 关键设计点： ...

对以 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 就是显著开销。 ...

“已经编译过的东西不再编译一遍”——这是编译优化的基础原理。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： ...

“无法度量就无法优化”。在开始任何编译优化动作之前，必须先建立一套可重复、可对比的观测手段，否则改动的真实收益无从谈起。本文介绍 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： ...