Android開發的朋友，如果是在開發一款中大型應用時，都會碰到這麼一個問題，就是dex分拆問題, google給出的解決方案MultiDex。

現象：

有些APP本身功能比較多，再加上一些其它三方的SDK，慢慢的發現dex越來越大，直到有一天編譯出現如下錯誤：

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

• 1
• 2

錯誤原因比較明確了，開啟Gradle Console檢視詳細資訊，我們在一堆錯誤中找到如下提醒：

"UNEXPECTED TOP-LEVEL EXCEPTION:\ncom.android.dex.DexIndexOverflowException: method ID not in [0, 0xffff]: 65536\n\tat com.android.dx.merge.DexMerger$6.updateIndex(DexMerger

• 1

原因：

問題原因是因為早期Android系統設計時用一個short來表示dex裡的每個method的id，我們知道short的上限是64K，所以就遺留了這樣一個問題，既然存在了，肯定要找方法解決，Google剛開始給出建議是使用proguard，但是再怎麼proguard也還是會突破64K的，所以後面Google給出了MultiDex方案。就是我們經常看到的一個apk裡，有classes.dex, classes2.dex，甚至還有classes3.dex等。

MultiDex實現步驟：

用這種方法來突破64K的method id數量的限制，具體實現步驟如下：
1. 在Module的build.gradle裡新增
multiDexEnabled true

例如：

android {
    compileSdkVersion 22
    buildToolsVersion "22.0.1"

    defaultConfig {
        applicationId "x.x.x"
        minSdkVersion 15
        targetSdkVersion 22
        versionCode 17
        versionName "1.2.9"
 


        //新增這一行
        multiDexEnabled true

    }

}

2. 接著在Module的build.gradle裡新增

dependencies {
  compile 'com.android.support:multidex:1.0.0'
}

• 1
• 2
• 3

3.第三步有兩種情況，
1）如果你的apk沒有定義application，則在AndroidManifest.xml裡的application裡做如下修改：
新增MultiDexApplication

<application
        android:icon="@mipmap/ic_launcher"
        android:label="@string/app_name"
        android:theme="@style/AppTheme"
        android:name="android.support.multidex.MultiDexApplication"
        tools:replace="android:icon, android:name"
       >

• 1
• 2
• 3
• 4
• 5
• 6
• 7

2）如果apk有自己的appliation，比如叫MyApplication，則在MyApplication實現里加如下程式碼：

 @Override
    protected void attachBaseContext(Context base) {
        super.attachBaseContext(base);
        MultiDex.install(this);
    }

至此，MultiDex的編譯配置已經完成，你只要重新編譯即可，apk就會生成兩個(或多個) dex。如果有興趣瞭解下MultiDex的實現原理，可以檢視原始碼，https://android.googlesource.com/platform/frameworks/multidex 原始碼相對比較簡單的。基本原理是使用java的class loader，這個在一些熱修復技術上也在使用，比如企鵝工廠開源的Tinker。

存在的坑及解決方法：

這個問題的表現除了報VerifyError外，還有可能報Could not find class，NoClassDefFoundError, Could not find method等。是因為我們在main dex中呼叫的函式或類被放在了classes2.dex中，而在classes2.dex還沒有被完全載入前，呼叫這些api就會導致這種問題。要確認是否是這個問題導致的錯誤，我們可以檢視：
app\build\intermediates\multi-dex\debug\maindexlist.txt 這個文字檔案，這裡列出來的類都會被放在主dex中，那麼問題是我們要如何解決這個問題呢？
解決方案：
首先，我們來看下在編譯過程中，multidex是做了哪幾步，這個開啟Gradle Console可以找到multidex相關的步驟，其中一個步驟是關鍵就是生成maindexlist.txt的步驟：createDebugMainDexClassList就是這裡生成maindexlist.txt 的，但是這個檔案直接修改又沒有什麼用，因為每次編譯都會重新生成一次的，筆者在實踐者發現可以用自定義的方式：multiDexKeepFile file(‘multiDexKeep.txt’)
例子:

android {
    compileSdkVersion 22
    buildToolsVersion "22.0.1"


    defaultConfig {
        applicationId "x.x.x"
        minSdkVersion 15
        targetSdkVersion 22
        versionCode 17
        versionName "1.2.9"

        multiDexEnabled true

        //新增這一行
        multiDexKeepFile file('multiDexKeep.txt')
    }

}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19

內容和上面提到的createDebugMainDexClassList生成的maindexlist.txt一樣即可，記得把這個multiDexKeep.txt檔案放在app目錄 下。multiDexKeep.txt內容可以如下：

com/test/Util.class
com/test/help/b.class

• 1
• 2

實測起作用，被keep的class全都留在了classes.dex中(release版本要配合mapping使用)。

