在Android專案開發中，尤其是開發類似淘寶，京東，微信，直播等大型專案中，由於產品的迭代，業務模組的快速增長，到了一定的規模後難免會遇到65536/64K方法數的問題。

它是個什麼鬼？

這個問題，網上還有其他人說65方法數問題，本質上都市指Android Dalvik可執行檔案.dex中的Java方法數引用超過65536，64K的計算方法是65536/1024，65K的計算方法是65536/1000，Android的官方說法就是64K這種說法。

也就是說64K方法數問題就是在構建APP的時候出現編譯，導致構建的失敗。同時，在舊版本和新版本的構建系統中提示也會不一樣。臥槽，我們不一樣。。。。

舊版本錯誤提示

com.android.dex.DexIndexOverflowException:method IDnotin[0,0xffff]:65536

新版本錯誤提示

trouble weriting output:
Too many field references:131000;max is 65536.
You may try using --multi-dex option

64K限制的原因

Android APK 檔案本質上是一個壓縮的檔案，它的裡面包含的classes.dex檔案是可執行Dalvik檔案，這個.dex檔案中存放的是所有便宜後的java程式碼。Dalvik可執行檔案規範限制了單個,dex檔案最多能夠引用的方法數是65536個，這其中包含了Android Framework、APP引用的第三方函式庫以及APP自身的方法。

使用MultiDex解決問題

、

Android5.0版本之前

在Android5.0(API 21)前，系統使用的是Dalvik虛擬機器來執行Android 應用，預設情況下，Dalvik為每個APK只生成一個classes.dex檔案，為了規避單個.dex檔案方法數超過64k的問題，我們需要拆分這個單一的classes.dex檔案，拆分後可能存在類似於classes.dex、classes2.dex、classes3.dex等多個.dex檔案，具體多小個需要看開發者的配置以及應用的方法總數。在啟動應用時，會先載入classes.dex檔案，我們叫做主的.dex檔案，應用在啟動後時才會依次載入其他.dex檔案，這些叫做從
的.dex檔案。

為了規避這些問題，Google推出了一個名為MultiDex Support Library的函式庫，當我們下載了Android Support Libraries之後，可以在SDK/extra/android/support/multidex/目錄中找到這個函式庫。

Android5.0之後版本

Android5.0 之後開始，Android使用名為ART的虛擬機器來代替Dalvik虛擬機器，ART天然支援從APK中間中載入多個.dex檔案，在應用安裝親戚間，它會執行一個預編譯操作，scanAPK中所有classes.dex檔案並將他們以便宜成一個單一的.oat檔案,在引用執行時去載入這個.oat檔案，而不是一個一個的載入.dex檔案。

如何避免出現64K限制

1，有效減少方法數，避免使用降低效能的MultiDex Support Library。

如何減少方法數

1，減少使用第三方函式庫，儘量避免使用。
2，使用Proguard移除無用程式碼：配置並在Release版本中使用Proguard,它的壓縮功能通過分析位元組碼，能夠檢測並且一處沒有使用到的類、欄位、方法和屬性。

如何配置MultiDex

最後實在是沒辦法了，來吧。配一配解決問題。
Android 的Gradle外掛在Android Build Tool21.1 就支援使用MultiDex了。

首先配置APP module的build.gradle檔案

defaultConfig {
      multiDexEnabled true
}

android-support-multidex.jar
或者
compile 'com.android.support:multidex'

引入MultiDexApplication

如果自身有BaseAppcation就直接繼承MultiDexApplication。

如何應用已經有自定義Appcation類，而且你不想或者不能修改它的弗雷，那麼也可以通過腹瀉attachBaseContext方法並初始化MultiDex。
因為attachBaseContext是在oncreate之前執行的。是應用最早執行的方法。

在此，使用MultiDex Support Library會有一些損耗，必須進行一下優化，請看下編博文之談。

如果對您有幫助，請點贊，留言，頂了