标签：落地 版本号 二进制 cocoapod 30 iOS 分钟 编译 组件

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

标签：落地,版本号,二进制,cocoapod,30,iOS,分钟,编译,组件
来源： https://www.cnblogs.com/huntaiji/p/15780533.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。