熱修復實現原理——MultiDex
一、 MultiDex
1、MultiDex 產生背景
當Android系統安裝一個應用的時候，有一步是對Dex進行優化，這個過程有一個專門的工具來處理，叫DexOpt。DexOpt的執行過程是在第一次加載Dex文件的時候執行的。這個過程會生成一個ODEX文件，即Optimised Dex。執行ODex的效率會比直接執行Dex文件的效率要高很多。
但是在早期的Android系統中，DexOpt有一個問題，DexOpt會把每一個類的方法id檢索起來，存在一個鏈表結構里面。但是這個鏈表的長度是用一個short類型來保存的，導致了方法id的數目不能夠超過65536個。
而當一個項目足夠大的時候：
- 生成的apk在2.3以前的機器無法安裝，提示INSTALL_FAILED_DEXOPT
- 方法數量過多，編譯時出錯，提示：Conversion to Dalvik format failed:Unable to execute dex: method ID not in [0, 0xffff]: 65536
原因：
- Android2.3及以前版本用來執行dexopt(用于優化dex文件)的內存只分配了5M
- 一個dex文件最多只支持65536個方法。
為了解決方法數超限的問題，需要將該dex文件拆成兩個或多個，為此谷歌官方推出了multidex兼容包，配合AndroidStudio實現了一個APK包含多個dex的功能。
2、MultiDex的思路
- 通過反射獲取PathClassLoader中的DexPathList中的Element數組（已加載了第一個dex包，由系統加載）
- 通過反射獲取DexClassLoader中的DexPathList中的Element數組（將第二個dex包加載進去）
- 將兩個Element數組合并之后，再將其賦值給PathClassLoader的Element數組
事實上，谷歌提供的MultiDex支持庫就是按照這個思路來實現的。
3、MultiDex的實現
I、MultiDex的原理
- apk在Applicaion實例化之后，會檢查系統版本是否支持MultiDex，判斷二級dex是否需要安裝；
- 如果需要安裝則會從apk中解壓出classes2.dex并將其拷貝到應用的/data/data/ /code_cache/secondary-dexes/目錄下；
- 通過反射將classes2.dex等注入到當前的ClassLoader的pathList中，完成整體安裝流程。
II、DexClassLoader的動態加載
4、Multidex的方式的局限性或者缺點
在冷啟動時因為需要安裝DEX文件，如果DEX文件過大時，處理時間過長，很容易引發ANR（Application Not Responding）；
采用MultiDex方案的應用因為需要申請一個很大的內存，在運行時可能導致程序的崩潰，這個主要是因為Dalvik linearAlloc 的一個限制(Issue 78035). 這個限制在 Android 4.0 (API level 14)已經增加了, 應用也有可能在低于 Android 5.0 (API level 21)版本的機器上觸發這個限制；
對于應用程序比較復雜的，存在較多的library的項目。multidex可能會造成不同依賴項目間的dex文件函數相互調用，找不到方法。
-
在Android 4.0設備（API Level 14）之前，由于Dalvik linearalloc bug（問題22586），multidex很可能是無法運行的。如果運行在Level 14之前的Android系統版本，需確保完整的測試和使用。
MultiDex最低只支持到1.6；MultiDex 最高只支持到20(Android 4.4W)，更高的版本不能保證正常工作
需要防止類被打上CLASS_ISPREVERIFIED，虛擬機在安裝期間為類打上CLASS_ISPREVERIFIED標志是為了提高性能的，強制防止類被打上標志會影響性能；
下一次啟動才生效;
-
Dalvik：對啟動速度略微有影響（插樁導致對程序運行時的性能產生影響），
Art下：補丁中的類出現修改類變量或者方法，可能會導致出現內存地址錯亂的問題。
備注：ART模式英文全稱為：Android runtime，谷歌Android 4.4系統新增的一種應用運行模式。ART模式與Dalvik模式最大的不同在于，在啟用ART模式后，系統在安裝應用的時候會進行一次預編譯，在安裝應用程序時會先將代碼轉換為機器語言存儲在本地，這樣在運行程序時就不會每次都進行一次編譯了，執行效率也大大提升。
二、熱修復——MultiDex 實現形式
一個ClassLoader可以包含多個dex文件，每個dex文件是一個Element，多個dex文件排列成一個有序的數組dexElements，當找類的時候，會按順序遍歷dex文件，然后從當前遍歷的dex文件中找類，如果找類則返回，如果找不到從下一個dex文件繼續查找。
理論上，如果在不同的dex中有相同的類存在，那么會優先選擇排在前面的dex文件的類，如下圖：
所以，如果某些類需要修復，我們可以把有問題的類打包到一個dex（patch.dex）中去，然后把這個dex插入到Elements的最前面，如下圖
使用該原理的開源方案有：
大眾點評Nuwa
https://github.com/jasonross/Nuwa
阿里 HotFix
https://github.com/dodola/HotFix
DroidFix
https://github.com/bunnyblue/DroidFix
Tinker
