1. 程式人生 > >Android熱修復原理

Android熱修復原理

基礎 ssl 不同的 都是 優先 -o 除了 自然 思路

一. 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的格式來減少差異的大小。

四、阿裏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修復另辟蹊徑


技術分享圖片

Android熱修復原理