熱修復框架技術主要有三類，代碼修復，資源修復，動態鏈接庫修復。

資源修復

很多資源修復的框架參考了Instant Run資源修復的原理，所以先了解一下Instant Run

Instant Run

Instant Run是Android Studio 2.0以后新增的一個運行機制，能減少開發人員第二次及以后的構建和部署時間。

Hot Swap: 這是效率最高的部署方式，修改一個現有方法中的代碼會采用這種方法。它不需要重啟APP， 不需要重啟Activity

Warm Swap: App不需要重啟，但是Activity需要重啟。 修改或刪除一個現有的資源文件時采用

Cold Swap: App需要重啟，但不需要重新安裝。 添加，刪除或修改一個字段和方法，添加一個類時采用該方式。

Instant Run 資源修復的原理創建新的AssetManager,通過反射調用addAssetPath方法加載外部的資源，這樣新創建的AssetManager就含有了外部資源

將AssetManager類型的mAssets字段的引用全部替換為新的AssetManager.

代碼修復

類加載方案

類加載方案基于dex分包。 為什么要dex分包，因為65535的限制和LinearAlloc限制。65535限制。主要原因是DVM ByteCode的限制，dvm指令集方法調用指令invoke-kind索引為16bits,最多能引用65535個方法數

LinearAlloc限制Dvm中的LinearAlloc是一個固定的緩沖區，當方法數超出了緩存區大小就會報錯。

常用的做法：我們會新建一個hotfix分支，然后在該分支上修改bug，生成patch包，然后將patch放到Element數組dexElements的第一個元素，這樣就會優先加載patch中的類，后面存在bug的類就不會被加載。 因為classloader采用的雙親委托模式，同一個類加載之后就不會再次加載

類加載方案需要重啟app,讓classloader重新加載補丁包中的類。為什么要重啟？ 因為類是無法卸載的，想要重新加載新的類，就需要重啟app. 所以采用類加載方案是不能及時生效的。Q Q空間超級補丁，Nuwa,就是按照上面將補丁包放到Element數組的首位優先加載

微信的Tinker將新舊APK做了diff,得到patch.dex,再將patch.dex與手機APK中的classes.dex做合并，生成新的classes.dex.然后在運行時通過反射將classes.dex放到Element數組的第一位。

底層替換方案

底層替換方案不會再次加載新類，而是直接在Native層修改原有類。底層替換方案主要是替換ArtMethod結構體中的字段或者替換整個ArtMethod結構體。

AndFix采用的是替換ArtMethod結構體中的字段，但是會有兼容性問題，因為廠商會修改結構體，導致替換失敗

Sophix采用的是替換整個ArtMethod結構體，不會存在兼容問題。

底層替換方案是可以及時生效的，不需要重啟。

Instant Run方案主要是通過ASM來操作代碼，進行方法的修改。

ASM是一個字節碼操作框架，能夠動態生成類或者增強現有類的功能。ASM可以直接產生class文件，也可以在類被加載到虛擬機之前動態改變類的行為。

動態鏈接庫修復

這個主要是更新so,也就是重新加載so. 加載so有兩個方法System的load方法. 該方法傳入的參數是so在磁盤空間的完整路徑

System的loadLibrary方法。 該方法傳入的參數是so的名稱，用于加載apk安裝后自動從APK包中復制到/data/data/packagename/lib下的so. 目前so的修復主要是針對這兩個方法。

so修復的兩個方案將so補丁插入到NativeLibraryElement數組的前部，讓so補丁優先加載

調用System的load方法來接管so的加載入口。

參考：

《Android進階解密》

總結

以上是生活随笔為你收集整理的android的热修复,Android热修复原理的全部內容，希望文章能夠幫你解決所遇到的問題。

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