2. ANR
也就是我們常說的卡頓，為什麼會卡頓呢？這裡因為我們把multidex的install放在了attachBaseContext中，而這個呼叫又是在MainActivity的onCreate之前的，所以如果2.dex，3.dex第一次載入時間很長(生成odex檔案會耗費一定的時間), 就有可能會導致第一次啟動卡上一小會（實測在Dalvik手機上一般classes.dex比較小的情況下，卡頓不明顯，線上就不好說了）。

解決方法是在 APP第一次啟動時(解除安裝、重灌都會做一遍2odex，具體可以檢視/data/data//code_cache/secondary-dexes/目錄下的odex檔案，所以這裡判斷要準確)，把install放到非同步執行緒裡去做。這是很多網上的解決方法，但是如果這樣做，你就必須再寫一個類似initAfterDex2Installed（）,來保證2.dex裡的類不會提前被呼叫到，或者輸出一個啟動介面，停留幾秒的樣子，比如很多APP啟動都有開機廣告，或者開機畫面，以此來解決app在2.dex載入之前部分功能無法使用的問題。網上大多是這種解決方案。本人測試後發現，如果MultiDex.install(this)，放在後面或者非同步來做的話，在MainActivity裡的onCreate函式:
setContentView這裡就出錯了,堆疊如下：

java.lang.NoClassDefFoundError: android.support.v7.appcompat.R$attr
                                                       at android.support.v7.app.AppCompatDelegateImplV7.ensureSubDecor(AppCompatDelegateImplV7.java:289)
                                                       at android.support.v7.app.AppCompatDelegateImplV7.setContentView(AppCompatDelegateImplV7.java:246)
                                                       at android.support.v7.app.AppCompatActivity.setContentView(AppCompatActivity.java:106)
                                                       at com.cn.x.x.MainActivity.onCreate(MainActivity.java:86)

• 1
• 2
• 3
• 4
• 5
• 6

很明顯android.support.v7.appcompat.R$attr在classes2.dex中，在呼叫時，還沒有完成classes2.dex的載入，所以如果要解決的話，要不把這個類放到maindex中，要不讓MainActivity的onCreate函式延遲呼叫。如果其它類還有類似問題，就要一個一個的試，成本有點高，有可能在不同系統，不同手機上還會出各種奇芭錯誤。由此看來，install延期載入方案並不合適。為了說明問題，也分析了網易幾款大的產品，比如新聞、雲音樂，全部是使用的mutlidex方式，都沒有延期載入，全部是在application的attachBaseContext直接呼叫install.

那麼我們要如何解決 2.dex, 3.dex在第一次啟動apk時，有可能產生的耗時呢？

1）重新設計，或者在開發之前就設計好，使用外掛化的方式來解決maindex的問題，把一些功能做成外掛，保證這些dex在首屏啟動時不需要被載入
2) 自己實現多dex框架，有興趣可以看下微信的實現框架，並沒有使用MultiDex，而是使用自己的Tinker（一種動態載入dex的方案，也被用於熱更新)
微信使用的是TinkerAppliation. 另外一個例子是手機QQ的實現技術，手Q里居然有classes6.dex，也就是總共有6個dex，感興趣的朋友可以分析下手Q的實現方案，筆者動態看過，基本上也是在手Q啟動介面還沒出來時，所有的dex會全部完成2odex的轉換，在手機上第一次執行還是會花費不少時間的。而且筆者測試了很多手機，基本上2個dex不會發生anr，當然真實情況怎麼樣，還是要放到線上才能說明問題，也就是接收眾多手機，不同品牌，不同效能的手機測試才知道，好在有一些知名公司的質量跟蹤平臺可以線上捕捉這些ANR，比如網易雲捕。

3) ART以後的實際情況是，不管你分成幾個dex，在安裝時都已經全部完成OAT的轉換，這樣分dex至少在ART以後也就是5.0（部分4.4機型可以選ART模式)以後不存在呼叫install佔用時間的問題，而且實際測試也是在5.0以後，即使不呼叫install(this)也能正常工作，為了證實，我們拿網易新聞測試，在安裝完後，在目錄 /data/dalvik-cache//[email protected]@[email protected]@classes.dex，這個oat檔案有84M，所以你可以知道
為什麼第一次安裝相比 dalivk慢了。
開啟這個檔案，字尾雖然還是dex，其實是一個ELF檔案，也就是OAT檔案。

classes.dex在這裡。

classes2.dex, classes3.dex都已經被優化成OAT檔案了。

這些處理都已經在安裝的時候完成，就不存在啟動時再對classes2.dex和classes3.dex進行處理了，避免了第一次啟動可能導致的ANR.

總結

總結一下就是我們可以通過自定義maindexlist來控制哪些類一定出現在main dex中,這樣可以避免crash；
而針對ANR還是不建議使用非同步載入，合理設計和外掛形式會比較合理，如果大家有其它更好的方法可以討論。
不過在ART以後，不管是classes.dex還是classes2.dex, classes3.dex在安裝時就已經完成了OAT的轉換了，由分包導致的ANR的可能性就小了很多。