隨着業務規模發展到一定程度，不斷地加入新功能、添加新的類庫，代碼在急劇的膨脹，相應的apk包的大小也急劇增加， 那麼終有一天，你會不幸遇到這個錯誤：
Conversion to Dalvik format failed:Unable to execute dex: method ID not in [0, 0xffff]: 65536
具體原因如下：
http://tech.meituan.com/mt-android-auto-split-dex.html?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io
1.修改Gradle配置文件，啓用MultiDex幷包含MultiDex支持：
android {
defaultConfig {
multiDexEnabled true
}
}
dependencies {
compile'com.android.support:multidex:1.0.1'
}
在AndroidManifest.xml的application中聲明android.support.MultiDex.MultiDexApplication；
如果你已經有自己的Application類，讓其繼承MultiDexApplication；
如果你的Application類已經繼承自其它類，你不想/能修改它，那麼可以重寫attachBaseContext()方法：
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
MultiDex.install(this);
}
MultiDex自動拆包帶來的問題：
1.在冷啓動時因爲需要安裝DEX文件，如果DEX文件過大時，處理時間過長，很容易引發ANR（Application Not Responding）；
2.採用MultiDex方案的應用可能不能在低於Android 4.0 (API level 14) 機器上啓動，這個主要是因爲Dalvik linearAlloc的一個bug ;
3.採用MultiDex方案的應用因爲需要申請一個很大的內存，在運行時可能導致程序的崩潰，這個主要是因爲Dalvik linearAlloc 的一個限制，這個限制在 Android 4.0 (API level 14)已經增加了, 應用也有可能在低於 Android 5.0 (API level 21)版本的機器上觸發這個限制；
MultiDex手動拆包：
Android Studio 中提供了相應的手動拆包的方法：
1.multiDexKeepFile：手動加入要放到Main.dex中的類。
例：
android/support/multidex/MultiDex.class
2.multiDexKeepProguard：以Proguard的方式手動加入要放到Main.dex中的類。
例：
-keep class android.support.multidex.** {
*;
}
build.gradle：
android {
defaultConfig {
multiDexEnabled true
// 'multidex.pro'和build.gradle同一個目錄
multiDexKeepProguard file('multidex.pro')
}
}
dependencies {
compile'com.android.support:multidex:1.0.1'
}
編譯時，相應的文件文件會加入到
build/intermediates/multi-dex/***/maindexlist.txt
build/intermediates/multi-dex/***/manifest_keep.txt
總結
上面是我在使用MultiDex過程中發現的DEX手動拆包的方案。由於時間倉促，項目要趕進度，所以直接貼代碼了，關於後續的MultiDex.install(this)異步加載方法和出現ClassNotFoundException的異常，以後再詳細的去寫吧。
