1為什么需要熱更新？
正常開發流程：
新版本上線，發現問題或用戶反饋bug，緊急修復，上線版本，用戶重新安裝。
存著如下問題：
l 周期長
l 用戶下載成本高，app推廣成本高昂
l 修復不及時，用戶體驗差，用戶遇到奔潰時失去耐心后直接卸載。
熱修復流程：
新版本上線，發現問題或用戶反饋，緊急修復，上線補丁，自動修復
存著如下優點：
l 無需重新發版，及時修復問題
l 用戶無感知修復，無需下載新應用，代價小
l 修復成功率高，把損失降到最低
但熱修復因為大量涉及android底層知識，又因為android本身開源，華為vivo小米幾大廠商都可能修改底層相關代碼，兼容性困難，所以熱修復技術開發維護難度巨大，人力和時間投入不菲。目前主要有騰訊，阿里等幾家互聯網大廠因自身剛性需求，實現此功能。
目前熱修復技術主要有以下幾家：
騰訊系：
QQ超級補丁
**tinker **
阿里系：
Xposed (不支持Art虛擬機，已廢棄)
Andfix (native hook兼容差，適配機型少)
Sophix 新一代
餓了嗎：
amigo
美團：
robust 每個函數插入額外邏輯
以上幾家熱修復技術都各有優缺點，也各說各的好。因此我們在引入時需要從代碼侵入性，修復實時性，兼容，支持力度等幾個維度綜合評估。
雖然熱修復在android生態圈目前呈現百花齊放的態勢，但追根溯源熱更新實現的基本原理，可以劃分為以tinker為代表的multidex類加載法和以阿里andfix為代表的底層替換法，而阿里sophix為了提高熱修復的成功率同時采用了上述兩種方案，并在兼容性上進行了一定的優化。
2底層替換方案：
2.1我們首先以andfix為例，簡答介紹底層替換方案。
底層替換是在已經加載了的類中直接在native層替換掉原有方法，見下圖。
Andfix核心函數replaceMehtod，它的參數是在java層通過反射機制得到的method對象對應的jobject。Src對應的是需要被替換的原有方法，dest對應的是新方法。
具體替換以art虛擬機為例，通過替換java對象的數據結構ArtMehtod的所有成員。
Andfix逐個替換方式
Sophix整體替換方式
2.2
由于底層替換原理只支持方法替換，不支持方法的增加和減少，成員字段的增加和減少，所以我們需要知道哪些修改會導致方法，字段的改變，從而底層替換熱部署失效。
a 非靜態內部類
非靜態內部類編譯后實際和外部類一樣都是頂級類。外部類為了訪問內部類的private field method，內部類額外會添加access方法。
b 匿名內部類
匿名內部類編譯后名字命名規則為外部類&number ,number根據匿名內部類在外部類出現的先后次序依次累加。如果將匿名內部類的次序調整，我們無法區分修改前后的差異的。
c 靜態field 靜態代碼塊
這2塊是被編譯器翻譯在clinit方法中，clinit方法是在類加載階段調用，導致熱部署方案失效。
d final static 域
代碼中變量i2, s2這兩個靜態域沒有被初始化在clinit中，而是在dvmInitClass的initSFields方法中，這個方法在clinit之前執行。
此外泛型，lambda函數的修改都有可能導致熱部署失效，這些都需要我們對android虛擬機的編譯有一定了解，在此我們不再贅述。
所以底層替換方法限制較多，但優點是實現熱部署，修改及時生效。
3 Multidex類加載法：
接著我們以tinker為例，簡單介紹multidex類加載方案。
3.1 64K事件
在android5.0之前，每個android應用只含有一個dex文件，dex的方法數量被限制在了65535之內，導致apk引入大量第三方sdk后方法數量超過限制無法編譯通過。為了解決這個問題，Google推出多dex文件的解決方案multidex，一個apk可以包含多個dex文件。通過Multidex.install(this)完成dex文件的加載。
Tinker方案參考multidex實現原理，在編譯時通過新舊兩個Dex生成差異patch.dex。在運行時，將差異patch.dex重新和原始安裝包的舊Dex合并還原為新的Dex。這個過程可能比較耗費時間與內存，所以tinker單獨放在一個后臺進程:patch中處理。為了補丁包盡量的小，微信自研了DexDiff算法，它深度利用Dex的格式來減少差異的大小。由于采用ClassLoader機制，所以需要app重啟。
3.2 Multidex.install()流程
我們分析下android的Multidex.install()的流程
MultiDex.install()在app最初啟動時被調用。
Install() 實現獲取DexClassLoader 解壓縮dex文件，根據不同的平臺版本加載補丁。
我們以V19.install為例，根據注釋我們可以知道它通過反射將多余的dex file 添加到DexPathList的pathList數組字段里。
我們查看DexPathList類確實如此。
那為什么通過添加就能夠實現多dex文件的合并呢？
重點我們需要看下makeDexElements這個函數做了什么處理。
這個函數通過反射調用了DexPathList的makeDexElements, 我們繼續跟蹤makeDexElements具體實現，發現它調用了loadDexFile.
我們繼續跟蹤loadDexFile, 發現最終它調用DexFile.loadDex(); 我們重點看下該函數的注釋如下。
我們繼續跟蹤發現已經到DexFile的C++ 部分，內部是對dexfile處理的具體實現，在此我們不再敘述。
通過對MultiDex.install()流程的跟蹤，我們基本可以了解騰訊tinker的熱更新原理。Tinker基于基版本利用自研的DexDiff算法生成差分包，放在后臺。App啟動時下載差分包，與原dex重新合并，解壓縮，并參考MultiDex.install()流程，重新安裝app。
我們查看Tinker的核心源碼確認基本按照這個思路實現，如下為tinker加載的核心函數。
由于類加載實現原理涉及dex文件的重新解壓縮合并等處理，消耗內存大，耗時長，在系統低內存時容易導致熱更新失敗，騰訊測試成功率大概為95%。實際熱部署時，差分包應文件大小最小。
綜上沒有完美的熱更新方案，沒有100%的熱更新成功率。目前，騰訊tinker基本可以滿足app的熱更新需求，但隨著app用戶規模不斷增大，業務需求日益復雜，可考慮阿里的sophix商業方案，sophix同時應用類加載和底層替換兩種方案，具有底層替換的修改及時性，和類加載方案的兼容性等優點。
注：此文主要介紹底層替換和類加載技術兩種方案，但對于熱更新我們還需要了解dalvik, art虛擬機下app優化，安裝的原理和差異，android類加載PathClassLoader,DexClassLoader原理, android文件校驗機制等，在此我們不再贅述。
引用：
《深入探索android熱修復技術原理》手淘技術團隊
<u>http://blog.csdn.net/jason0539/article/details/50440669</u>
<u>https://jaeger.itscoder.com/android/2016/08/27/android-classloader.html</u>
<u>http://blog.csdn.net/nanzhiwen666/article/details/50515895</u>
<u>https://github.com/Tencent/tinker</u>
Android 5.1 source code
