iOS二进制方案真实落地经验(30分钟降低到10分钟以内)

我们做iOS二进制化断断续续尝试了一年多了，来来回回换了三个架构师去尝试落地，今日完全落地，在此做个总结

背景

工程基于cocoapod的组件化开发，组件按照规范是可以独立运行的，但是我们的组件在上传cocoapod私有库的时候去掉了lint检查（为了更快的发布组件），因此，很多组件是做不到独立运行的，在此基础上我们要做二进制化来加速打包速度。

使用方是多个app多个业务线，我用最大的工程试了下最终收益：30分钟打包时间降到10分钟左右，在纯净环境的打包机下是25分钟降低到5分钟

失败的探索经验

之前有两个人做过前期尝试，思路都是双源策略，源码源+二进制源。最大的区别是如何把组件二进制化，之前的策略是使用cocoapod自带的binary扩展插件来实现，最终没落地是因为组件打出.a的成功率太低，基本没啥效果，而且cocoapod错误难以定位

我的尝试

站在前人的肩膀上做了升级

1，使用xcodebuild原生指令编译二进制文件

2，编译失败则使用源码podspec上传到二进制私有源中，保证二进制私有源可用

流程图如下：

以上流程关键点：

增加了白名单机制，有些组件本身不需要执行二进制化；
如果组件的这个版本号已经执行了二进制编译，则无需再次编译，直接跳过；（这里的判断方式是使用cocoapod源地址来搜索判断的，一开始使用的是sqlite来存储，但是无法跨多个打包机实现共享，而且需要自己维护，cocoapod自带的源地址就可以完美解决这个问题）

主要思路是：所有组件在更新发布出新版本号的时候，对应的版本号都有对应的二进制化版本；工程特性分支合并后也会产生新版本号，因此凌晨任务的时候执行组件编译

尝试过程中遇到的问题

组件编译的时候，组件的依赖组件版本号没指定，拉取的一定是最新版本号的，如果依赖的组件正在修改且编译失败，会导致当前组件编译失败；因此，第一版尝试是组件依赖的组件版本号去主工程的podfile.lock里取，以此达到主工程能编译成功则组件就可以编译成功。但是最终没落地，是因为有些组件依赖的其他组件，但是没在podspec里写依赖，而是直接import对应达到类来使用！(我们组件pod repo push 的时候去掉了lint检查，去掉原因是lint耗时)

最终落地方案

如图：

流程关键点

1，组件不再独立编译(独立编译成功率低)

2，组件在开发过程中执行了更新发布(产生了新版本号)，除了pod repo push到源码源之外，向二进制源也push一份(重点)

2，主工程master分支在凌晨自动执行一次编译，编译出的组件.a直接拿来使用

3，其他流程和老流程一样

成功落地分析

首先二进制源要保证每个组件的版本号都能覆盖，就是流程关键点2起到主要作用
壳工程依赖的一百多个组件，特性分支开发的时候最多也就十几二十个，其他组件都是二进制版本，保证了运行速度
一期目标是在打包机落地，打包脚本中动态切换source源为静态源，不影响开发流程