前言

剛開始要做 SDK 熱修復，我是拒絕的 ~

某日，解決完一個線上 bug 后，我冒出了一個念頭：讓我們的 SDK 也具有熱修復的能力唄！

但是查了查，網上資料少、很多熱修復方案只針對app……

可是我都拍胸脯向老大夸口了，焉有退縮的道理？！

加上萬一以后手抖，出了個什么大 bug 或者兼容問題，我的職業生涯不就要終結了！？

我滴乖乖，保命要緊！還是趕緊做個保底方案吧。

一、背景和目的

我們想實現的效果很簡單，如下場景三：

二、技術方案

先說明下，方案沒有最好，只有最合適。雖然我最終選定了方案四，但如果各位小伙伴的團隊有資源、有其他方案的經驗、SDK的熱更需求更豐富，可以自行選擇其他方案。

方案一：JAR 替換

步驟

從服務端下載 jar -> 通過反射，加載jar -> 創建相關對象并且操作之。

方案參考： Android SDK熱修復機制簡析以實現

優缺點

優點： 1. 無兼容問題

缺點： 1. 反射消耗性能； 2. jar 包如果體積大，整個下載就很不友好； 3. 確定改動的代碼范圍繁瑣，維護麻煩。

方案一改進：子 JAR 替換

步驟

針對 jar 包體積大的情況，我們可以考慮對 sdk 項目進行拆包（拆module），分成小的 jar 包和主包

主包負責反射加載，如果需要熱修，下發子 jar 即可，比較輕量。

優缺點

優點： 1. 只下發子包，輕量

缺點： 1. 比較適合主包變動小的情況； 2. 主包和子包耦合性強； 3. 還是需要用到反射。

方案二：插件化

步驟

將SDK分包，宿主包僅提供 API 和加載核心實現的插件包，插件包就可以熱更了。

優缺點

優點： 1. 靈活

缺點： 1. 對主項目工程的依賴太大，往往一些基本配置需要依賴于主工程的項目源碼； 2. 使用接入成本高，配置麻煩，而 SDK 的業務接入方需要的是快速接入； 3. 插件化框架可能會對系統原生代碼的運行造成不可預估的影響； 4. 不得不依賴很多不需要的插件化框架功能。

方案三：業務方熱更

走投無路之下，我想起，誒！很多 app 熱更方案不是說支持 lib 熱更嗎！那先作為一個保底方案吧。

步驟

通過業務方 app 熱更 lib 包。

優缺點

優點： 1. 熱更權把控在業務方手中，對業務方透明

缺點： 1. lib 包太大時，下載還是很耗流量的 2. diff 算法無法計算新舊 lib 的差異，只能整個替換掉 3. 步驟相當繁瑣，如下圖：

方案四：改造現有 APP 熱修復方案

1. 那在選擇熱修復方案時考慮點有哪些？

熱更項目的需求

只需要簡單的方法級別 Bug 修復？

需要資源及 so 庫的修復？

需要 Native 的修復？

對平臺兼容性要求及成功率要求？

是否需要對補丁包進行管理？

公司資源是否支持商業付費？

學習及使用成本

集成難度和復雜度

代碼侵入性

調試維護

選擇框架的關注點

盡量大廠

性能過關

有專人維護

熱度高，開源社區活躍

2. 總結出需要熱更的 SDK 特點

主要是代碼熱更，無so庫、資源更新需求；

實時性要求高，因為一旦出問題，對業務方的影響極大；

兼容性要求高，你無法預料到業務方的活躍用戶都有啥機型。

3. 那我們趕緊來看下，現有的 APP 熱修復方案都有哪些？

3.1 綜合優化的產物 —— Sophix（棄）

Sophix 功能完善、開發簡單透明，可惜沒開源，無法改造。

3.2 底層替換方案（棄）

底層替換方案不可避免地存在兼容問題，棄之。

3.3 類加載方案 —— Tinker

