標籤:
AndroidStudio利用android-support-multidex解決65536問題64k問題
著作權聲明:轉載請註明本文轉自嚴振傑的部落格: http://blog.csdn.net/yanzhenjie1003
64k的各種異常
Error:The number of method references in a .dex file cannot exceed 64K.
Learn how to resolve this issue at https://developer.android.com/tools/building/multidex.html
或者
finished with non-zero exit value 2
當你的應用程式和庫引用達到一定規模,你遇到構建錯誤顯示你的應用已經達到了一個Android應用程式構建體繫結構的限制。早期版本的構建系統報告這個錯誤如下:
Conversion to Dalvik format failed:Unable to execute dex: method ID not in [0, 0xffff]: 65536
或者
UNEXPECTED TOP-LEVEL EXCEPTION: java.lang.IllegalArgumentException: method ID not in [0, 0xffff]: 65536 at com.android.dx.merge.DexMerger$6.updateIndex(DexMerger.java:501) at com.android.dx.merge.DexMerger$IdMerger.mergeSorted(DexMerger.java:282) at com.android.dx.merge.DexMerger.mergeMethodIds(DexMerger.java:490) at com.android.dx.merge.DexMerger.mergeDexes(DexMerger.java:167) at com.android.dx.merge.DexMerger.merge(DexMerger.java:188) at com.android.dx.command.dexer.Main.mergeLibraryDexBuffers(Main.java:439) at com.android.dx.command.dexer.Main.runMonoDex(Main.java:287) at com.android.dx.command.dexer.Main.run(Main.java:230) at com.android.dx.command.dexer.Main.main(Main.java:199) at com.android.dx.command.Main.main(Main.java:103)
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
最新版本的Android構建系統顯示一個不同的錯誤,但是是同樣一個問題:
trouble writing output:Too many field references: 131000; max is 65536.You may try using --multi-dex option.
或者
Error:The number of method references in a .dex file cannot exceed 64K.
上面的錯誤顯示一個共同的數字:65536。這個數字是重要的,它代表了引用的總數,可以在單個調用的代碼Dalvik可執行(Dex)位元組碼檔案。如果你的Android應用發生這個錯誤,恭喜你,你的代碼已經達到了一定的量!本文解釋了如何解決這個限制並繼續構建應用程式。
關於64 k引用限制
Android應用程式(APK)在Dalvik可執行檔的形式包含可執行檔位元組碼檔案(DEX)檔案,其中包含已編譯的代碼來運行你的應用程式。Dalvik可執行規格限制一個Dex檔案包含65536個方法:包括Android架構方法、Library方法的總數、和你自己的代碼方法總數。因為65536等於64×1024,這一限制被稱為“64k引用限制”。
這個極限就要求我們配置應用程式的構建過程,需要產生多個DEX檔案,所以稱為multidex 配置。
分析原因與注意事項
解決方案分Android 5.0及以上系統和5.0以下系統怎麼做。客官們不要著急,先看我一個個分析原因,畢竟我要裝下逼哈哈。
一、Android 5.0以下的版本
Android 5.0(API leve 21)之前的系統使用Dalvik執行應用程式代碼。預設情況下,Dalvik限制一個apk只有一個Dex檔案。為了繞過這個限制, 我們可以使用multidex support library,它成為我們APK的主要DEX檔案的一部分,負責管理我們APK訪問其他DEX檔案和代碼。
注意: 如果咱的項目minSdkVersion是20或更低,運行到Android 4.4(API leve 20)或者更低版本的裝置上時需要禁用AndroidStudio的即時運行
二、Android 5.0和更高版本
Android 5.0(API leve 21)和更高的系統使用runtime是ART ,原生支援從應用的apk檔案載入多個DEX檔案。ART在安裝應用時先行編譯應用程式,會掃描多個classes(..N).dex檔案編譯成一個.oat的檔案。更多Android5.0 runtime的更多資訊,請參見即時運行-instant-run。
注意: 如果你使用即時運行 , AndroidStudio自動設定你的應用程式,你應用程式的minSdkVersion應該設定為21或更高。因為即時只工作在你APP的Debug版本,你任然需要配置你的release版本構建時用multidex避免64k的限制。
盡量避免64k限制
在配置我們的App啟用64k或者更多方法引用之前,我們可以減少應用代碼內的調度總數,包括我們自身應用的方法和第三方的庫,下面的幾個策略或許可以幫到你:
- 檢查你的APP的直接和間接的過度依賴關係:有時候我們用到某個Libaray的某幾個方法或者功能時這個庫非常大,減少這種依賴可能對與避免64k的問題非常有效。
- 在正式打包構建的時候,使用代碼混淆器ProGuard混淆移除未使用的代碼,也就是不把沒有使用的代碼打包到我們的apk中。
使用上面的方法可以協助我們避免在應用程式中產生太多無用的方法和減小我們apk的大小,這對於用自己伺服器做app更新升級的同學是非常有協助的。
這裡給大家推薦下任玉剛同學的外掛程式式開發架構:https://github.com/singwhatiwanna/dynamic-load-apk,共同參與開發人員:田嘯,宋思宇。
解決64k問題
在Android SDK Build Tools 21.1或者更高版本的build工具中用Android plugin gradle。確保你更新Android SDK build tools和Android support到最新版本,然後用multidex配置應用程式。我們必須要做兩步。
第一步,修改主module的build.gradle檔案
在gradle中依賴multidex,並啟用multiDexEnable:
android { compileSdkVersion 21 buildToolsVersion defaultConfig { ... minSdkVersion 14 targetSdkVersion 21 ... // Enabling multidex support. multiDexEnabled true } ...}dependencies { compile ‘com.android.support:multidex:1.0.1‘}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
第二步,繼承
android.support.multidex.MultiDexApplication類兩種情況
第一種情況,如果我們的APP沒有重寫過Application類,我們直接繼承MultiDexApplication,然後在manifest.xml中註冊Application即可。
第二種情況,如果我們已經重寫過Application類,重寫attachBaseContext(Context)方法,並調用MultiDex.install(this);即可:
protected void attachBaseContext(Context base) {super.attachBaseContext(base);MultiDex.install(this);
因為我翻過MultiDexApplication的源碼了,裡面就是重寫了這個方法而已哈哈:
public class MultiDexApplication extends Application { public MultiDexApplication() { } protected void attachBaseContext(Context base) { super.attachBaseContext(base); MultiDex.install(this); }}
註冊Application
<?xml version= encoding=?><manifest xmlns:android= package=> <application ... android:name="剛才重寫的Application全類名"> ... </application></manifest>
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代碼)無法使用。
使用了multidex後的構建最佳化
一、因此如果應用中包含lirary工程,可能會發生如下錯誤:
UNEXPECTED TOP-LEVEL EXCEPTION: com.android.dex.DexException: Library dex files are not supported in multi-dex mode
這個時候我們需要禁用先行編譯:
android { ... dexOptions { preDexLibraries = false } ...}
二、如果在啟動並執行時候遇到如下錯誤:
UNEXPECTED TOP-LEVEL ERROR: java.lang.OutOfMemoryError: Java heap space
我們需要加大java堆記憶體大小:
maxProcessCount 4 // this is the default valuejavaMaxHeapSize "2g"
三、提升運行速度
在Android leve 21或者更高SDK版本。使用ART-supported格式產生multidex輸出更快,為我們節省時間,所以我們不必在調試的使用也相容到5.0以下,所以我們配置最低版本的時候做個如下相容:
android { productFlavors { // 自訂喜好設定. dev { // 在Android leve 21或更高版本編譯更快 minSdkVersion 21 } prod { // 真正的生產環境. minSdkVersion 14 } } ...}dependencies { compile ‘com.android.support:multidex:1.0.1‘}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
Android plugin Gradle版本低於1.1怎麼辦
你需要添加 以下依賴 multidex-instrumentation :
dependencies { androidTestCompile(‘com.android.support:multidex-instrumentation:1.0.1‘) { exclude group: ‘com.android.support‘, module: ‘multidex‘ }}
Eclipse Jar包下載:http://download.csdn.net/detail/yanzhenjie1003/9566518
官方參考文檔:https://developer.android.com/tools/building/multidex.html
AndroidStudio利用android-support-multidex解決65536問題64k問題