64K方法数限制原理及解决方案
64K限制的原因
Android APK文件本质上是一个压缩文件，它包含的classes.dex文件是可执行的Dalvik字节码文件，这个.dex文件中存放的就是编译后的Java代码。Dalvik可执行文件规范限制了单个.dex文件最多引用的方法数是65536个。其中包含联网Android Framework、APP引用的第三方函数库以及APP自身的方法。
配置MultiDex
一、修改build.gradle文件
android {compileSdkVersion 21buildToolsVersion "21.1.0" // 这里必须要21.1.0之后defaultConfig {minSdkVersion 14targetSdkVersion 21...// Enabling multidex support.multiDexEnabled true}...
}dependencies {compile 'com.android.support:multidex:1.0.1'
}
第二步，修改AndroidManifest.xml文件，引用MultiDexApplication类：
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"package="com.example.android.multidex.myapplication"><application...android:name="android.support.multidex.MultiDexApplication"> ...</application>
</manifest>
三、Application配置
如果应用已经有自定义的Application类，那么可以让它改而继承MultiDexApplication：
public class MyApplication extends MultiDexApplication {@Overridepublic void onCreate() {super.onCreate();}
}
如果应用已经有自定义的Application，且你不想修改它的父类，可以通过覆写attachBaseContext方法并初始化MultiDex：
@Overrideprotected void attachBaseContext(Context base) {super.attachBaseContext(base);MultiDex.install(this);
}
在开发阶段优化MultiDex的构建
MultiDex在开发阶段将极大地影响到团队的开发效率。MultiDex之所以会增加如此显著的构建处理时间，原因在于构建系统需要经过复杂的计算决定哪些类要包含在主dex文件中，哪些类可以包含在从dex文件中。
解决：
为加速构建过程，我们可以在Gradle中配置productFlavors来创建两个flavor：一个是开发阶段使用的，一个是生产阶段使用的。开发阶段将minSdkVersion改为21使用ART运行时机制，这样能加快构建速度。release时改为合适的minSdkVersion，这样仅在release时费时较长。
android {compileSdkVersion 21buildToolsVersion "21.1.0" // 这里必须要21.1.0之后productFlavors{// 配置不同的falvordev {minSdkVersion 21 // 开发环境的minSdkVersion }prod {minSdkVersion 14 // 生产环境的minSdkVersion }}...
}dependencies {compile 'com.android.support:multidex:1.0.1'
}
MultiDex的局限性：
- 应用首次启动时Delvik虚拟机会对所以的dex文件执行dexopt操作，生成ODEX文件，这个过程复杂且非常耗时，如果应用的dex文件太大，可能会导致出现ANR。
- 由于Dalvik的线性内存分配器alnearAlloc的限制，使用MultiDex的应用在出现很大的内存分配时，可能会导致应用崩溃。根本原因是Dalvik虚拟机用来加载类的堆内存大小被硬编码了。在Android5.0使用ART虚拟机后，不存在此问题。
- 引入MultiDex机制时，会存在主dex文件和从dex文件，应用启动所需要的类都必须放在主dex文件中，否则会出现NoClassDefFoundError的错误。