摘要：不過它確實各方面都做了大量的優(yōu)化，本文中的很多知識點也來源于阿里的熱修復(fù)技術(shù)原理一書，本書值得一讀，里面就是基于框架來編排的。

什么是熱修復(fù)？

熱修復(fù)框架分類

技術(shù)原理及特點

Tinker框架解析

各框架對比圖

總結(jié)

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

1.正常開發(fā)流程

2.熱修復(fù)開發(fā)流程

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

4.修復(fù)什么？

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

2.簡單分類；

3.更合理的分類；

3.1 阿里Dexposed -- native解決方案

原理：

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

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

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

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

優(yōu)點：

即時生效

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

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

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

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

缺點：

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

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

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

3.2 阿里AndFix -- native解決方案

原理：

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

優(yōu)點：

即時生效

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

缺點：

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

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

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

原理：

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

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

優(yōu)點：

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

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

缺點：

需要下次啟動才會生效

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

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

插樁方案性能上的痛點：

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

原理：

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

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

優(yōu)點：

幾乎不會影響性能（方法調(diào)用，冷啟動）

支持Android2.3-8.x版本

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

補丁實時生效，不需要重新啟動

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

支持增加方法和類

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

缺點：

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

so和資源的替換暫時不支持

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

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

3.5 微信Tinker

原理：

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

優(yōu)點：

支持動態(tài)下發(fā)代碼

支持替換So庫以及資源

缺點：

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

Tinker已知問題：

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

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

在Android N上，補丁對應(yīng)用啟動時間有輕微的影響；

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

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

Tinker性能痛點：

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)時采用內(nèi)部變量一一替換，倒是這個各個廠商是會修改的，所以兼容性不好。

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

突破QQ和Tinker的缺陷

QQ和Tinker的缺陷

Sophix對dex的解決方案

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

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

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

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

Sophix資源修復(fù)方案

SO修復(fù)另辟蹊徑

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

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

修復(fù)流程；

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

來自Tinker的對比；

來自Sophix的對比；

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

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

最后分享我整理的騰訊T3級別的整套系統(tǒng)化的進階視頻，對于有3到5年Android開發(fā)經(jīng)驗的朋友深入學(xué)習(xí)提升幫助很大。有興趣的小伙伴可以加騰訊課堂的官方交流群；830344345。免費學(xué)習(xí)下載。