以下參考自官方文檔配置方法數超過 64K 的應用
隨着 Android 平台的持續成長，Android 應用的大小也在增加。當您的應用及其引用的庫達到特定大小時，您會遇到構建錯誤，指明您的應用已達到 Android 應用構建架構的極限。早期版本的構建系統按如下方式報告這一錯誤：
Conversion to Dalvik format failed: Unable to execute dex: method ID not in [0, 0xffff]: 65536較新版本的 Android 構建系統雖然顯示的錯誤不同，但指示的是同一問題：
trouble writing output:
Too many field references: 131000; max is 65536. You may try using --multi-dex option.這些錯誤狀況都會顯示下面這個數字：65,536。這個數字很重要，因為它代表的是單個 Dalvik Executable (DEX) 字節碼文件內的代碼可調用的引用總數。本頁介紹如何通過啟用被稱為 Dalvik 可執行文件分包的應用配置來越過這一限制，使您的應用能夠構建並讀取 Dalvik 可執行文件分包 DEX 文件。
關於 64K 引用限制
Android 應用 (APK) 文件包含 Dalvik Executable (DEX) 文件形式的可執行字節碼文件，其中包含用來運行您的應用的已編譯代碼。Dalvik Executable 規范將可在單個 DEX 文件內可引用的方法總數限制在 65,536，其中包括 Android 框架方法、庫方法以及您自己代碼中的方法。在計算機科學領域內，術語千（簡稱 K）表示 1024（或 2^10）。由於 65,536 等於 64 X 1024，因此這一限制也稱為“64K 引用限制”。
Android 5.0 之前版本的 Dalvik 可執行文件分包支持
Android 5.0（API 級別 21）之前的平台版本使用 Dalvik 運行時來執行應用代碼。默認情況下，Dalvik 限制應用的每個 APK 只能使用單個 classes.dex
字節碼文件。要想繞過這一限制，您可以使用 Dalvik 可執行文件分包支持庫，它會成為您的應用主要 DEX 文件的一部分，然后管理對其他 DEX 文件及其所包含代碼的訪問。
注：如果您的項目配置時所面向的 Dalvik 可執行文件分包使用的是 minSdkVersion 20
或更低版本，並且您將其部署到運行 Android 4.4（API 級別 20）或更低版本的目標設備上，則 Android Studio 會停用 Instant Run。
Android 5.0 及更高版本的 Dalvik 可執行文件分包支持
Android 5.0（API 級別 21）及更高版本使用名為 ART 的運行時，后者原生支持從 APK 文件加載多個 DEX 文件。ART 在應用安裝時執行預編譯，掃描classesN.dex 文件，並將它們編譯成單個 .oat 文件，供 Android 設備執行。因此，如果您的 minSdkVersion 為 21 或更高值，則不需要 Dalvik 可執行文件分包支持庫。
如需了解有關 Android 5.0 運行時的詳細信息，請參閱 ART 和 Dalvik。
注：如果將應用的 minSdkVersion
設置為 21 或更高值，使用 Instant Run 時，Android Studio 會自動將應用配置為進行 Dalvik 可執行文件分包。由於 Instant Run 僅適用於調試版本的應用，您仍需配置發布構建進行 Dalvik 可執行文件分包，以規避 64K 限制。
規避 64K 限制
在將您的應用配置為支持使用 64K 或更多方法引用之前，您應該采取措施減少應用代碼調用的引用總數，包括由您的應用代碼或包含的庫定義的方法。下列策略可幫助您避免達到 DEX 引用限制：
檢查您的應用的直接和傳遞依賴項 - 確保您在應用中使用任何龐大依賴庫所帶來的好處大於為應用添加大量代碼所帶來的弊端。一種常見的反面模式是，僅僅為了使用幾個實用方法就在應用中加入非常龐大的庫。減少您的應用代碼依賴項往往能夠幫助您規避 dex 引用限制。
通過 ProGuard 移除未使用的代碼 - 為您的版本構建啟用代碼壓縮以運行 ProGuard。啟用壓縮可確保您交付的 APK 不含有未使用的代碼。
使用這些技巧使您不必在應用中啟用 Dalvik 可執行文件分包，同時還會減小 APK 的總體大小。
配置您的應用進行 Dalvik 可執行文件分包
將您的應用項目設置為使用 Dalvik 可執行文件分包配置需要對您的應用項目進行以下修改，具體取決於應用支持的最低 Android 版本。
如果您的 minSdkVersion 設置為 21 或更高值，您只需在模塊級 build.gradle 文件中將 multiDexEnabled
設置為 true，如此處所示：
android {
defaultConfig {
... minSdkVersion 21 targetSdkVersion 25 multiDexEnabled true } ... }但是，如果您的 minSdkVersion 設置為 20 或更低值，則您必須按如下方式使用 Dalvik 可執行文件分包支持庫：
-修改模塊級 build.gradle 文件以啟用 Dalvik 可執行文件分包，並將 Dalvik 可執行文件分包庫添加為依賴項，如此處所示：
android { defaultConfig { ... minSdkVersion 15 targetSdkVersion 25 multiDexEnabled true } ...}dependencies { compile 'com.android.support:multidex:1.0.1'}
- 根據是否要替換 Application 類，執行以下操作之一：如果您沒有替換 Application類，請編輯清單文件，按如下方式設置 <application> 標記中的 android:name：
<?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.example.myapp"> <application android:name="android.support.multidex.MultiDexApplication" > ... </application> </manifest> - 如果您替換了 Application 類，請按如下方式對其進行更改以擴展 MultiDexApplication（如果可能）：
public class MyApplication extends MultiDexApplication { ... }
或者，如果您替換了 Application 類，但無法更改基本類，則可以改為替換 attachBaseContext() 方法並調用 MultiDex.install(this) 來啟用 Dalvik 可執行文件分包：
public class MyApplication extends SomeOtherApplication { @Override protected void attachBaseContext(Context base) { super.attachBaseContext(context); Multidex.install(this); } }構建應用后，Android 構建工具會根據需要構建主 DEX 文件 (classes.dex) 和輔助 DEX 文件（classes2.dex
和 classes3.dex 等）。然后，構建系統會將所有 DEX 文件打包到您的 APK 中。
運行時，Dalvik 可執行文件分包 API 使用特殊的類加載器來搜索適用於您的方法的所有 DEX 文件（而不是僅在主 classes.dex 文件中搜索）。
Dalvik 可執行文件分包支持庫的局限性
Dalvik 可執行文件分包支持庫具有一些已知的局限性，將其納入您的應用構建配置之中時，您應該注意這些局限性並進行針對性的測試：
- 啟動期間在設備數據分區中安裝 DEX 文件的過程相當復雜，如果輔助 DEX 文件較大，可能會導致應用無響應 (ANR) 錯誤。在此情況下，您應該通過 ProGuard 應用代碼壓縮以盡量減小 DEX 文件的大小，並移除未使用的那部分代碼。
- 由於存在 Dalvik linearAlloc 錯誤（問題 22586），使用 Dalvik 可執行文件分包的應用可能無法在運行的平台版本早於 Android 4.0（API 級別 14）的設備上啟動。如果您的目標 API 級別低於 14，請務必針對這些版本的平台進行測試，因為您的應用可能會在啟動時或加載特定類群時出現問題。代碼壓縮可以減少甚至有可能消除這些潛在問題。
- 由於存在 Dalvik linearAlloc 限制（問題 78035），因此，如果使用 Dalvik 可執行文件分包配置的應用發出非常龐大的內存分配請求，則可能會在運行期間發生崩潰。盡管 Android 4.0（API 級別 14）提高了分配限制，但在 Android 5.0（API 級別 21）之前的 Android 版本上，應用仍有可能遭遇這一限制。
聲明主 DEX 文件中需要的類
為 Dalvik 可執行文件分包構建每個 DEX 文件時，構建工具會執行復雜的決策制定來確定主要 DEX 文件中需要的類，以便應用能夠成功啟動。如果啟動期間需要的任何類未在主 DEX 文件中提供，那么您的應用將崩潰並出現錯誤 java.lang.NoClassDefFoundError。
該情況不應出現在直接從應用代碼訪問的代碼上，因為構建工具能識別這些代碼路徑，但可能在代碼路徑可見性較低（如使用的庫具有復雜的依賴項）時出現。例如，如果代碼使用自檢機制或從原生代碼調用 Java 方法，那么這些類可能不會被識別為主 DEX 文件中的必需項。
因此，如果您收到 java.lang.NoClassDefFoundError，則必須使用構建類型中的 multiDexKeepFile 或 multiDexKeepProguard 屬性聲明它們，以手動將這些其他類指定為主 DEX 文件中的必需項。如果類在 multiDexKeepFile 或 multiDexKeepProguard 文件中匹配，則該類會添加至主 DEX 文件。
multiDexKeepFile 屬性
您在 multiDexKeepFile 中指定的文件應該每行包含一個類，並且采用 com/example/MyClass.class
的格式。例如，您可以創建一個名為 multidex-config.txt 的文件，如下所示：
com/example/MyClass.class com/example/MyOtherClass.class然后，您可以按以下方式針對構建類型聲明該文件：
android { buildTypes { release { multiDexKeepFile file 'multidex-config.txt' ... } } }請記住，Gradle 會讀取相對於 build.gradle 文件的路徑，因此如果 multidex-config.txt 與 build.gradle 文件在同一目錄中，以上示例將有效。
multiDexKeepProguard 屬性
multiDexKeepProguard 文件使用與 Proguard 相同的格式，並且支持整個 Proguard 語法。如需了解有關 Proguard 格式和語法的詳細信息，請參閱 Proguard 手冊中的 Keep Options 一節。
您在 multiDexKeepProguard 中指定的文件應該在任何有效的 ProGuard 語法中包含 -keep 選項。例如，-keep com.example.MyClass.class。您可以創建一個名為 multidex-config.pro 的文件，如下所示：
-keep class com.example.MyClass-keep class com.example.MyClassToo如果您想要指定包中的所有類，文件將如下所示：
-keep class com.example.** { *; } // All classes in the com.example package然后，您可以按以下方式針對構建類型聲明該文件：
android { buildTypes { release { multiDexKeepProguard 'multidex-config.pro' ... } } }優化開發構建中的 Dalvik 可執行文件分包
Dalvik 可執行文件分包配置會大幅增加構建處理時間，因為構建系統必須就哪些類必須包括在主 DEX 文件中以及哪些類可以包括在輔助 DEX 文件中作出復雜的決策。這意味着使用 Dalvik 可執行文件分包的增量式構建通常耗時更長，可能會拖慢您的開發進度。
為了縮短耗時更長的 Dalvik 可執行文件分包輸出構建時間，請利用 productFlavors （一個開發定制和一個發布定制，具有不同的 minSdkVersion 值）創建兩個構建變型。
對於開發定制，將 minSdkVersion 設置為 21。該設置將啟用一個名為 pre-dexing 的構建功能，此功能使用僅適用於 Android 5.0（API 級別 21）和更高版本的 ART 格式更快生成 Dalvik 可執行文件分包輸出。對於發布定制，將 minSdkVersion 設置為適於您的實際最低支持級別。此設置生成的 Dalvik 可執行文件分包 APK 可兼容更多設備，但構建時間更長。
以下構建配置示例展示了如何在 Gradle 構建文件中設置這些定制：
android {
defaultConfig {
...
multiDexEnabled true } productFlavors { dev { // Enable pre-dexing to produce an APK that can be tested on // Android 5.0+ without the time-consuming DEX build processes. minSdkVersion 21 } prod { // The actual minSdkVersion for the production version. minSdkVersion 14 } } buildTypes { release { minifyEnabled true proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' } } } dependencies { compile 'com.android.support:multidex:1.0.1' }您完成此配置變更后，可以為增量式構建使用應用的 devDebug 變體，后者集 dev 產品定制與 debug
構建類型的屬性於一身。這將創建已啟用 Dalvik 可執行文件分包且禁用 proguard 的可調試應用（因為 minifyEnabled 默認為 false）。這些設置會使適用於 Gradle 的 Android 插件執行以下操作：
- 執行 pre-dexing：將每個應用模塊和每個依賴項構建為單獨的 DEX 文件。
- 將每個 DEX 文件加入 APK，並且不做任何修改（不執行代碼壓縮）。
- 最重要的是，模塊 DEX 文件不執行合並操作，因此可以避免為確定主 DEX 文件的內容而進行長時間的計算。
這些設置的好處是，可以進行快速的增量式構建，因為只有修改過的模塊的 DEX 文件才會在后續構建期間重新計算並重新打包。但是，這些構建的 APK 只能用於在 Android 5.0 設備上進行測試。不過，由於是以定制形式實現配置，您保留了使用與發布相適的最低 API 級別和 ProGuard 代碼壓縮執行正常構建的能力。
您還可以構建其他變體，包括 prodDebug 變體構建，該變體雖然構建時間更長，但可用於開發以外的測試。在所示配置內，prodRelease 變體將是最終測試和發布版本。如需了解有關使用構建變體的詳細信息，請參閱配置構建變體。
提示：由於您有適用於不同 Dalvik 可執行文件分包需求的不同構建變體，因此也可以為不同變體提供不同清單文件（這樣，只有適用於 API 級別 20 和更低版本的清單文件會更改 <application> 標記名稱），或者為每個變體創建不同的 Application 子類（這樣，只有適用於 API 級別 20 和更低版本的清單文件會擴展 MultiDexApplication 類或調用 MultiDex.install(this) ）。
測試 Dalvik 可執行文件分包應用
編寫面向 Dalvik 可執行文件分包應用的儀器測試時，無需進行其他配置。AndroidJUnitRunner
直接支持 Dalvik 可執行文件分包，前提是您使用MultiDexApplication 或替換您的自定義 Application
對象中的 attachBaseContext() 方法，並調用 MultiDex.install(this) 以啟用 Dalvik 可執行文件分包。
或者，您可以替換 AndroidJUnitRunner 中的 onCreate() 方法：
public void onCreate(Bundle arguments) { MultiDex.install(getTargetContext()); super.onCreate(arguments); ... }注：目前不支持使用 Dalvik 可執行文件分包來創建測試 APK。
模擬65K問題
在一個文件中輸出65535個方法，拷貝到項目中的一個Class(Methods.java)。
結果報出編譯異常:
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在module的build.gradle加入配置:
android {
defaultConfig {
// Enabling multidex support. multiDexEnabled true } } dependencies { compile 'com.android.support:multidex:1.0.1' }此時編譯通過了。
統計APK的方法數和字段數
在根目錄的build.gradle中配置:
buildscript { repositories { jcenter() } dependencies { classpath 'com.getkeepsafe.dexcount:dexcount-gradle-plugin:0.3.0' } }在module(默認app目錄)下的build.gradle配置:
apply plugin: 'com.getkeepsafe.dexcount'測試結果
編譯時設置最小api14::minSdkVersion 14
因為未用proguard對未使用的方法優化，build apk后可以統計總的方法和子段數：
Total methods in testapplication-release-unsigned.apk: 82585 Total fields in testapplication-release-unsigned.apk: 7745可見已超過上限65535。
分析APK包：總計生成了3個dex。
官方文檔中提到：
Android 5.0（API 級別 21）及更高版本使用名為 ART 的運行時，后者原生支持從 APK 文件加載多個 DEX 文件。ART 在應用安裝時執行預編譯，掃描classesN.dex 文件，並將它們編譯成單個 .oat 文件，供 Android 設備執行。因此，如果您的 minSdkVersion 為 21 或更高值，則不需要 Dalvik 可執行文件分包支持庫。
如果將最小支持的api改為21（Android 5.0）:minSdkVersion 21
則不需要添加:
dependencies { compile 'com.android.support:multidex:1.0.1' }並且在生成的apk包里看到不止一個dex，在我試驗的項目一共生成了18個dex。這些dex由Android ART虛擬機原生支持編譯成單個oat文件供Android設備執行。
如果你的項目最少支持API14，還是老老實實添加'com.android.support:multidex:1.0.1',並且在Application中執行MultiDex的install方法動態加載多個dex。
Application的靜態塊和靜態變量導致的ClassNotFoundError
參考《深入理解Java虛擬機》，一個類被加載驗證后，首先進入准備階段，即類變量和靜態代碼塊會合並成<clinit>()方法優先於構造方法執行。
如果生成的classes.dex中不包含靜態代碼塊引用的類則必然會報錯。
所幸的是在我使用的Android2.2.2環境，顯示的調用類或者通過Java反射技術得到類，都會在編譯階段被識別，可以在module的build/intermediates/multi-dex/release(debug)/maindexlist.txt中找到Methods.class類的全限定名。據了解早期的AS未做此優化。
在Native層通過JNIEnv* 的FindClass得到一個類，此時AS未正確將Methods.class編譯到主DEX，拋出了ClassNotFoundError。在module的build/intermediates/multi-dex/release(debug)/maindexlist.txt果然也未找到該類。因此還是需要我們參考官方文檔的配置方法，將需要的類編譯進主DEX中。
至於Android 5.0以上，由於虛擬機的優化，即使不通過MultiDex的install()方法，默認也會加載APK的多個DEX，因此如果你設置的最小適配API是21，就不需要考慮這個問題了。
MultiDex加載多DEX原理
參考MultiDex與熱修復實現原理
MultiDex在Application的attachBaseContext()函數階段通過Java反射技術替換掉默認的BaseDexClassLoader中DexPathList中的Element[]dexElements數組。