Android 熱修復原理（主要談代碼修復）

Android開發中，熱修復技術被愈來愈多的開發者使用，市面上也出現不少成熟的開源框架。但對大部分開發者來講，熱修復依然是一個既熟悉又陌生的詞。僅僅知道熱修復的做用，會使用框架，那樣意義並不大。咱們還要知道熱修復的原理，這樣無論框架如何變化，只要基本原理不變，咱們均可以快速掌握它，或者本身動手寫一個適合項目的熱修復框架。

熱修復介紹

1.開發流程

開發流程對比

當項目出現緊急bug時，傳統的開發流程是發佈新版本，引導用戶覆蓋安裝。拋開平臺審覈上線的時間不說，一天重複下載安裝至少兩次的用戶體驗是不好的。而熱修復的出現完美解決了這個問題，用戶在收到服務器推送過來的修復包後，在項目運行時進行修復。整個過程是在用戶無感知狀態下完成，也無需下載相對來講較大的安裝包，代價小。

總結爲兩個優勢：

• 無需從新發版，修復效率高
• 用戶無感知，代價小

2.都能修復什麼

• 資源修復
• 代碼修復
• so庫修復

3.代碼修復技術分類

目前最主要有三種方案：

• 基於類加載與 Dex 分包方案，進行 Dex 插樁/替換
• Native Hook 進行底層替換
• Install Run 進行類的注入

因爲國內手機廠商定製系統的多樣，Dex 插樁/替換是我認爲最適合的方案。

Dex插樁原理

ClassLoader 是經過調用 findClass 方法，在 pathList 對象中的 dexElements[] 中遍歷dex文件尋找相關的類。因爲靠前的dex會優先被系統調用，因此就有了插樁的概念。將修復好的 dex 插入到 dexElements[] 的最前方，這樣系統就會調用修復好的插入類而不是靠後的 bug 類。

Dex插樁原理圖

上圖中，patch.dex 是插入的 dex ，classes2.dex 是原有的 bug dex。ClassLoader 在遍歷時優先獲取了 patch.dex 中的 D.class ,因此 classes2.dex 中的 D.class 就不會被調用，這樣就完成了對 D.class 的替換，修復了bug。

本文簡單介紹了代碼修復的技術原理，下篇文章將從系統源碼入手，結合我本身封裝的代碼修復開源框架Fettler，詳細解讀代碼修復的每個過程。本文若是有出現錯誤的地方也請幫忙在評論區指出，共同窗習進步，謝謝你們。