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

Android平台出現了一些優秀的熱更新方案，主要可以分為4類：

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

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

基於multidex的熱修復方案：代表有Qzone的超級補丁、大眾點評的Nuwa、百度金融的RocooFix、餓了么的Amigo和微信的Tinker（也可以修復so和資源）等（重新冷啟動修復）

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

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

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

基於阿里混合模式：阿里沒有開源的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權限

優點：

即時生效
不需要任何編譯器的插樁或者代碼改寫，對正常運行不引入任何性能開銷。這是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來對文件生成差量補丁。