近日镜沽，Android Developers在Google+上宣布了新的Multidex支持庫，為方法總數(shù)超過65K的Android應用提供了官方支持桨吊。
如果你是一名幸運的Android應用開發(fā)者威根，正在開發(fā)一個前景廣闊的應用，不斷地加入新功能视乐、添加新的類庫洛搀，那么終有一天，你會不幸遇到這個錯誤：
Conversion to Dalvik format failed: Unable to execute dex: method ID not in [0, 0xffff]: 65536
這個錯誤是Android應用的方法總數(shù)限制造成的佑淀。Android平臺的Java虛擬機Dalvik在執(zhí)行DEX格式的Java應用程序時留美，使用原生類型short來索引DEX文件中的方法。這意味著單個DEX文件可被引用的方法總數(shù)被限制為65536。通常APK包含一個classes.dex文件独榴，因此Android應用的方法總數(shù)不能超過這個數(shù)量僧叉，這包括Android框架、類庫和你自己開發(fā)的代碼棺榔。
這個問題可以通過將一個DEX文件分拆成多個DEX文件解決瓶堕。Facebook介紹了為Android應用開發(fā)的Dalvik補丁；Android Developers博客介紹了通過自定義類加載過程的方法來解決此問題症歇。但這些方法有些復雜而且并不優(yōu)雅郎笆。
隨著新的MultiDex支持庫發(fā)布，Google正式為解決此問題提供官方支持忘晤。構建超過65K方法數(shù)的應用介紹了如何使用Gradle構建多DEX應用宛蚓。
首先使用Android SDK Manager升級到最新的Android SDK Build Tools和Android Support Library R21。然后進行以下兩步操作：
1.修改Gradle配置文件设塔，啟用MultiDex并包含MultiDex支持：
android { compileSdkVersion 21 buildToolsVersion "21.1.0"defaultConfig { ... minSdkVersion 14 targetSdkVersion 21 ... // Enabling multidex support. multiDexEnabled true}...}dependencies { compile 'com.android.support:multidex:1.0.0' }
2.讓應用支持多DEX文件凄吏。在MultiDexApplication JavaDoc中描述了三種可選方法：
在AndroidManifest.xml的application中聲明android.support.multidex.MultiDexApplication；
如果你已經(jīng)有自己的Application類闰蛔，讓其繼承MultiDexApplication痕钢；
如果你的Application類已經(jīng)繼承自其它類，你不想/能修改它序六，那么可以重寫attachBaseContext()方法：
@Override protected void attachBaseContext(Context base) { super.attachBaseContext(base); MultiDex.install(this);}
經(jīng)過以上步驟任连，你的應用已經(jīng)可以實現(xiàn)多個DEX文件了。當應用構建時例诀，構建工具會分析哪些類必須放在第一個DEX文件随抠，哪些類可以放在附加的DEX文件中。當它創(chuàng)建了第一個DEX文件（classes.dex）后繁涂，如果有必要會繼續(xù)創(chuàng)建附加的DEX文件拱她，如classes2.dex, classes3.dex。Multidex的支持類庫將被包含在應用的第一個DEX文件中扔罪，幫助實現(xiàn)對其它DEX文件的訪問秉沼。
文中還介紹了在開發(fā)多DEX應用時，通過設置productFlavors提高開發(fā)效率以及多DEX應用的測試方法步势。
Android 5.0和更高版本使用名為ART的運行時氧猬，它原生支持從APK文件加載多個DEX文件。在應用安裝時坏瘩，它會執(zhí)行預編譯盅抚，掃描classes(..N).dex文件然后將其編譯成單個.oat文件用于執(zhí)行。了解更多關于ART的信息倔矾。
雖然Google解決了應用總方法數(shù)限制的問題妄均，但并不意味著開發(fā)者可以任意擴大項目規(guī)模柱锹。Multidex仍有一些限制：
DEX文件安裝到設備的過程非常復雜，如果第二個DEX文件太大丰包，可能導致應用無響應禁熏。此時應該使用ProGuard減小DEX文件的大小。
由于Dalvik linearAlloc的Bug邑彪，應用可能無法在Android 4.0之前的版本啟動瞧毙，如果你的應用要支持這些版本就要多執(zhí)行測試。
同樣因為Dalvik linearAlloc的限制寄症，如果請求大量內(nèi)存可能導致崩潰宙彪。Dalvik linearAlloc是一個固定大小的緩沖區(qū)。在應用的安裝過程中有巧，系統(tǒng)會運行一個名為dexopt的程序為該應用在當前機型中運行做準備释漆。dexopt使用LinearAlloc來存儲應用的方法信息。Android 2.2和2.3的緩沖區(qū)只有5MB篮迎，Android 4.x提高到了8MB或16MB男图。當方法數(shù)量過多導致超出緩沖區(qū)大小時，會造成dexopt崩潰甜橱。
Multidex構建工具還不支持指定哪些類必須包含在首個DEX文件中逊笆，因此可能會導致某些類庫（例如某個類庫需要從原生代碼訪問Java代碼）無法使用。
避免應用過大渗鬼、方法過多仍然是Android開發(fā)者要注意的問題览露。Mihai Parparita的開源項目dex-method-counts可以用于統(tǒng)計APK中每個包的方法數(shù)量荧琼。
通常開發(fā)者自己的代碼很難達到這樣的方法數(shù)量限制譬胎，但隨著第三方類庫的加入，方法數(shù)就會迅速膨脹命锄。因此選擇合適的類庫對Android開發(fā)者來說尤為重要堰乔。
開發(fā)者應該避免使用Google Guava這樣的類庫，它包含了13000多個方法脐恩。盡量使用專為移動應用設計的Lite/Android版本類庫镐侯，或者使用小類庫替換大類庫，例如用Google-gson替換Jackson JSON驶冒。而對于Google Protocol Buffers這樣的數(shù)據(jù)交換格式苟翻，其標準實現(xiàn)會自動生成大量的方法。采用Square Wire的實現(xiàn)則可以很好地解決此問題骗污。
