iOS二进制解实战经验（30分钟缩减到10分钟以内）我们断断续续做iOS二进制解一年多了，来回切换我聘请了三个架构师来尝试实现它，今天它已经完全实现了。这里总结一下基于cocoapod组件化开发的后台项目。组件可以按照规范独立运行，但是我们的组件在上传cocoapod私有库时去除了lint。检查（为了更快的发布组件），因此，很多组件不能独立运行，在此基础上我们需要做二进制来加快打包。用户是多个应用程序和多个业务线。我用最大的项目尝试了最后的好处：30分钟的打包时间减少到10分钟左右，失败的探索经验从25分钟减少到纯环境下打包机下的5分钟。之前两个人都有过早期的尝试，思路是双源策略，源码源+二进制源。最大的区别在于如何将组件二值化。之前的策略是使用cocoapod自带的二进制扩展插件。最后失败了，因为组件的.我的尝试站在前人的肩膀上做了升级1.使用xcodebuildnative指令编译二进制文件2.如果编译失败，使用源码podspec上传到二进制私有源，保证二进制私有源可用.流程图如下：上述过程的重点：增加了白名单机制，部分组件不需要进行二进制编译；如果组件的版本号已经进行过二进制编译，则不需要重新编译，直接跳过；（这里的判断方法是使用cocoapod源地址搜索判断是的，一开始是用sqlite存储的，但是不能跨多个packer共享，需要自己维护的源地址）cocoapod自带的可以完美解决这个问题）主要思路是：所有组件更新发布时使用版本号，对应的版本号有对应的二进制版本；工程特性分支合并后，也会生成一个新的版本号，所以在早上任务中执行组件编译尝试时遇到的问题时，编译组件时，组件依赖组件的版本号为未指定，必须拉取最新版本号。如果依赖组件正在修改，编译失败，则当前组件编译失败；因此，第一个版本尝试将组件所依赖的组件的版本号从项目的podfile.lock中取出，这样如果主项目能编译成功，组件也能编译成功。但是最终并没有落地，因为有些组件依赖其他组件，但是他们并没有在podspec中写依赖，而是直接导入对应的类来使用！（我们组件podrepopush的时候去掉了lint检查，去掉的原因是lint比较耗时。）最终的实现方案如图：流程要点1.组件不再独立编译（独立编译成功率低）2.组件在开发过程中执行updaterelease后（生成新的版本号），除了podrepopush到sourcecodesource之外，还push了一份tothebinarysource(关键点)2.主工程的master分支凌晨自动执行一次编译，编译好的组件。A。直接使用3.其他流程和老流程一样成功执行。分析首先，二进制源码必须保证能够覆盖各个组件的版本号，这是流程的重点。feature分支开发的时候，最多只有十几二十个，其他组件都是二进制版本，保证了运行速度。第一阶段的目标是登陆打包机，在打包脚本中动态切换源码为静态源码，不影响开发进程。
