1.分包背景
這里首先介紹下MultiDex的產生背景。
當Android系統安裝一個應用的時候，有一步是對Dex進行優化，這個過程有一個專門的工具來處理，叫DexOpt。DexOpt的執行過程是在第一次加載Dex文件的時候執行的。這個過程會生成一個ODEX文件，即Optimised Dex。執行ODex的效率會比直接執行Dex文件的效率要高很多。
但是在早期的Android系統中，DexOpt有一個問題，DexOpt會把每一個類的方法id檢索起來，存在一個鏈表結構里面。但是這個鏈表的長度是用一個short類型來保存的，導致了方法id的數目不能夠超過65536個。當一個項目足夠大的時候，顯然這個方法數的上限是不夠的。盡管在新版本的Android系統中，DexOpt修復了這個問題，但是我們仍然需要對低版本的Android系統做兼容。
為了解決方法數超限的問題，需要將該dex文件拆成兩個或多個，為此谷歌官方推出了multidex兼容包，配合AndroidStudio實現了一個APK包含多個dex的功能。
我們在Android開發中，會不斷的在App代碼里面增加新功能，引入新的類庫，如果不加控制的話，那么會碰到編輯器IDE爆出一下錯誤：
|
1
2
|
Error:Execution failed for task ':ttt:transformClassesWithDexForDebug'.com.android.build.api.transform.TransformException: com.android.ide.common.process.ProcessException: java.util.concurrent.ExecutionException: com.android.dex.DexIndexOverflowException: method ID not in [0, 0xffff]: 65536 |
這個錯誤是Android應用的對方法總數有限制造成的。Android平臺的Java虛擬機Dalvik在執行DEX格式的Java應用程序時，使用原生類型short來索引DEX文件中的方法。這意味著單個DEX文件可被引用的方法總數被限制為65536。通常APK包含一個classes.dex文件，因此Android應用的方法總數不能超過這個數量，這包括Android框架、類庫和你自己開發的代碼。
這個問題可以通過將一個DEX文件分拆成多個DEX文件解決。
2. 分包策略實現
Gradle 配置：
|
1
2
3
4
5
6
7
8
9
10
|
defaultConfig { applicationId "XXX" minSdkVersion 14 targetSdkVersion 23 multiDexEnabled true}.......dependencies { compile 'com.android.support:multidex:1.0.0'} |
在應用的Application 類重寫方法：
|
1
2
3
4
5
|
@Overrideprotected void attachBaseContext(Context base) { super.attachBaseContext(base); MultiDex.install(this);} |
3.分包效果說明
經過以上的配置，你的應用已經可以實現多個DEX文件了。當應用構建時，構建工具會分析哪些類必須放在第一個DEX文件，哪些類可以放在附加的DEX文件中。當它創建了第一個DEX文件后，如果有必要會繼續創建附加的DEX文件，如classes2.dex, classes3.dex。Multidex的支持類庫將被包含在應用的第一個DEX文件中，幫助實現對其它DEX文件的訪問。
雖然Google解決了應用總方法數限制的問題，但并不意味著開發者可以任意擴大項目規模。Multidex仍有一些限制：
DEX文件安裝到設備的過程非常復雜，如果第二個DEX文件太大，可能導致應用無響應。此時應該使用ProGuard減小DEX文件的大小。
由于Dalvik linearAlloc的Bug，應用可能無法在Android 4.0之前的版本啟動，如果你的應用要支持這些版本就要多執行測試。
同樣因為Dalvik linearAlloc的限制，如果請求大量內存可能導致崩潰。Dalvik linearAlloc是一個固定大小的緩沖區。在應用的安裝過程中，系統會運行一個名為dexopt的程序為該應用在當前機型中運行做準備。dexopt使用LinearAlloc來存儲應用的方法信息。Android 2.2和2.3的緩沖區只有5MB，Android 4.x提高到了8MB或16MB。當方法數量過多導致超出緩沖區大小時，會造成dexopt崩潰。
-Multidex構建工具還不支持指定哪些類必須包含在首個DEX文件中，因此可能會導致某些類庫（例如某個類庫需要從原生代碼訪問Java代碼）無法使用。
4.對開發者的建議
開發者應該避免使用Google Guava這樣的類庫，它包含了13000多個方法。
盡量使用專為移動應用設計的Lite/Android版本類庫，或者使用小類庫替換大類庫，例如用Google-gson替換Jackson JSON。而對于Google Protocol Buffers這樣的數據交換格式，其標準實現會自動生成大量的方法。采用Square Wire的實現則可以很好地解決此問題。
在出現應用分包后低版本手機無法使用，高版本正常使用的問題時，可以考慮檢查一下分包的配置是否正確。
總結
以上就是本文關于Android分包MultiDex策略詳解的全部內容，希望對大家有所幫助。感興趣的朋友可以繼續參閱本站其他相關內容，如有不足之處，歡迎留言指出。
原文鏈接：http://www.cnblogs.com/renhui/p/7738421.html
