关于前端:iOS二进制方案真实落地经验30分钟降低到10分钟以内

2次阅读

共计 1239 个字符，预计需要花费 4 分钟才能阅读完成。

咱们做 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，其余流程和老流程一样