作者简介
天超,携程资深软件工程师,关注iOS研发,喜欢用脚本语言解决各种难题。
引言
开发效率的提升,是开发者关注的一个永恒的话题。对于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)(后面简称【发布平台】&#x