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 源为动态源，不影响开发流程