2019 深入解析Android熱修復技術

前言

通過閱讀本文，你會對熱修復技術有更深的認知，本文會列出各類框架的優缺點以及技術原理，文章末尾簡單描述一下Tinker的框架結構。

本文框架

• 什么是熱修復？

• 熱修復框架分類

• 技術原理及特點

• Tinker框架解析

• 各框架對比圖

• 總結

一、什么是熱修復？

正常開發流程

熱修復優勢

修復什么？

二、熱修復框架分類

現狀：百花齊放百家爭鳴

簡單分類；

更合理的分類；

三、技術原理及特點

3.1 阿里Dexposed -- native解決方案

原理：

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

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

• 基于開源框架Xposed實現，是一種AOP解決方案

• 只Hook App本身的進程，不需要Root權限

優點：

• 即時生效

• 不需要任何編譯器的插樁或者代碼改寫，對正常運行不引入任何性能開銷。這是AspectJ之類的框架沒法比擬的優勢；

• 對所改寫方法的性能開銷也極低（微秒級），基本可以忽略不計；

• 從工程的角度來看，熱補丁僅僅是牛刀小試，它真正的威力在于『線上調試』；

• 基于Xposed原理實現的AOP不僅可以hook自己的代碼，還可以hook同進程的Android SDK代碼，這也就可以讓我們有能力在App中填上Google自己挖的坑。

缺點：

• Dalvik上近乎完美，不支持ART（需要另外的實現方式），所以5.0以上不能用了；

• 最大挑戰在于穩定性與兼容性，而且native異常排查難度更高；

• 由于無法增加變量與類等限制，無法做到功能發布級別；

3.2 阿里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等

AndFix（Dexpsed）框架不穩定的原因（痛點）

原理：

• 原理是Hook了ClassLoader.pathList.dexElements[]。因為ClassLoader的findClass是通過遍歷dexElements[]中的dex來尋找類的。當然為了支持4.x的機型，需要打包的時候進行插樁。

• 越靠前的Dex優先被系統使用，基于類級別的修復

優點：

• 不需要考慮對dalvik虛擬機和art虛擬機做適配

• 代碼是非侵入式的，對apk體積影響不大

缺點：

• 需要下次啟動才會生效

• 最大挑戰在于性能，即Dalvik平臺存在插樁導致的性能損耗，Art平臺由于地址偏移問題導致補丁包可能過大的問題

• 虛擬機在安裝期間為類打上CLASS_ISPREVERIFIED標志是為了提高性能的，我們強制防止類被打上標志是否會影響性能？這里我們會做一下更加詳細的性能測試．但是在大項目中拆分dex的問題已經比較嚴重，很多類都沒有被打上這個標志。

插樁方案性能上的痛點：

3.4 美團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內聯的函數不能被內聯了

3.5 微信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來對文件生成差量補丁。

優點：

• 支持動態下發代碼

• 支持替換So庫以及資源

缺點：

• 不能即時生效，需要下次啟動

Tinker已知問題：

• Tinker不支持修改AndroidManifest.xml，Tinker不支持新增四大組件(1.9.0支持新增非export的Activity)；

• 由于Google Play的開發者條款限制，不建議在GP渠道動態更新代碼；

• 在Android N上，補丁對應用啟動時間有輕微的影響；

• 不支持部分三星android-21機型，加載補丁時會主動拋出"TinkerRuntimeException:checkDexInstall failed"；

• 對于資源替換，不支持修改remoteView。例如transition動畫，notification icon以及桌面圖標。

Tinker性能痛點：

• Dex合并內存消耗在vm head上，容易OOM，最后導致合并失敗。

• 如果本身app占用內存已經比較高，可能容易導致app本系統殺掉。

3.6 阿里Sophix

原理(雙劍合璧)：

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

Andfix底層ArtMethod結構時采用內部變量一一替換，倒是這個各個廠商是會修改的，所以兼容性不好。

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

突破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，如下圖所示。

資源修復另辟蹊徑

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

Sophix資源修復方案

SO修復另辟蹊徑

四、Tinker框架解析

之所以只貼了Tinker的代碼框架，是因為目前開源的方案中是最好的，當然除了Robust。

代碼結構

修復流程

這里后續再補一個詳細的源碼分析，敬請期待

五、對比圖（來自不同的地方）

來自Tinker的對比；

來自Sophix的對比；

來自蘑菇街 Android 熱修復探索之路；

六、總結

如果不考慮增大apk的體積，只是簡單的修復代碼，不修復so和資源，選擇Robust是最穩定的，否則的話選擇Tinker是一個不錯的方案。雖然阿里Sophix橫空出世，但是它不開源，而且商業收費，所以一般不是很賺錢的app選擇收費的可能就很小了。不過它確實各方面都做了大量的優化，本文中的很多知識點也來源于阿里的《Android熱修復技術原理.pdf》一書，本書值得一讀，里面就是基于Sophix框架來編排的。