自如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源為靜態源，不影響開發流程