咱們在Android開發中,會不斷的在App代碼裏面增長新功能,引入新的類庫,若是不加控制的話,那麼會碰到編輯器IDE爆出一下錯誤:html
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文件解決。java
defaultConfig { applicationId "XXX" minSdkVersion 14 targetSdkVersion 23 multiDexEnabled true } ....... dependencies { compile 'com.android.support:multidex:1.0.0' }
@Override protected void attachBaseContext(Context base) { super.attachBaseContext(base); MultiDex.install(this); }
配置好相關方法後,必須Clean或者Rebuild下項目,不然可能看到的仍是存在問題的現象。android
通過以上的配置,你的應用已經能夠實現多個DEX文件了。當應用構建時,構建工具會分析哪些類必須放在第一個DEX文件,哪些類能夠放在附加的DEX文件中。當它建立了第一個DEX文件後,若是有必要會繼續建立附加的DEX文件,如classes2.dex, classes3.dex。Multidex的支持類庫將被包含在應用的第一個DEX文件中,幫助實現對其它DEX文件的訪問。api
雖然Google解決了應用總方法數限制的問題,但並不意味着開發者能夠任意擴大項目規模。Multidex仍有一些限制:app
- 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代碼)沒法使用。
- 開發者應該避免使用Google Guava這樣的類庫,它包含了13000多個方法。
- 儘可能使用專爲移動應用設計的Lite/Android版本類庫,或者使用小類庫替換大類庫,例如用Google-gson替換Jackson JSON。而對於Google Protocol Buffers這樣的數據交換格式,其標準實現會自動生成大量的方法。採用Square Wire的實現則能夠很好地解決此問題。
- 在出現應用分包後低版本手機沒法使用,高版本正常使用的問題時,能夠考慮檢查一下分包的配置是否正確。