2019 深入解析Android熱修復(fù)技術(shù)

前言

通過閱讀本文，你會(huì)對熱修復(fù)技術(shù)有更深的認(rèn)知，本文會(huì)列出各類框架的優(yōu)缺點(diǎn)以及技術(shù)原理，文章末尾簡單描述一下Tinker的框架結(jié)構(gòu)。

本文框架

• 什么是熱修復(fù)？

• 熱修復(fù)框架分類

• 技術(shù)原理及特點(diǎn)

• Tinker框架解析

• 各框架對比圖

• 總結(jié)

一、什么是熱修復(fù)？

正常開發(fā)流程

熱修復(fù)優(yōu)勢

修復(fù)什么？

二、熱修復(fù)框架分類

現(xiàn)狀：百花齊放百家爭鳴

簡單分類；

更合理的分類；

三、技術(shù)原理及特點(diǎn)

3.1 阿里Dexposed -- native解決方案

原理：

• 直接在native層進(jìn)行方法的結(jié)構(gòu)體信息對換，從而實(shí)現(xiàn)完美的方法新舊替換，從而實(shí)現(xiàn)熱修復(fù)功能

他的思想完全來源于Xposed框架，完美詮釋了AOP編程，這里用到最核心的知識點(diǎn)就是在native層獲取到指定方法的結(jié)構(gòu)體，然后改變他的nativeFunc字段值，而這個(gè)值就是可以指定這個(gè)方法對應(yīng)的native函數(shù)指針，所以先從Java層跳到native層，改變指定方法的nativeFunc值，然后在改變之后的函數(shù)中調(diào)用Java層的回調(diào)即可。實(shí)現(xiàn)了方法的攔截功能。

• 基于開源框架Xposed實(shí)現(xiàn)，是一種AOP解決方案

• 只Hook App本身的進(jìn)程，不需要Root權(quán)限

優(yōu)點(diǎn)：

• 即時(shí)生效

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

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

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

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

缺點(diǎn)：

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

• 最大挑戰(zhàn)在于穩(wěn)定性與兼容性，而且native異常排查難度更高；

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

3.2 阿里AndFix -- native解決方案

原理：

• 與Dexposed一樣都基于開源框架Xposed實(shí)現(xiàn)，是一種AOP解決方案

優(yōu)點(diǎn)：

• 即時(shí)生效

• 支持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框架更加輕便好用，在進(jìn)行熱修復(fù)的過程中更加方便了

缺點(diǎn)：

• 面臨穩(wěn)定性與兼容性問題

• AndFix不支持新增方法，新增類，新增field等

AndFix（Dexpsed）框架不穩(wěn)定的原因（痛點(diǎn)）

原理：

• 原理是Hook了ClassLoader.pathList.dexElements[]。因?yàn)镃lassLoader的findClass是通過遍歷dexElements[]中的dex來尋找類的。當(dāng)然為了支持4.x的機(jī)型，需要打包的時(shí)候進(jìn)行插樁。

• 越靠前的Dex優(yōu)先被系統(tǒng)使用，基于類級別的修復(fù)

優(yōu)點(diǎn)：

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

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

缺點(diǎn)：

• 需要下次啟動(dòng)才會(huì)生效

• 最大挑戰(zhàn)在于性能，即Dalvik平臺存在插樁導(dǎo)致的性能損耗，Art平臺由于地址偏移問題導(dǎo)致補(bǔ)丁包可能過大的問題

• 虛擬機(jī)在安裝期間為類打上CLASS_ISPREVERIFIED標(biāo)志是為了提高性能的，我們強(qiáng)制防止類被打上標(biāo)志是否會(huì)影響性能？這里我們會(huì)做一下更加詳細(xì)的性能測試．但是在大項(xiàng)目中拆分dex的問題已經(jīng)比較嚴(yán)重，很多類都沒有被打上這個(gè)標(biāo)志。

插樁方案性能上的痛點(diǎn)：

3.4 美團(tuán)Robust -- Instant Run 熱插拔原理

原理：

• Robust插件對每個(gè)產(chǎn)品代碼的每個(gè)函數(shù)都在編譯打包階段自動(dòng)的插入了一段代碼，插入過程對業(yè)務(wù)開發(fā)是完全透明

• 編譯打包階段自動(dòng)為每個(gè)class都增加了一個(gè)類型為ChangeQuickRedirect的靜態(tài)成員，而在每個(gè)方法前都插入了使用changeQuickRedirect相關(guān)的邏輯，當(dāng) changeQuickRedirect不為null時(shí)，可能會(huì)執(zhí)行到accessDispatch從而替換掉之前老的邏輯，達(dá)到fix的目的。

優(yōu)點(diǎn)：

• 幾乎不會(huì)影響性能（方法調(diào)用，冷啟動(dòng)）

• 支持Android2.3-8.x版本

• 高兼容性（Robust只是在正常的使用DexClassLoader）、高穩(wěn)定性，修復(fù)成功率高達(dá)99.9%

