携程旅行App iOS工程编译优化实践-InfoQ

AICon全球人工智能与机器学习技术大会周四开幕，点击查看完整日程>> 了解详情 



 写点什么

引言

开发效率的提升，是开发者关注的一个永恒的话题。对于 iOS 而言，编译速度一直是影响 iOS 开发和集成测试效率关键的一环。

携程旅行 App iOS 工程编译，经历了从全源码编译到工程组件化，细分 Bundle，再到细分 Bundle 基础上的进一步优化四个阶段。每次的优化改造都是不断结合业务反馈，深入了解 xcode 编译过程后的成果。

一、背景

简单回顾一下在做 Bundle 拆分之前的情况，当时整个 iOS 工程的所有代码都在一起，并未做工程拆分和解耦，编译时全都是源码编译，数百万行代码全部编译完成要将近一个小时。所有的开发人员都在一个工程里开发，如果因为某个人提交的代码有问题（这是常常会发生的），导致编译了很长时间之后才报错，更是耽误时间，严重影响开发效率。对于测试人员来说，每次需要验证一个功能时打包测试都需要至少等待几十分钟，这是极大的资源浪费。

这个时候的 Build 过程是全源码 complie，几千上万个文件都需要编译、链接，效率可想而知。

所以为了提高开发和测试的效率，提高 iOS 工程的编译速度刻不容缓。

二、优化方案

2.1 工程组件化

第一个优化是把整个工程的编译过程打散，把代码按照业务线拆分成一个个独立的子工程，每个子工程的编译过程都是独立的。每个子工程只需要保证自己工程的源码能够编译成功，对外输出统一的静态库和资源文件包的产物。这个产物我们叫做 Bundle。

单个业务工程（Bundle）：

App Build：

对于单个业务来说，编译时间大大缩短，整个 Build 过程变成单工程 complie，多工程 link，极大减少了 Build 过程中的 complie 花费的时间。

这样有两个好处：

1）对于开发人员，每个业务开发只需要把自己这个子工程切为源码引用，把其他非自己模块的子工程全部用静态库依赖，本地编译也只需要编译自己的子工程，可以大大提升本地开发编译速度。

2）对于测试人员，打包过程就变成了把所有已经编译好的子 Bundle 静态库链接到一个壳工程里，不需要对每个文件进行编译，可以很快的打包测试验证。

2.2 增量编译

在工程组件化之后，在持续集成平台上单个 Bundle 的打包时间还是过长。因此框架团队开始研究单个 Bundle 在持续集成平台上增量编译的可能性。

经过调研，最终选定 CCache 做为解决方案。CCache 是一个编译工具，可以将 Xcode 编译文件缓存起来，从而达到编译提速。

针对本地开发该方案具有优势，但是在结合自研的移动发布平台 MCD（Mobile Continuous Delivery）（后面简称【发布平台】）上使用时效果并没有达到预期，主要有两点原因：

1）同一 Bundle 多分支共存：App 会存在大小版本同时开发的情况，在发布平台中也就会存在不同版本、不同分支的情况。

2）缓存管理不便：发布平台打包机器通常仅有 250G 磁盘空间，当面临磁盘压力时，需要灵活的清理策略。

最终框架团队采用了自管理，能做到缓存物理隔离，同时也就省去了环境配置的步骤。

增量编译具体实现：

1）合并有变动的文件

打包任务会根据新的 commitId 下载一份代码副本，不能直接使用该副本，因为代码文件内容没有变动，仅仅是文件属性的变动也会导致 xcodebuild 缓存不生效。因此需要副本和工作区内的源码做 diff，仅仅合并内容有变动的文件。
使用 python 的 filecmp 实现合并代码逻辑，并且支持配置 ignore。
xcodebuild 指定 -derivedDataPath 设置缓存路径，并将该目录配置到 diff ignore 中。

2）提供清除缓存的功能

xcodebuild 的缓存有时候会出问题，比如修改了 c++文件后有时并不会生效，这种需要提供清除缓存的功能，可以由开发自由选择使用。

截止到以上两步，Native 已经基本实现了增量编译，但是实际使用还不够。因为打包主要是在集成系统平台上面完成的，集成平台打包有多台机器。

携程旅行 App 的打包 Jenkins 采用的是 master-slave 模式，一个 Job 下会有多个节点，Job 是随机抽取的节点。为了提高增量编译的命中率，必须要让 Bundle 和节点关联起来。比如：有 ABCD 四个节点，HotelBundle 每次都落到 A 节点，这样才能保证 A 节点中 HotelBundle 的 xcodebuild 缓存有效，并且代码 diff 差异最小。

具体实现：

1）保留 Jenkins Job 的工作区

该步骤是在 Jenkins Job 的配置中操作，取消勾选下图中的 Delete workspace before build starts

2）使用 Jenkins 插件建立 Bundle 和节点的关联

基于 Jenkins Label Parameter Plugin，并做改造，实现伪随机，以保证关联的节点下线之后，能使用候补节点正常工作。

发布平台前端提供关联配置，业务可以按需选择使用。

通过以上步骤就实现了增量编译，但是该方案针对 swift 不生效。swift 在 Release 模式采用的全量编译（如下图）,做整体优化。不过 swift Bundle 可以采用上述 Bundle 拆分的方案。

以某一个编译源码文件 197 个、资源文件 142 个的 Bundle 为例看下效果。

采用增量编译后，Bundle 编译耗时由 116s 降为 9s。

2.3 Bundle 细分

最初携程旅行 App 的 Bundle 都是按照业务来拆分的，比如：酒店就一个 Hotel Bundle，在当时编译速度已经不慢了。但是随着业务的发展，单个 Bundle 中业务代码越来越多，文件越来越多，导致编译又会变慢。这时，可以将单个 Bundle 按照功能做更细粒度的拆分，比如酒店拆分出了酒店主工程、酒店基础工程。

更细粒度的 Bundle 拆分还能带来以下其他收益：

加快本地开发编译：某个功能的开发人员只需要将自己这个功能模块切为源码，其他模块全用静态库，提高本地开发编译效率。
为其他独立 app 提供更细粒度的模块功能支持：我厂的很多独立 App 都是共用一套框架和基础组件的，按功能模块细粒度的拆分出独立的模块 Bundle 后，可以使独立 app 在选择基础组件时按需选择。