编译工程

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

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