随着业务规模发展到一定程度，不断地加入新功能、添加新的类库，代码在急剧的膨胀，相应的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'
}
multidex.pro加入:
-keep class android.support.multidex.** {
*;
}
编译时，相应的文件文件会加入到
build/intermediates/multi-dex/***/maindexlist.txt
build/intermediates/multi-dex/***/manifest_keep.txt
总结
上面是我在使用MultiDex过程中发现的DEX手动拆包的方案。由于时间仓促，项目要赶进度，所以直接贴代码了，关于后续的MultiDex.install(this)异步加载方法和出现ClassNotFoundException的异常，以后再详细的去写吧。
