iOS二進制方案真實落地經驗(30分鐘降低到10分鐘以內)
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源為靜態源，不影響開發流程
