干货 | 携程旅行App iOS工程编译优化实践

关注

原创最新推荐文章于 2026-06-13 16:12:17 发布 1.1k 阅读 AI 写同款· GEO 优化 ›

生产级机器学习：从模型上线到系统稳定的关键工程实践机器学习模型部署不是开发终点，而是系统性工程挑战的起点。当模型脱离训练环境进入真实业务流，其行为受特征延迟、服务依赖、数据漂移、资源约束和合规要求等多重因素影响。本文围绕生产环境中最常被忽视的四大核心问题——特征可用性保障、低延迟推理设计、防御性监控与漂移检测、可审计的模型治理——展开深度解析。结合金融风控与电商推荐等高后果场景的真实案例，揭示95%以上的线上故障源于工程疏漏而非算法缺陷。内容涵盖特征fallback语义对齐、eBPF级延迟诊断、KL散度动态基线告警、GitOps驱动的灰度回滚、以及将监管条阅读详情

作者简介

天超，携程资深软件工程师，关注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）（后面简称【发布平台】）上使用时效果并没有达到预期，主要有两点原因：

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拆分还能带来以下其他收益：