一. 前景
随着Android平台的持續成長，Android應用的大小也在增加。當應用及其引用的庫達到特定大小時，會遇到建構錯誤，指明你的應用已達到Android應用建構架構的極限。一般情況下，你會獲得類似的錯誤資訊：
Dex: The number of method references in a .dex file cannot exceed 64K.
com.android.dex.DexIndexOverflowException: method ID not in [0, 0xffff]: 65536
二. MultiDex
2.1. 官方方案
Dex檔案64K方法數的限制已經被提及過很多次，Android官方也提供了MultiDex來解決這一問題。
2.2. 局限性
官方文檔中也指出了MultiDex的局限性：
啟動期間在裝置資料分區中安裝 DEX 檔案的過程相當複雜，如果輔助 DEX 檔案較大，可能會導緻應用無響應 (ANR) 錯誤。在此情況下，您應該通過 ProGuard 應用代碼壓縮以盡量減小 DEX 檔案的大小，并移除未使用的那部分代碼。
使用 Dalvik 可執行檔案分包的應用可能無法在運作的平台版本早于 Android 4.0(API 級别 14)的裝置上啟動。
使用 Dalvik 可執行檔案分包配置的應用發出非常龐大的記憶體配置設定請求，則可能會在運作期間發生崩潰。盡管 Android 4.0(API 級别 14)提高了配置設定限制，但在 Android 5.0(API 級别 21)之前的 Android 版本上，應用仍有可能遭遇這一限制。
在将應用配置為支援使用64K或更多方法引用之前，開發者應該采取措施減少應用代碼調用的引用總數，包括由應用代碼或包含的庫定義的方法。下列政策可幫助您避免達到 DEX 引用限制：
檢查您的應用的直接和傳遞依賴項 - 確定您在應用中使用任何龐大依賴庫所帶來的好處大于為應用添加大量代碼所帶來的弊端。一種常見的反面模式是，僅僅為了使用幾個實用方法就在應用中加入非常龐大的庫。減少您的應用代碼依賴項往往能夠幫助您規避 dex 引用限制。
通過 ProGuard 移除未使用的代碼 - 為您的版本建構啟用代碼壓縮以運作 ProGuard。啟用壓縮可確定您傳遞的 APK 不含有未使用的代碼。
三. 工具
由于MultiDex存在的局限性，官方也給出了上述的兩個政策來輔助減少應用代碼調用的引用總數。
在實施這兩個政策之前，我們需要一個好用的工具來統計目前應用代碼的方法數，在添加一個依賴庫之後，需要評估該依賴庫會引入多少方法，是否值得引用。
3.1. DexHelper
一款分析Dex檔案的Gradle插件，在APK打包的同時，輸出APK包中的dex檔案相關資訊: 引用方法數等。實作原理參考的官網Dex 格式，根據Dex檔案格式，解析APK包中的.dex二進制檔案，擷取該dex檔案中方法總數。
修改父項目build.gradle，添加依賴com.ximsfei:dexhelper:version
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:2.3.3'
// 添加依賴
classpath 'com.ximsfei:dexhelper:version'
}
}
注: 最新version，以官方位址為準
修改子項目build.gradle，應用插件com.ximsfei.dexhelper
apply plugin: 'com.android.application'
// 應用插件
apply plugin: 'com.ximsfei.dexhelper'
運作，通過assemble*指令打包apk，自動輸出結果
$ ./gradlew assemble -q
DexHelper: apk file -> app-debug.apk
DexHelper: dex file -> classes.dex
DexHelper: method size -> 27022
DexHelper: apk file -> app-release-unsigned.apk
DexHelper: dex file -> classes.dex
DexHelper: method size -> 27021
四. 總結
在選擇解決方案時，利用好的工具來評估實施方案的價值，提高代碼運作效率，降低應用本身的體積，是每個開發者需要努力去做的。使用MultiDex來解決項目日益增長帶來的問題，不如在開發的過程中，将點滴細節做到極緻。小工具大用途，DexHelper可以幫你将應用做到小而美。