• 補(bǔ)丁實(shí)時(shí)生效，不需要重新啟動(dòng)

• 支持方法級別的修復(fù)，包括靜態(tài)方法

• 支持增加方法和類

• 支持ProGuard的混淆、內(nèi)聯(lián)、優(yōu)化等操作

缺點(diǎn)：

• 代碼是侵入式的，會(huì)在原有的類中加入相關(guān)代碼

• so和資源的替換暫時(shí)不支持

• 會(huì)增大apk的體積，平均一個(gè)函數(shù)會(huì)比原來增加17.47個(gè)字節(jié)，10萬個(gè)函數(shù)會(huì)增加1.67M。

• 會(huì)增加少量方法數(shù)，使用了Robust插件后，原來能被ProGuard內(nèi)聯(lián)的函數(shù)不能被內(nèi)聯(lián)了

3.5 微信Tinker

原理：

• 服務(wù)端做dex差量，將差量包下發(fā)到客戶端，在ART模式的機(jī)型上本地跟原apk中的classes.dex做merge，merge成為一個(gè)新的merge.dex后將merge.dex插入pathClassLoader的dexElement，原理類同Q-Zone，為了實(shí)現(xiàn)差量包的最小化，Tinker自研了DexDiff/DexMerge算法。Tinker還支持資源和So包的更新，So補(bǔ)丁包使用BsDiff來生成，資源補(bǔ)丁包直接使用文件md5對比來生成，針對資源比較大的（默認(rèn)大于100KB屬于大文件）會(huì)使用BsDiff來對文件生成差量補(bǔ)丁。

優(yōu)點(diǎn)：

• 支持動(dòng)態(tài)下發(fā)代碼

• 支持替換So庫以及資源

缺點(diǎn)：

• 不能即時(shí)生效，需要下次啟動(dòng)

Tinker已知問題：

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

• 由于Google Play的開發(fā)者條款限制，不建議在GP渠道動(dòng)態(tài)更新代碼；

• 在Android N上，補(bǔ)丁對應(yīng)用啟動(dòng)時(shí)間有輕微的影響；

• 不支持部分三星android-21機(jī)型，加載補(bǔ)丁時(shí)會(huì)主動(dòng)拋出"TinkerRuntimeException:checkDexInstall failed"；

• 對于資源替換，不支持修改remoteView。例如transition動(dòng)畫，notification icon以及桌面圖標(biāo)。

Tinker性能痛點(diǎn)：

• Dex合并內(nèi)存消耗在vm head上，容易OOM，最后導(dǎo)致合并失敗。

• 如果本身app占用內(nèi)存已經(jīng)比較高，可能容易導(dǎo)致app本系統(tǒng)殺掉。

3.6 阿里Sophix

原理(雙劍合璧)：

優(yōu)化Andfix（突破底層結(jié)構(gòu)差異，解決穩(wěn)定性問題）：

Andfix底層ArtMethod結(jié)構(gòu)時(shí)采用內(nèi)部變量一一替換，倒是這個(gè)各個(gè)廠商是會(huì)修改的，所以兼容性不好。

Sophix改變了一下思路，采用整體替換方法結(jié)構(gòu)，忽略底層實(shí)現(xiàn)，從而解決兼容穩(wěn)定性問題。

突破QQ和Tinker的缺陷

QQ和Tinker的缺陷

Sophix對dex的解決方案

• Dalvik下采用阿里自研的全量dex方案：不是考慮把補(bǔ)丁包的dex插到所有dex前面（dex插樁），而是想辦法在原理的dex中刪除（只是刪除了類的定義）補(bǔ)丁dex中存在的類，這樣讓系統(tǒng)查找類的時(shí)候在原來的dex中找不到，那么只有補(bǔ)丁中的dex加載到系統(tǒng)中，系統(tǒng)自然就會(huì)從補(bǔ)丁包中找到對應(yīng)的類。

• Art下本質(zhì)上虛擬機(jī)以及支持多dex的加載，Sophix的做法僅僅是把補(bǔ)丁dex作為主dex（classes.dex）而已，相當(dāng)于重新組織了所有的dex文件：把補(bǔ)丁包的dex改名為classes.dex，以前apk的所有dex依次改為classes2.dex、classes3.dex ... classesx.dex，如下圖所示。

資源修復(fù)另辟蹊徑

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

Sophix資源修復(fù)方案

SO修復(fù)另辟蹊徑

四、Tinker框架解析

之所以只貼了Tinker的代碼框架，是因?yàn)槟壳伴_源的方案中是最好的，當(dāng)然除了Robust。

代碼結(jié)構(gòu)

修復(fù)流程

這里后續(xù)再補(bǔ)一個(gè)詳細(xì)的源碼分析，敬請期待

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

來自Tinker的對比；

來自Sophix的對比；

來自蘑菇街 Android 熱修復(fù)探索之路；

六、總結(jié)

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