Android熱修復原理

一. AndFix

AndFix的原理就是方法的替換，把有bug的方法替換成補丁文件中的方法。

注：在Native層使用指針替換的方式替換bug方法，已達到修復bug的目的。

AndFix採用native hook的方式，這套方案直接使用dalvik_replaceMethod替換class中方法的實現。因爲它並無總體替換class, 而field在class中的相對地址在class加載時已肯定，因此AndFix沒法支持新增或者刪除filed的狀況(經過替換init與clinit只能夠修改field的數值)。Andfix能夠支持的補丁場景相對有限，僅僅可使用它來修復特定問題。 二. QZone（插樁方式）

該方案基於的是android dex分包方案的, 簡單的歸納一下，就是把多個dex文件塞入到app的classloader之中，可是android dex拆包方案中的類是沒有重複的，若是classes.dex和classes1.dex中有重複的類，當用到這個重複的類的時候，系統會選擇哪一個類進行加載呢？  讓咱們來看看類加載的代碼：

一個ClassLoader能夠包含多個dex文件，每一個dex文件是一個Element，多個dex文件排列成一個有序的數組dexElements，當找類的時候，會按順序遍歷dex文件，而後從當前遍歷的dex文件中找類，若是找類則返回，若是找不到從下一個dex文件繼續查找。

理論上，若是在不一樣的dex中有相同的類存在，那麼會優先選擇排在前面的dex文件的類，以下圖：

在此基礎上，咱們構想了熱補丁的方案，把有問題的類打包到一個dex（patch.dex）中去，而後把這個dex插入到Elements的最前面，以下圖：

三. 微信Tinker（差量包）

Instant Run的冷插拔與buck的exopackage或許能給咱們靈感，它們的思想都是全量替換新的Dex。

咱們能夠將新舊兩個Dex的差別放到補丁包中，最簡單咱們能夠採用BsDiff算法。

簡單來講，在編譯時經過新舊兩個Dex生成差別path.dex。在運行時，將差別patch.dex從新跟原始安裝包的舊Dex還原爲新的Dex。這個過程可能比較耗費時間與內存，因此咱們是單獨放在一個後臺進程:patch中。爲了補丁包儘可能的小，微信自研了DexDiff算法，它深度利用Dex的格式來減小差別的大小。 4、阿里Sophix

原理(雙劍合璧)：

1.優化Andfix（突破底層結構差別，解決穩定性問題）：

---

Andfix底層ArtMethod結構時採用內部變量一一替換，卻是這個各個廠商是會修改的，因此兼容性很差。

Sophix改變了一下思路，採用總體替換方法結構，忽略底層實現，從而解決兼容穩定性問題。

2.突破QQ和Tinker的缺陷

---

QQ和Tinker的缺陷

Sophix對dex的解決方案

• Dalvik下采用阿里自研的全量dex方案：不是考慮把補丁包的dex插到全部dex前面（dex插樁），而是想辦法在原理的dex中刪除（只是刪除了類的定義）補丁dex中存在的類，這樣讓系統查找類的時候在原來的dex中找不到，那麼只有補丁中的dex加載到系統中，系統天然就會從補丁包中找到對應的類。
• Art下本質上虛擬機以及支持多dex的加載，Sophix的作法僅僅是把補丁dex做爲主dex（classes.dex）而已，至關於從新組織了全部的dex文件：把補丁包的dex更名爲classes.dex，之前apk的全部dex依次改成classes2.dex、classes3.dex ... classesx.dex，以下圖所示。

3.資源修復另闢蹊徑

---

經常使用方案（Instant Run技術）：這種方案的兼容問題在於替換AssetManager的地方

Sophix資源修復方案

4.SO修復另闢蹊徑

---