常見的幾個熱修復框架的對比

熱修復框架的種類繁多，按照公司團隊划分主要有以下幾種：

類別	成員
阿里系	AndFix、Dexposed、阿里百川、Sophix
騰訊系	微信的Tinker、QQ空間的超級補丁、手機QQ的QFix
知名公司	美團的Robust、餓了么的Amigo、美麗說蘑菇街的Aceso
其他	RocooFix、Nuwa、AnoleFix

雖然熱修復框架很多，但熱修復框架的核心技術主要有三類，分別是代碼修復、資源修復和動態鏈接庫修復，其中每個核心技術又有很多不同的技術方案，每個技術方案又有不同的實現，另外這些熱修復框架仍在不斷的更新迭代中，可見熱修復框架的技術實現是繁多可變的。

部分熱修復框架的對比如下表所示：

特性	AndFix	Tinker/Amigo	QQ空間	Robust/Aceso
即時生效	是	否	否	是
方法替換	是	是	是	是
類替換	否	是	是	否
類結構修改	否	是	否	否
資源替換	否	是	是	否
so替換	否	是	否	否
支持gradle	否	是	否	否
支持ART	是	是	是	是
支持Android7.0	是	是	是	是

我們可以根據上表和具體業務來選擇合適的熱修復框架，當然上表的信息很難做到完全准確，因為部分的熱修復框架還在不斷更新迭代。

從表中也可以發現Tinker和Amigo擁有的特性最多，是不是就選它們呢？也不盡然，擁有的特性多也意味着框架的代碼量龐大，我們需要根據業務來選擇最合適的，假設我們只是要用到方法替換，那么使用Tinker和Amigo顯然是大材小用了。另外如果項目需要即時生效，那么使用Tinker和Amigo是無法滿足需求的。

Tinker、AndFix 等框架的比較

Tinker的功能非常強大，基本除了AndroidManifest.xml文件和tinker本身少數幾個類之外，其他內容都能替換，包括布局、資源

但是接入麻煩，上手難度較AndFix高很多。

和Tinker不同， AndFix上手非常容易，只需寥寥數行代碼即可，但沒有Tinker功能多。

由於AndFix實現原理是底層通過c++直接操作指針實現，它可以做到加載補丁后實時生效，但它目前只支持替換方法實現內容，不能增加類也不能增加、修改字段。

	Tinker	QZone	AndFix	Robust
類替換	yes	yes	no	no
So替換	yes	no	no	no
資源替換	yes	yes	no	no
全平台支持	yes	yes	yes	yes
即時生效	no	no	yes	yes
性能損耗	較小	較大	較小	較小
補丁包大小	較小	較大	一般	一般
開發透明	yes	yes	no	no
復雜度	較低	較低	復雜	復雜
gradle支持	yes	no	no	no
Rom體積	較大	較小	較小	較小
成功率	較高	較高	一般	最高

阿里各個版本熱修復的差別

參考

雖然有着一些使用限制，但一旦滿足使用條件，這種熱修復方式是十分出眾的，它補丁小，加載迅速，能夠實時生效無需重新啟動app，並且具有着完美的設備兼容性。對於較小程度的修復再適合不過了。

本修復方案將最先在阿里Hotfix最新版本(Sophix)上應用，由手機淘寶技術團隊與阿里雲聯合發布。

Sophix提供了一套更加完美的客戶端服務端一體的熱更新方案。針對小修改可以采用本文這種即時生效的熱修復，並且可以結合資源修復，做到資源和代碼的即時生效。

而如果觸及了本文提到的熱替換使用限制，對於比較大的代碼改動以及被修復方法反射調用情況，Sophix也提供了另一種完整代碼修復機制，不過是需要app重新冷啟動，來發揮其更加完善的修復及更新功能。從而可以做到無感知的應用更新。

並且Sophix做到了圖形界面一鍵打包、加密傳輸、簽名校驗和服務端控制發布與灰度功能，讓你用最少的時間實現最強大可靠的全方位熱更新。

一張表格來說明一下各個版本熱修復的差別：

方案對比	Andfix開源版本	阿里Hotfix 1.X	阿里Hotfix最新版(Sophix)
方法替換	支持，除部分情況^[0]	支持，除部分情況	全部支持
方法增加減少	不支持	不支持	以冷啟動方式支持^[1]
方法反射調用	只支持靜態方法	只支持靜態方法	以冷啟動方式支持
即時生效	支持	支持	視情況支持^[2]
多DEX	不支持	支持	支持
資源更新	不支持	不支持	支持
so庫更新	不支持	不支持	支持
Android版本	支持2.3~7.0	支持2.3~6.0	全部支持包含7.0以上
已有機型	大部分支持^[3]	大部分支持	全部支持
安全機制	無	加密傳輸及簽名校驗	加密傳輸及簽名校驗
性能損耗	低，幾乎無損耗	低，幾乎無損耗	低，僅冷啟動情況下有些損耗
生成補丁	繁瑣，命令行操作	繁瑣，命令行操作	便捷，圖形化界面
補丁大小	不大，僅變動的類	小，僅變動的方法	不大，僅變動的資源和代碼^[4]
服務端支持	無	支持服務端控制^[5]	支持服務端控制

說明：

[0] 部分情況指的是構造方法、參數數目大於8或者參數包括long,double,float基本類型的方法。
[1] 冷啟動方式，指的是需要重啟app在下次啟動時才能生效。
[2] 對於Andfix及Hotfix 1.X能夠支持的代碼變動情況，都能做到即時生效。而對於Andfix及Hotfix 1.X不支持的代碼變動情況，會走冷啟動方式，此時就無法做到即時生效。
[3] Hotfix 1.X已經支持絕大部分主流手機，只是在X86設備以及修改了虛擬機底層結構的ROM上不支持。
[4] 由於支持了資源和庫，如果有這些方面的更新，就會導致補丁變大一些，這個是很正常的。並且由於只包含差異的部分，所以補丁已經是最大程度的小了。
[5] 提供服務端的補丁發布和停發、版本控制和灰度功能，存儲開發者上傳的補丁包。

從現在起，讓你的APP實現隨心所欲的熱更新吧！請猛戳這里>_<

注意事項

在本地動態執行遠端下發的代碼是極度危險的行為，利用此方法執行非法代碼等或用於繞過 Google Play 等市場的審查是違反相關協議的，也是對用戶極度不負責任的行為。
在一些訪問非常密集的地方使用熱更新可能會對效率產生相對比較大的影響，應該避免使用。
我們可以對 Java 的 ScriptEngine 進行一些封裝成為一個 HotPatch 類使得它更適合做熱更新的工作。
檢查熱更新補丁的管道一定要建立在 https 上，因為下發代碼是極其危險的，如果被劫持，后果是無法想象的。
請求時最好自動帶上 Android 版本、手機型號、地區、版本號等信息，以方便更精確地下發，千萬不能下發錯。
Java在運行時加載對應的類是通過ClassLoader來實現的，ClassLoader本身是一個抽象來，Android中使用PathClassLoader類作為Android的默認的類加載器。
我們如果想做hotpatch，一定要保證我們的hotpacth dex文件出現在dexElements列表的前面。