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

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

我们做iOS二进制化断断续续尝试了一年多了,来来回回换了三个架构师去尝试落地,今日完全落地,在此做个总结
背景 【iOS二进制方案真实落地经验(30分钟降低到10分钟以内)】工程基于cocoapod的组件化开发,组件按照规范是可以独立运行的,但是我们的组件在上传cocoapod私有库的时候去掉了lint检查(为了更快的发布组件),因此,很多组件是做不到独立运行的,在此基础上我们要做二进制化来加速打包速度。
使用方是多个app多个业务线,我用最大的工程试了下最终收益:30分钟打包时间降到10分钟左右,在纯净环境的打包机下是25分钟降低到5分钟
失败的探索经验 之前有两个人做过前期尝试,思路都是双源策略,源码源+二进制源。最大的区别是如何把组件二进制化,之前的策略是使用cocoapod自带的binary扩展插件来实现,最终没落地是因为组件打出.a的成功率太低,基本没啥效果,而且cocoapod错误难以定位
我的尝试 站在前人的肩膀上做了升级
1,使用xcodebuild原生指令编译二进制文件
2,编译失败则使用源码podspec上传到二进制私有源中,保证二进制私有源可用
流程图如下:
iOS二进制方案真实落地经验(30分钟降低到10分钟以内)
文章图片

以上流程关键点:
  • 增加了白名单机制,有些组件本身不需要执行二进制化;
  • 如果组件的这个版本号已经执行了二进制编译,则无需再次编译,直接跳过;(这里的判断方式是使用cocoapod源地址来搜索判断的,一开始使用的是sqlite来存储,但是无法跨多个打包机实现共享,而且需要自己维护,cocoapod自带的源地址就可以完美解决这个问题)
主要思路是:所有组件在更新发布出新版本号的时候,对应的版本号都有对应的二进制化版本;工程特性分支合并后也会产生新版本号,因此凌晨任务的时候执行组件编译
尝试过程中遇到的问题 组件编译的时候,组件的依赖组件版本号没指定,拉取的一定是最新版本号的,如果依赖的组件正在修改且编译失败,会导致当前组件编译失败;因此,第一版尝试是组件依赖的组件版本号去主工程的podfile.lock里取,以此达到主工程能编译成功则组件就可以编译成功。但是最终没落地,是因为有些组件依赖的其他组件,但是没在podspec里写依赖,而是直接import对应达到类来使用!(我们组件pod repo push 的时候去掉了lint检查,去掉原因是lint耗时)
最终落地方案 如图:
iOS二进制方案真实落地经验(30分钟降低到10分钟以内)
文章图片

  • 流程关键点
    1,组件不再独立编译(独立编译成功率低)
    2,组件在开发过程中执行了更新发布(产生了新版本号),除了pod repo push到源码源之外,向二进制源也push一份(重点)
    2,主工程master分支在凌晨自动执行一次编译,编译出的组件.a直接拿来使用
    3,其他流程和老流程一样
成功落地分析
  • 首先二进制源要保证每个组件的版本号都能覆盖,就是流程关键点2起到主要作用
  • 壳工程依赖的一百多个组件,特性分支开发的时候最多也就十几二十个,其他组件都是二进制版本,保证了运行速度
  • 一期目标是在打包机落地,打包脚本中动态切换source源为静态源,不影响开发流程

    推荐阅读