Monorepo 解决方案 — 基于 Bazel 的 Xcode 性能优化实践

字节跳动技术团队

于 2024-03-13 11:00:56 发布

阅读量9.6k

点赞数 3

文章标签： xcode macos ide

本文链接：https://blog.csdn.net/ByteDanceTech/article/details/136698882

版权

背景介绍

书接上回《Monorepo 解决方案 — Bazel 在头条 iOS 的实践》，在头条工程切换至 Bazel 构建系统后，为了支持用户使用 Xcode 开发的习惯，我们使用了开源项目 Tulsi 作为生成工具，用于将 Bazel 工程转换为 Xcode 工程。但是在使用的过程中，我们发现了一些问题，其中影响较大的是，

Xcode 工程卡顿：对于头条这种大型项目来说，Xcode 卡顿一直是本地研发的痛点问题，在切换 Bazel 构建系统之后卡顿现象明显加剧。
Xcode 功能支持受限：Tulsi 支持的功能有限，很多功能都年久失修，并未持续适配 Bazel 与 rules 的更新。

在做了一些前期调研后，我们发现 rules_xcodeproj 提供了更好的解决方案。rules_xcodeproj 是一个由一系列 Bazel rules 组成的开源项目，使用它可以从一个 Bazel 工程生成对应的 Xcode 工程，实现在 Xcode 中写代码同时使用 Bazel 进行真正的构建任务，相比于 Tulsi，rules_xcodeproj 在以下几个方面有着更为明显的优势。

Xcode 工程更加流畅： 头条工程迁移到 rules_xcodeproj 后，工程首次冷启、二次启动和文件增删操作的时间有了明显缩短，工程卡顿情况也明显好转。
Xcode 功能支持度更高： rules_xcodeproj 对 Xcode 的支持更全面（包括单元测试、SwiftUI Previews），能够更好地满足我们的需求。
社区更加活跃：随着 rules_xcodeproj 在 2023 年 2 月份发布正式版，Tulsi 项目也正式宣布停止维护，这意味着对于新版本的 Bazel，Tulsi 将不再提供适配和支持；同时 rules_xcodeproj 几乎每月都会更新一个中版本，对于后续适配 Bazel 更新的成本会更低。
更符合 BitSky 的演进路线：由 Bazel 驱动的工程生成方式更符合 BitSky 的 Bazel Native 演进路线，可以完全在 Bazel 环境下生成工程。

因此，我们将 Xcode 生成工具从 Tulsi 迁移到了 rules_xcodeproj，并对 BitSky 工具链进行了适配。适配过程中，我们在修复 rules_xcodeproj 索引问题的同时，对工程结构进行了一些优化，进一步提升了工程流畅度。头条 iOS 工程的测试数据如下：

测试设备 MacBook Pro，芯片 M1 Pro，内存 32GB

ps. 本文介绍均基于 rules_xcodeproj 1.4.0 版本，build with bazel 模式

pps. 由于 Xcode 主线程的卡顿较难监测，此处用主动操作的执行时间衡量流畅度

	Tulsi	rules_xcodeproj
工程首次冷启	47s	16s
二次启动	33s	12s
文件操作	新增 20s 删除 23s	新增 8s 删除 6s

下面来看下我们具体做的适配工作。

适配过程

从 Tulsi 迁移到 rules_xcodeproj 后，我们发现 Xcode 卡顿有明显改善，仔细分析发现 Tulsi 工程的卡顿主要有两方面原因：

头条工程中组件数量多、依赖关系复杂：Tulsi 的索引方案需要 Xcode Target 之间保留这些依赖关系，但这些依赖关系并不会被 Xcode 构建消费，却增加了 Xcode 对工程进行解析和计算的成本。

图中 Pod X_A 与 Pod X_B 为 Pod X 分别在 App A 与 App B 下被引用的 Target

全源码构建：我们在切换 Bazel 时还推进了工程的全源码构建，源码数量大幅增加，也给索引任务带来更大的压力。

接下来详细说明整个分析和适配过程，带大家更全面地了解我们结合 rules_xcodeproj 在 Xcode 背后做了什么。

在 Xcode 中开发时主要会用到三部分功能：构建、索引和调试。而 Xcode 并不能直接理解 Bazel 项目的工程文件（BUILD 和 WORKSPACE），所以我们需要通过工具（rules_xcodeproj 或 Tulsi）将 Bazel 的工程文件转换为 Xcode 可以理解的 .xcodeproj来支持这些功能正常工作。

各功能的适配点如下表所示。