快捷導(dǎo)航

Android分包MultiDex策略詳解

更新時(shí)間：2017年10月30日 09:35:40 作者：灰色飄零

這篇文章主要介紹了Android分包MultiDex策略詳解，具有一定參考價(jià)值，需要的朋友可以了解下。

1.分包背景

這里首先介紹下MultiDex的產(chǎn)生背景。

當(dāng)Android系統(tǒng)安裝一個(gè)應(yīng)用的時(shí)候，有一步是對(duì)Dex進(jìn)行優(yōu)化，這個(gè)過(guò)程有一個(gè)專門的工具來(lái)處理，叫DexOpt。DexOpt的執(zhí)行過(guò)程是在第一次加載Dex文件的時(shí)候執(zhí)行的。這個(gè)過(guò)程會(huì)生成一個(gè)ODEX文件，即Optimised Dex。執(zhí)行ODex的效率會(huì)比直接執(zhí)行Dex文件的效率要高很多。

但是在早期的Android系統(tǒng)中，DexOpt有一個(gè)問(wèn)題，DexOpt會(huì)把每一個(gè)類的方法id檢索起來(lái)，存在一個(gè)鏈表結(jié)構(gòu)里面。但是這個(gè)鏈表的長(zhǎng)度是用一個(gè)short類型來(lái)保存的，導(dǎo)致了方法id的數(shù)目不能夠超過(guò)65536個(gè)。當(dāng)一個(gè)項(xiàng)目足夠大的時(shí)候，顯然這個(gè)方法數(shù)的上限是不夠的。盡管在新版本的Android系統(tǒng)中，DexOpt修復(fù)了這個(gè)問(wèn)題，但是我們?nèi)匀恍枰獙?duì)低版本的Android系統(tǒng)做兼容。

為了解決方法數(shù)超限的問(wèn)題，需要將該dex文件拆成兩個(gè)或多個(gè)，為此谷歌官方推出了multidex兼容包，配合AndroidStudio實(shí)現(xiàn)了一個(gè)APK包含多個(gè)dex的功能。

我們?cè)贏ndroid開(kāi)發(fā)中，會(huì)不斷的在App代碼里面增加新功能，引入新的類庫(kù)，如果不加控制的話，那么會(huì)碰到編輯器IDE爆出一下錯(cuò)誤：

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

這個(gè)錯(cuò)誤是Android應(yīng)用的對(duì)方法總數(shù)有限制造成的。Android平臺(tái)的Java虛擬機(jī)Dalvik在執(zhí)行DEX格式的Java應(yīng)用程序時(shí)，使用原生類型short來(lái)索引DEX文件中的方法。這意味著單個(gè)DEX文件可被引用的方法總數(shù)被限制為65536。通常APK包含一個(gè)classes.dex文件，因此Android應(yīng)用的方法總數(shù)不能超過(guò)這個(gè)數(shù)量，這包括Android框架、類庫(kù)和你自己開(kāi)發(fā)的代碼。

這個(gè)問(wèn)題可以通過(guò)將一個(gè)DEX文件分拆成多個(gè)DEX文件解決。

2. 分包策略實(shí)現(xiàn)

Gradle 配置：

defaultConfig {  
    applicationId "XXX"
    minSdkVersion 14
    targetSdkVersion 23
    multiDexEnabled true
}
.......
dependencies {
  compile 'com.android.support:multidex:1.0.0'
}

在應(yīng)用的Application 類重寫方法：

@Override
protected void attachBaseContext(Context base) {
  super.attachBaseContext(base);
  MultiDex.install(this);
}

3.分包效果說(shuō)明

經(jīng)過(guò)以上的配置，你的應(yīng)用已經(jīng)可以實(shí)現(xiàn)多個(gè)DEX文件了。當(dāng)應(yīng)用構(gòu)建時(shí)，構(gòu)建工具會(huì)分析哪些類必須放在第一個(gè)DEX文件，哪些類可以放在附加的DEX文件中。當(dāng)它創(chuàng)建了第一個(gè)DEX文件后，如果有必要會(huì)繼續(xù)創(chuàng)建附加的DEX文件，如classes2.dex, classes3.dex。Multidex的支持類庫(kù)將被包含在應(yīng)用的第一個(gè)DEX文件中，幫助實(shí)現(xiàn)對(duì)其它DEX文件的訪問(wèn)。

雖然Google解決了應(yīng)用總方法數(shù)限制的問(wèn)題，但并不意味著開(kāi)發(fā)者可以任意擴(kuò)大項(xiàng)目規(guī)模。Multidex仍有一些限制：

DEX文件安裝到設(shè)備的過(guò)程非常復(fù)雜，如果第二個(gè)DEX文件太大，可能導(dǎo)致應(yīng)用無(wú)響應(yīng)。此時(shí)應(yīng)該使用ProGuard減小DEX文件的大小。

由于Dalvik linearAlloc的Bug，應(yīng)用可能無(wú)法在Android 4.0之前的版本啟動(dòng)，如果你的應(yīng)用要支持這些版本就要多執(zhí)行測(cè)試。
同樣因?yàn)镈alvik linearAlloc的限制，如果請(qǐng)求大量?jī)?nèi)存可能導(dǎo)致崩潰。Dalvik linearAlloc是一個(gè)固定大小的緩沖區(qū)。在應(yīng)用的安裝過(guò)程中，系統(tǒng)會(huì)運(yùn)行一個(gè)名為dexopt的程序?yàn)樵搼?yīng)用在當(dāng)前機(jī)型中運(yùn)行做準(zhǔn)備。dexopt使用LinearAlloc來(lái)存儲(chǔ)應(yīng)用的方法信息。Android 2.2和2.3的緩沖區(qū)只有5MB，Android 4.x提高到了8MB或16MB。當(dāng)方法數(shù)量過(guò)多導(dǎo)致超出緩沖區(qū)大小時(shí)，會(huì)造成dexopt崩潰。

-Multidex構(gòu)建工具還不支持指定哪些類必須包含在首個(gè)DEX文件中，因此可能會(huì)導(dǎo)致某些類庫(kù)（例如某個(gè)類庫(kù)需要從原生代碼訪問(wèn)Java代碼）無(wú)法使用。

4.對(duì)開(kāi)發(fā)者的建議

開(kāi)發(fā)者應(yīng)該避免使用Google Guava這樣的類庫(kù)，它包含了13000多個(gè)方法。

盡量使用專為移動(dòng)應(yīng)用設(shè)計(jì)的Lite/Android版本類庫(kù)，或者使用小類庫(kù)替換大類庫(kù)，例如用Google-gson替換Jackson JSON。而對(duì)于Google Protocol Buffers這樣的數(shù)據(jù)交換格式，其標(biāo)準(zhǔn)實(shí)現(xiàn)會(huì)自動(dòng)生成大量的方法。采用Square Wire的實(shí)現(xiàn)則可以很好地解決此問(wèn)題。

在出現(xiàn)應(yīng)用分包后低版本手機(jī)無(wú)法使用，高版本正常使用的問(wèn)題時(shí)，可以考慮檢查一下分包的配置是否正確。

總結(jié)

以上就是本文關(guān)于Android分包MultiDex策略詳解的全部?jī)?nèi)容，希望對(duì)大家有所幫助。感興趣的朋友可以繼續(xù)參閱本站其他相關(guān)內(nèi)容，如有不足之處，歡迎留言指出。

您可能感興趣的文章: