iOS模組化灰度 A/BTest
iOS模組化灰度改造
服務能力
To 技術:
新功能模組級別的 灰度釋出.
線上版本回退老版本的能力.
一個App內 打入不同版本模組的能力.
模組組裝到不同App的能力. 比如司機端模組 可以單獨組裝為司機端App 也可與騎手端組裝在一起 打包成司機 + 騎手端App.
支援多個版本並行開發.
To 業務方:
- 不同地區 執行不同版本的業務程式碼.
某些地區先試點,時機成熟後 線上動態擴大/縮小試點範圍.
不同地區 不同市場策略 業務邏輯的實現.
新舊版本A/B Test.
預埋節假日模組,指定節假日不用發版 即可執行節假日模式.
方案概述
第一階段:
將業務程式碼拆分到Pods中,不同版本的業務程式碼打包成不同的Pods.
由於Swift中不同Pods中的程式碼屬於不同的Module,所以將不同的Pods組裝到同一個App內不需要考慮重名的問題.
這樣改造後的App = 穩定版業務程式碼Pods + 新開發版本業務程式碼Pods + 共用的三方庫程式碼.
接入服務端配置中心後,可以在服務端控制Native使用者使用的業務版本.
第二階段:
將第一階段業務程式碼拆分為不同的元件,僅對需要灰度的模組進行多版本的預埋.
客戶端的主動降級保護,啟動App後如果在一定時間內Crash,下次啟動自動降級為穩定版本.
手動配置指令碼化.
方案總攬
方案總攬方案缺點
包內預埋多個版本的模組 包大小增加.
部分步驟目前需要手工配置xcode.
實施過程
Step 1 將程式碼封裝到Pods中管理,製作Podspec.
PodspecStep 2 .a形式的靜態庫處理.
由於Pods中無法引入.a形式的靜態庫,需要把.a形式的靜態庫(比如微信支付)封裝為.framework形式的動態庫或者靜態庫.
這裡我們封裝為.framework形式的動態庫.
編譯時如果遇到找不到標頭檔案,請檢查WXPay.framework中的module.modulemap 是否包含下圖中的標頭檔案.
WXPay modulemap或者 在 module.modulemap中指定的umbrella header檔案WXPay.h中 引入需要暴漏的標頭檔案 如下圖. 也比較推薦這種方式.
WXPay modulemapStep 3 部分vendor framework完善.
比如AMap3DMap.framework AMapFoundation.framework中沒有包含module.modulemap的三方framework,
編譯時找不到標頭檔案,需要手工/指令碼新增 module.modulemap.
我們這裡可採用在 podfile中新增指令碼的方式 具體見下圖:
podfileStep 4 去除之前App工程Header Bridge標頭檔案.
由於之前Swfit工程通過Header Bridge標頭檔案去找引入OC程式碼的標頭檔案.改造後引入的庫封裝到Pods中 以framework的形式引入工程,
在新增module.modulemap後無需通過header bridge標頭檔案的方式引入標頭檔案.
所以可以在主工程刪除Header Bridge標頭檔案.
Step 5 header search path 新增vender framework path
在 Build Settings > framework search path 中新增 vender framework的路徑
Step 6 App內內建兩個版本業務程式碼Pods後 xcode需要的設定
當預置兩個版本業務程式碼Pods後,會出現Pods安裝不成功.
分析一下 專案結構時 主工程 包含 Pods A & Pods B.
Pods A & Pods B包含了同樣的Vendor Framework.
此時我們可以把Pods B中Vendor Framework中的庫刪掉.
然後在Pods B的Target > Build Settings > Framework Search Paths中指向Pods A的Vendor Framework.
達到 主工程 包含 Pods A & Pods B. Pods A & Pods B沒有引入兩份相同的Vendor Framework,而是共用一份Vendor Framework.