自如 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源为静态源,不影响开发流程
来源:自如大前端团队
https://juejin.cn/post/7050377958241861663
-End-
最近有一些小伙伴,让我帮忙找一些 面试题 资料,于是我翻遍了收藏的 5T 资料后,汇总整理出来,可以说是程序员面试必备!所有资料都整理到网盘了,欢迎下载!
面试题
】即可获取