優點： 1. 用戶多 2. 更新時間新，相比之下，其他有在Github上開源的框架，star數都是7000以下，上次更新時間都在1年前，甚至2年前。

缺點： 1. dex合成占用ROM較大 2. 不夠實時 3. 需要改造Application，業務方有感知。（也可以參考 InstantRun 做到不修改 Application 達到替換 Application 的效果，但該方案大量 hook 系統 api，不夠穩定，大概有 1/1w 的概率會出現替換失敗，所以Tinker最終還是沒有使用InstantRun的方式）

還有兩個問題，留給大家去思考： 1. 會不會影響業務方加固？ 2. 和業務方是否沖突？

方案參考： 基于Tinker的SDK全局熱更新方案（全網唯一）
擴展： InstantRun 如何動態替換 Application，總結起來就兩步：
- 打包時替換 Application 標簽，插入BootstrapApplication
- 運行時 hook 系統api，將 BootstrapApplication 換回 MyApplication

3.4 插樁 —— 美團 Robust

Robust 的原理可以簡單描述為： 1. 打基礎包時插樁，在每個方法前插入一段 if(changeQuickRedirect==null)-else 的邏輯； 2. 加載補丁時，從補丁包中讀取要替換的類及具體替換的方法實現，新建 ClassLoader 加載補丁 dex，當目標方法被執行時，此時 changeQuickRedirect != null，方法邏輯流程被改變，而替換掉之前的舊邏輯，達到 fix 的目的。

優點： 1. 兼容性最優，兼容加固 2. 實時生效 3. 粒度細，支持方法級別的修復 3. 高穩定性，修復成功率高達99.9%

缺點： 1. 在編譯階段插件侵入了產品代碼，對運行效率、方法數、包體積還是產生了一些副作用。（支持指定某些class無需插入） 2. so和資源的替換目前暫未實現 3. 無法新增變量 4. 沒有補丁管理和安全校驗，需要開發者自行實現

思考： 1. 和其他的插樁插件混用是否有沖突？

三、實現

就在我美滋滋地接入 Robust 時，問題來了！

Robust 需要是 Application 才能插樁和打補丁，要用在 SDK 上，還是需要一輪改造的。

如何改造？我將在下篇博文中詳解，同時將推出封裝好的庫，讓 SDK 開發者只需 5 分鐘即可讓自己的 SDK 擁有熱修復的能力，敬請期待。

四、除了熱更技術本身，我們還應該關心的

當然，我們的焦點并不局限在技術實現上，還有很多值得我們去考慮的：

我們怎么對分發進行控制？對監控數據進行統計？如果補丁引起了崩潰，我們怎么第一時間補救？

1. 精準分發

結合外部維度系統，根據用戶維度，比如渠道、系統版本等等做有差別的下發。

2. 數據分析

上線后我們最關心的就是補丁的兼容性和成功率。

補丁拉取成功率 = 請求補丁成功的用戶 / 發起請求補丁的用戶

補丁下載成功率 = 下載補丁成功的用戶 / 嘗試下載補丁的用戶

patch應用成功率 = patch成功的用戶 - 回滾的用戶 / 補丁下載成功的用戶

3. 補丁回滾機制

我們需要支持自動監控崩潰，如果是下發的補丁引起的，則下次啟動補丁自動失效，避免擴大影響范圍。

以上這些思考，我將會在下篇博文中一一實現，敬請關注！

本篇完成耗時 6 個番茄鐘（180 分鐘）

---

我是 FeelsChaotic，一個寫得了代碼 p 得了圖，剪得了視頻畫得了畫的程序媛，致力于追求代碼優雅、架構設計和 T 型成長。

歡迎關注 FeelsChaotic 的簡書和掘金，如果我的文章對你哪怕有一點點幫助，歡迎 ??！你的鼓勵是我寫作的最大動力！

最最重要的，請給出你的建議或意見，有錯誤請多多指正！

總結

以上是生活随笔為你收集整理的插件修复数据_APP 热修复都懂了，你会 SDK 热修复吗？最全方案在这里！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。