Android熱修復框架之優逆勢分析（Hotfix）

時間 2019-11-24

標籤 android 修復框架分析 hotfix 欄目 Android 简体版

原文原文鏈接

從新整理了一篇更詳細的，請移步 Android熱修復技術原理

Android平臺出現了一些優秀的熱更新方案，主要能夠分爲4類：html

基於Instant Run 熱插拔方案：美團的Robust（實時修復）

Robust插件對每一個產品代碼的每一個函數都在編譯打包階段自動的插入了一段代碼，對方法進行了Hook，相似AOP的方式。android

基於multidex的熱修復方案：表明有Qzone的超級補丁、大衆點評的Nuwa、百度金融的RocooFix、餓了麼的Amigo和微信的Tinker（也能夠修復so和資源）等（從新冷啓動修復）

須要反射更改DexElements，改變Dex的加載順序，這使得patch須要在下次啓動時才能生效，實時性就受到了影響，同時這種方案在android N [speed-profile]編譯模式下可能會有問題。git

基於native hook方案：如阿里開源的Andfix和Dexposed（實時修復）

須要針對dalvik虛擬機和art虛擬機作適配，須要考慮指令集的兼容問題，須要native代碼支持，兼容性上會有必定的影響；github

基於阿里混合模式：阿里沒有開源的Sophix（兼具實時修復和冷啓動修復）

在Andfix的基礎上進行優化和改進，因此具備實時修復特色。在Dex的加載，資源加載上都作了優化，解決了其餘熱修復框架上面沒法解決的痛點。總體作了大量的優化和改進，惟一的遺憾就是不開源，可是也將整套技術方案整理成電子書，也算是一種回饋吧。算法

相關技術文章編程

Android 熱修復專題：支付寶、淘寶、微信、QQ空間、餓了麼、美麗說蘑菇街、美團大衆點評方案集 https://zhuanlan.zhihu.com/p/25863920

阿里Dexposed -- native解決方案

原理：微信

直接在native層進行方法的結構體信息對換，從而實現完美的方法新舊替換，從而實現熱修復功能

他的思想徹底來源於Xposed框架，完美詮釋了AOP編程，這裏用到最核心的知識點就是在native層獲取到指定方法的結構體，而後改變他的nativeFunc字段值，而這個值就是能夠指定這個方法對應的native函數指針，因此先從Java層跳到native層，改變指定方法的nativeFunc值，而後在改變以後的函數中調用Java層的回調便可。實現了方法的攔截功能。框架

基於開源框架Xposed實現，是一種AOP解決方案
只Hook App自己的進程，不須要Root權限

優勢：ide

即時生效
不須要任何編譯器的插樁或者代碼改寫，對正常運行不引入任何性能開銷。這是AspectJ之類的框架無法比擬的優點；
對所改寫方法的性能開銷也極低（微秒級），基本能夠忽略不計；
從工程的角度來看，熱補丁僅僅是牛刀小試，它真正的威力在於『線上調試』；
基於Xposed原理實現的AOP不只能夠hook本身的代碼，還能夠hook同進程的Android SDK代碼，這也就可讓咱們有能力在App中填上Google本身挖的坑。

缺點：函數

Dalvik上近乎完美，不支持ART（須要另外的實現方式），因此5.0以上不能用了；
最大挑戰在於穩定性與兼容性，並且native異常排查難度更高；
因爲沒法增長變量與類等限制，沒法作到功能發佈級別；

相關連接：

阿里AndFix -- native解決方案

原理：

與Dexposed同樣都基於開源框架Xposed實現，是一種AOP解決方案

優勢：

即時生效
支持dalvik和art（AndFix supports Android version from 2.3 to 7.0, both ARM and X86 architecture, both Dalvik and ART runtime, both 32bit and 64bit.）
與Dexposed框架相比AndFix框架更加輕便好用，在進行熱修復的過程當中更加方便了

缺點：

面臨穩定性與兼容性問題
AndFix不支持新增方法，新增類，新增field等

相關連接：

文章：https://zhuanlan.zhihu.com/p/23935568
AndFix源碼：https://github.com/alibaba/AndFix

QQ空間--Dex分包方案（大衆點評的Nuwa參考其實現並開源）

原理：

原理是Hook了ClassLoader.pathList.dexElements[]。由於ClassLoader的findClass是經過遍歷dexElements[]中的dex來尋找類的。固然爲了支持4.x的機型，須要打包的時候進行插樁。
越靠前的Dex優先被系統使用，基於類級別的修復

優勢：

不須要考慮對dalvik虛擬機和art虛擬機作適配
代碼是非侵入式的，對apk體積影響不大

缺點：

須要下次啓動纔會生效
最大挑戰在於性能，即Dalvik平臺存在插樁致使的性能損耗，Art平臺因爲地址偏移問題致使補丁包可能過大的問題
虛擬機在安裝期間爲類打上CLASS_ISPREVERIFIED標誌是爲了提升性能的，咱們強制防止類被打上標誌是否會影響性能？這裏咱們會作一下更加詳細的性能測試．可是在大項目中拆分dex的問題已經比較嚴重，不少類都沒有被打上這個標誌。

相關連接：

文章：https://zhuanlan.zhihu.com/magilu/20308548
文章：http://blog.csdn.net/sbsujjbcy/article/details/50812674
Nuwa源碼：https://github.com/jasonross/Nuwa
HotFix源碼：https://github.com/dodola/HotFix
DroidFix源碼：https://github.com/bunnyblue/DroidFix

美團Robust -- Instant Run 熱插拔原理

原理：

Robust插件對每一個產品代碼的每一個函數都在編譯打包階段自動的插入了一段代碼，插入過程對業務開發是徹底透明
編譯打包階段自動爲每一個class都增長了一個類型爲ChangeQuickRedirect的靜態成員，而在每一個方法前都插入了使用changeQuickRedirect相關的邏輯，當 changeQuickRedirect不爲null時，可能會執行到accessDispatch從而替換掉以前老的邏輯，達到fix的目的。

優勢：

幾乎不會影響性能（方法調用，冷啓動）
支持Android2.3-8.x版本
高兼容性（Robust只是在正常的使用DexClassLoader）、高穩定性，修復成功率高達99.9%
補丁實時生效，不須要從新啓動
支持方法級別的修復，包括靜態方法
支持增長方法和類
支持ProGuard的混淆、內聯、優化等操做

缺點：

代碼是侵入式的，會在原有的類中加入相關代碼
so和資源的替換暫時不支持
會增大apk的體積，平均一個函數會比原來增長17.47個字節，10萬個函數會增長1.67M。
會增長少許方法數，使用了Robust插件後，原來能被ProGuard內聯的函數不能被內聯了

相關連接：

美團技術文章：https://tech.meituan.com/android_robust.html
美團技術文章：https://tech.meituan.com/android_autopatch.html
Robust源碼：https://github.com/Meituan-Dianping/Robust

微信Tinker

原理：

服務端作dex差量，將差量包下發到客戶端，在ART模式的機型上本地跟原apk中的classes.dex作merge，merge成爲一個新的merge.dex後將merge.dex插入pathClassLoader的dexElement，原理類同Q-Zone，爲了實現差量包的最小化，Tinker自研了DexDiff/DexMerge算法。Tinker還支持資源和So包的更新，So補丁包使用BsDiff來生成，資源補丁包直接使用文件md5對比來生成，針對資源比較大的（默認大於100KB屬於大文件）會使用BsDiff來對文件生成差量補丁。

優勢：