自如 iOS 二進(jìn)制方案落地：30 分鐘降低到 10 分鐘以內(nèi)

我們做iOS二進(jìn)制化斷斷續(xù)續(xù)嘗試了一年多了，來來回回?fù)Q了三個(gè)人去嘗試落地，今日完全落地，在此做個(gè)總結(jié)。

背景

工程是基于cocoapod的組件化開發(fā)，組件按照規(guī)范是可以獨(dú)立運(yùn)行的，但是我們的組件在上傳cocoapod私有庫的時(shí)候去掉了lint檢查（為了更快的發(fā)布組件），因此，很多組件是做不到獨(dú)立運(yùn)行的，在此基礎(chǔ)上我們要做二進(jìn)制化來加速打包速度。使用方是多個(gè)app多個(gè)業(yè)務(wù)線，我用最大的工程試了下最終收益：30分鐘打包時(shí)間降到10分鐘左右，在純凈環(huán)境的打包機(jī)下是25分鐘降低到5分鐘

失敗的探索經(jīng)驗(yàn)

之前有兩個(gè)人做過前期嘗試，思路都是雙源策略，源碼源+二進(jìn)制源。最大的區(qū)別是如何把組件二進(jìn)制化，之前的策略是使用cocoapod自帶的binary擴(kuò)展插件來實(shí)現(xiàn)，最終沒落地是因?yàn)榻M件打出.a的成功率太低，基本沒啥效果，而且cocoapod錯(cuò)誤難以定位

我的嘗試

站在前任的肩膀上做了升級(jí) 1，使用xcodebuild原生指令編譯二進(jìn)制文件 2，編譯失敗則使用源碼podspec上傳到二進(jìn)制私有源中，保證二進(jìn)制私有源可用

流程圖如下：

以上流程關(guān)鍵點(diǎn)：

• 增加了白名單機(jī)制，有些組件本身不需要執(zhí)行二進(jìn)制化；
• 如果組件的這個(gè)版本號(hào)已經(jīng)執(zhí)行了二進(jìn)制編譯，則無需再次編譯，直接跳過；（這里的判斷方式是使用cocoapod源地址來搜索判斷的，一開始使用的是sqlite來存儲(chǔ)，但是無法跨多個(gè)打包機(jī)實(shí)現(xiàn)共享，而且需要自己維護(hù)，cocoapod自帶的源地址就可以完美解決這個(gè)問題）

主要思路是：所有組件在更新發(fā)布出新版本號(hào)的時(shí)候，對(duì)應(yīng)的版本號(hào)都有對(duì)應(yīng)的二進(jìn)制化版本；工程特性分支合并后也會(huì)產(chǎn)生新版本號(hào)，因此凌晨任務(wù)的時(shí)候執(zhí)行組件編譯

嘗試過程中遇到的問題

組件編譯的時(shí)候，組件的依賴組件版本號(hào)沒指定，拉取的一定是最新版本號(hào)的，如果依賴的組件正在修改且編譯失敗，會(huì)導(dǎo)致當(dāng)前組件編譯失敗；因此，第一版嘗試是組件依賴的組件版本號(hào)去主工程的podfile.lock里取，以此達(dá)到主工程能編譯成功則組件就可以編譯成功。但是最終沒落地，是因?yàn)橛行┙M件依賴的其他組件，但是沒在podspec里寫依賴，而是直接import對(duì)應(yīng)達(dá)到類來使用！(我們組件pod repo push 的時(shí)候去掉了lint檢查，去掉原因是lint耗時(shí))

最終落地方案

如圖：

• 流程關(guān)鍵點(diǎn)

1，組件不再獨(dú)立編譯(獨(dú)立編譯成功率低) 2，組件在開發(fā)過程中執(zhí)行了更新發(fā)布(產(chǎn)生了新版本號(hào))，除了pod repo push到源碼源之外，向二進(jìn)制源也push一份(重點(diǎn)) 2，主工程master分支在凌晨自動(dòng)執(zhí)行一次編譯，編譯出的組件.a直接拿來使用 3，其他流程和老流程一樣

成功落地分析

• 首先二進(jìn)制源要保證每個(gè)組件的版本號(hào)都能覆蓋，就是流程關(guān)鍵點(diǎn)2起到主要作用
• 殼工程依賴的一百多個(gè)組件，特性分支開發(fā)的時(shí)候最多也就十幾二十個(gè)，其他組件都是二進(jìn)制版本，保證了運(yùn)行速度
• 一期目標(biāo)是在打包機(jī)落地，打包腳本中動(dòng)態(tài)切換source源為靜態(tài)源，不影響開發(fā)流程

來源：自如大前端團(tuán)隊(duì) 

https://juejin.cn/post/7050377958241861663