前言
剛開始要做 SDK 熱修復，我是拒絕的 ~
某日，解決完一個線上 bug 後，我冒出了一個念頭：讓我們的 SDK 也具有熱修復的能力唄！
但是查了查，網上資料少、很多熱修復方案只針對app……
可是我都拍胸脯向老大誇口了，焉有退縮的道理？！
加上萬一以後手抖，出了個什麼大 bug 或者兼容問題，我的職業生涯不就要終結了！？
我滴乖乖，保命要緊！還是趕緊做個保底方案吧。
一、背景和目的
我們想實現的效果很簡單，如下場景三：
二、技術方案
先說明下，方案沒有最好，只有最合適。雖然我最終選定了方案四，但如果各位小夥伴的團隊有資源、有其他方案的經驗、SDK的熱更需求更豐富，可以自行選擇其他方案。
方案一：JAR 替換
步驟
從服務端下載 jar -> 通過反射，加載jar -> 創建相關對象並且操作之。
方案參考：
Android SDK熱修復機制簡析以實現
優缺點
優點：
- 無兼容問題
缺點：
- 反射消耗性能；
- jar 包如果體積大，整個下載就很不友好；
- 確定改動的代碼範圍繁瑣，維護麻煩。
方案一改進：子 JAR 替換
步驟
針對 jar 包體積大的情況，我們可以考慮對 sdk 項目進行拆包（拆module），分成小的 jar 包和主包
主包負責反射加載，如果需要熱修，下發子 jar 即可，比較輕量。
優缺點
優點：
- 只下發子包，輕量
缺點：
- 比較適合主包變動小的情況；
- 主包和子包耦合性強；
- 還是需要用到反射。
方案二：插件化
步驟
將SDK分包，宿主包僅提供 API 和加載核心實現的插件包，插件包就可以熱更了。
優缺點
優點：
- 靈活
缺點：
- 對主項目工程的依賴太大，往往一些基本配置需要依賴於主工程的項目源碼；
- 使用接入成本高，配置麻煩，而 SDK 的業務接入方需要的是快速接入；
- 插件化框架可能會對系統原生代碼的運行造成不可預估的影響；
- 不得不依賴很多不需要的插件化框架功能。
方案三：業務方熱更
走投無路之下，我想起，誒！很多 app 熱更方案不是說支持 lib 熱更嗎！那先作爲一個保底方案吧。
步驟
通過業務方 app 熱更 lib 包。
優缺點
優點：
- 熱更權把控在業務方手中，對業務方透明
缺點：
- lib 包太大時，下載還是很耗流量的
- diff 算法無法計算新舊 lib 的差異，只能整個替換掉
- 步驟相當繁瑣，如下圖：
方案四：改造現有 APP 熱修復方案
1. 那在選擇熱修復方案時考慮點有哪些？
- 熱更項目的需求
- 只需要簡單的方法級別 Bug 修復？
- 需要資源及 so 庫的修復？
- 需要 Native 的修復？
- 對平臺兼容性要求及成功率要求？
- 是否需要對補丁包進行管理？
- 公司資源是否支持商業付費？
- 學習及使用成本
- 集成難度和複雜度
- 代碼侵入性
- 調試維護
- 選擇框架的關注點
- 儘量大廠
- 性能過關
- 有專人維護
- 熱度高，開源社區活躍
2. 總結出需要熱更的 SDK 特點
- 主要是代碼熱更，無so庫、資源更新需求；
- 實時性要求高，因爲一旦出問題，對業務方的影響極大；
- 兼容性要求高，你無法預料到業務方的活躍用戶都有啥機型。
3. 那我們趕緊來看下，現有的 APP 熱修復方案都有哪些？
3.1 綜合優化的產物 —— Sophix（棄）
Sophix 功能完善、開發簡單透明，可惜沒開源，無法改造。
3.2 底層替換方案（棄）
底層替換方案不可避免地存在兼容問題，棄之。
3.3 類加載方案 —— Tinker
優點：
- 用戶多
- 更新時間新，相比之下，其他有在Github上開源的框架，star數都是7000以下，上次更新時間都在1年前，甚至2年前。
缺點：
- dex合成佔用ROM較大
- 不夠實時
- 需要改造Application，業務方有感知。（也可以參考 InstantRun 做到不修改 Application 達到替換 Application 的效果，但該方案大量 hook 系統 api，不夠穩定，大概有 1/1w 的概率會出現替換失敗，所以Tinker最終還是沒有使用InstantRun的方式）
還有兩個問題，留給大家去思考：
- 會不會影響業務方加固？
- 和業務方是否衝突？
擴展：
InstantRun 如何動態替換 Application，總結起來就兩步：
- 打包時替換 Application 標籤，插入BootstrapApplication
- 運行時 hook 系統api，將 BootstrapApplication 換回 MyApplication
3.4 插樁 —— 美團 Robust
Robust 的原理可以簡單描述爲：
- 打基礎包時插樁，在每個方法前插入一段 if(changeQuickRedirect==null)-else 的邏輯；
- 加載補丁時，從補丁包中讀取要替換的類及具體替換的方法實現，新建 ClassLoader 加載補丁 dex，當目標方法被執行時，此時 changeQuickRedirect != null，方法邏輯流程被改變，而替換掉之前的舊邏輯，達到 fix 的目的。
優點：
- 兼容性最優，兼容加固
- 實時生效
- 粒度細，支持方法級別的修復
- 高穩定性，修復成功率高達99.9%
缺點：
- 在編譯階段插件侵入了產品代碼，對運行效率、方法數、包體積還是產生了一些副作用。（支持指定某些class無需插入）
- so和資源的替換目前暫未實現
- 無法新增變量
- 沒有補丁管理和安全校驗，需要開發者自行實現
思考：
- 和其他的插樁插件混用是否有衝突？
三、實現
就在我美滋滋地接入 Robust 時，問題來了！
Robust 需要是 Application 才能插樁和打補丁，要用在 SDK 上，還是需要一輪改造的。
如何改造？我將在下篇博文中詳解，同時將推出封裝好的庫，讓 SDK 開發者只需 5 分鐘即可讓自己的 SDK 擁有熱修復的能力，敬請期待。
四、除了熱更技術本身，我們還應該關心的
當然，我們的焦點並不侷限在技術實現上，還有很多值得我們去考慮的：
我們怎麼對分發進行控制？對監控數據進行統計？如果補丁引起了崩潰，我們怎麼第一時間補救？
1. 精準分發
結合外部維度系統，根據用戶維度，比如渠道、系統版本等等做有差別的下發。
2. 數據分析
上線後我們最關心的就是補丁的兼容性和成功率。
- 補丁拉取成功率 = 請求補丁成功的用戶 / 發起請求補丁的用戶
- 補丁下載成功率 = 下載補丁成功的用戶 / 嘗試下載補丁的用戶
- patch應用成功率 = patch成功的用戶 - 回滾的用戶 / 補丁下載成功的用戶
3. 補丁回滾機制
我們需要支持自動監控崩潰，如果是下發的補丁引起的，則下次啓動補丁自動失效，避免擴大影響範圍。
以上這些思考，我將會在下篇博文中一一實現，敬請關注！
本篇完成耗時 6 個番茄鍾（180 分鐘）
我是 FeelsChaotic，一個寫得了代碼 p 得了圖，剪得了視頻畫得了畫的程序媛，致力於追求代碼優雅、架構設計和 T 型成長。
歡迎關注 FeelsChaotic 的簡書和掘金，如果我的文章對你哪怕有一點點幫助，歡迎 ❤️！你的鼓勵是我寫作的最大動力！
最最重要的，請給出你的建議或意見，有錯誤請多多指正！