Android 应用开发中，当产品迭代到一定版本，业务模块增长到一定模块后，APK不可避免会遇到64K方法数的问题，了解其原理并给出解决方案是作为高级开发人员必须具备的能力。
64k方法数问题也有人称之为65K方法数，本质都是指Android Dalvik可执行文件.dex中的Java方法数引用超过65536,64k的计算方法是65536除以1024,65k的计算方法是65536除以1000，Android官方的叫法是64K.因此64K这种说法是一种符合计算机科学的说法。
Android官方64K介绍：
https://developer.android.com/intl/estools/buiding/multidex.html
64K方法数问题的直观表现在构建APP的时候出现编译错误，导致构建失败，有旧版本的构建系统中会提示如下错误。
Conversion to Dalvik format failed:
Unable to execute dex:method ID not in [0,0xffff]:65536
新版本的构建系统会提示类似如下错误：
trouble writing output:
Too many field references:131000;max is 65536.
You may try using - multi - dex option.
A、64K 限制的原因
Android APK 文件本质上是一个压缩文件，它里面包含的classes.dex文件是可执行的Dalvik字节码文件，这个.dex文件中存放的是所有编译后的Java 代码。Dalvik可执行文件规范限制了（事实上是最初设计上的一个失误）单个.dex文件做多能引用的方法数时65536个，这其中包含了Android Framework、APP引用第三方函数库以及APP自身的方法。
B、使用MultiDex解决64K限制的问题
（1）Android5.0之前的版本
在Android5.0(API level 21)之前，系统使用的是Dalvik 虚拟机来执行Android 应用，默认情况下，Dalvik 为每个APK只生成一个classes.dex文件，为了避免单个.dex文件方法数超过64K的问题，我们需要拆分这个单一的classes,dex文件，拆分后可能存在类似于classes.dex,classes2.dex,classes3.dex等多个classes.dex文件，我们称之为主（Primary）dex文件，应用启动后才会依次加载其他.dex文件，这些统称为从（Secondary）dex文件。为了规避64K限制，Google推出了一个名为MultiDex Support Library 的函数库，当我们下载了Android Support Libraries 之后，可以在<sdk>/extras/android/support/multidex/目录中找到这个函数库。
（2）Android5.0及之后的版本
从Android 5.0(API level 21)开始，Android 使用名为ART的虚拟机来代替Dalvik虚拟机，ART天然支持从APK文件中加载多个.dex文件，在应用安装期间，他会执行一个预编译操作，扫描APK中的classes(..n).dex文件并将它们编译成一个单一的.oat文件，在应用运行时去加载这个.oat文件，而不是一个一个的加载.dex文件。
C、如何避免出现64K限制
当APP开始触碰到64K方法数的界限时，我并不建议你立即使用MultiDex Support Library来将APK中单一的.dex 拆分成多个，从而规避64K方法限制引起的编译错误的问题。最佳实践是永远保持应用的方法数低于64K，永远没有机会使用MultiDex Support Library,因为使用MultiDex是下下策，在大多数情况下会降低应用的性能。一次有必要先了解有哪些方法可以将应用的方法数降到低与64K以下。
（1）检查应用的直接和间接第三方依赖
在项目开发中引入一个第三方函数库，是件非常谨慎的事情，我们需要综合考虑这个库的体积，方法数，性能等。一个常见的反模式引入一个很大的函数库，但仅仅用到其中很少的功能，对于这种函数库的引入坚决抵制的，有很多其他的方法可以被用来避免引入这个库。例如，使用其他库代替，或者将这部分功能单独抠出来，或者自己实现。目的只有一个，提出对这个函数库的依赖，从而较大的减少APK的方法数。
（2）使用Proguard移除无用代码
配置并在Release版本中使用能ProGuard,他的压缩功能通过分析字节码，能够检测并移除没有使用到的类、字段、方法、属性。
D、配置MultiDex
如果由于各种原因无法将应用的方法数降到64K一下，那么就只有使用Google官方的MultiDex解决方案了。
配置如下：
android {
compileSdkVersion 26
defaultConfig {
applicationId "com.explem.chaohaozhao.giveyou"
minSdkVersion 15
targetSdkVersion 26
versionCode 1
versionName "1.0"
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
//使能multidex的支持
multiDexEnabled true
}
}
引入依赖：
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation"org.jetbrains.kotlin:kotlin-stdlib-jre7:$kotlin_version"
implementation 'com.android.support:appcompat-v7:26.1.0'
implementation 'com.android.support.constraint:constraint-layout:1.1.3'
testImplementation 'junit:junit:4.12'
androidTestImplementation 'com.android.support.test:runner:1.0.2'
androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'
//解决64K限制问题，编译不通过的问题，尽量别用
implementation 'com.android.support:multidex:1.0.3'
}
接入MultiDexApplication,根据项目的需要，具体情况决定如何接入
如果项目中没有实现自定义的Application 类，那么只需要在Application Module 的AndroidManifest.xml文件中使用MultiDexApplication替换Application即可：语句如下：
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.explem.chaohaozhao.giveyou">
<!--接入MultiDex-->
<application
android:name="android.support.multidex.MultiDexApplication"
android:allowBackup="true"
android:icon="@mipmap/ic_launcher"
android:label="@string/app_name"
android:roundIcon="@mipmap/ic_launcher_round"
android:supportsRtl="true"
android:theme="@style/AppTheme">
</application>
</manifest>
如果已经有自定义Application类了，那么直接继承MultiDexApplication，语句如下：
/**
* Created by chaohao.zhao on 2018/10/16.
*/
class MyApplication : MultiDexApplication(){
override fun onCreate() {
super.onCreate()
}
}
如果应用不想或者不能修改它的父类，那么可以以覆写attachBaseContext方法并初始化MultiDex，语句如下：
/**
* Created by chaohao.zhao on 2018/10/16.
*/
class MyApplication : Application(){
override fun attachBaseContext(base: Context?) {
super.attachBaseContext(base)
MultiDex.install(this)
}
}
注:因为attachBaseContext这个方法在onCreate之前执行的，是我们可以控制的应用最早执行的方法。
E、MultiDex Support Library的局限性
前面我们说过，MultiDex只是一个不得已而为之的方案，它本身不是完美的，因此将他集成到项目中，需要经过完整的测试才能上线，可能会出现应用想能下降的问题。局限性如下：
（1）应用首次启动时Dalvik虚拟机会对所有的.dex文件执行dexopt 操作，生成ODEX文件，这个过程很复杂而且非常耗时，如果应用的dex文件太大，可能会出现ANR.
（2）建议直接将应用的minSdkVersion设置为大于14，解决在低版本启动失败的可能。
（3）由于Dalvik的线性内存分配器linearAlloc 的限制，使用MultiDex应用出现很大内存分配时，可能会导致应用崩溃。根本原因是Dalvik虚拟机加载类的堆内存大小被硬编码了。可能超过了内存限制导致崩溃，当然Android5.0开始由于使用了ART虚拟机，不再存在linearAlloc的问题。
（4）当引入MultiDex 机制时，必然会存在主dex文件和从dex文件，应用启动需要的类都必须放到主dex文件汇总，否则会出现NoClassDefFoundError的错误，Android 构建工具自动帮我们处理了
Android 系统相关的依赖，但对于应用自己引入的第三方函数库，如果还依赖其他的一些东西，例如通过反射调用Java类，或者调用NDK层代码的Java方法，这些可能就不会放到主dex文件中，如果在应用启动时需要用到，那么必然出现问题。
F、在开发阶段优化MultiDex的构建
为减少开发阶段由于引入MultiDex所增加的构建时间，可以在工程模块build.gradle文件中使用productFlavors创建两个falvor：一个开发阶段用，一个生产阶段用，开发阶段falvor设置minSdkVersion为21，这使得构建系统使用ART支持的格式更快的生成MultiDex的输出；生产阶段falvor设置minSdkVersion为应用实际支持的最低版本号，代码如下
android {
productFlavors{
//定义不同的falvor
dev{
minSdkVersion 21
}
prod{
//app实际的 minSdkVersion
minSdkVersion 15
}
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}
dependencies {
//解决64K限制问题，编译不通过的问题，尽量别用
implementation 'com.android.support:multidex:1.0.3'
}
通过这样的配置，Android gradle所做的工作：
（1）将Android Studio工程中美俄Module包括他的依赖构建生成一个独立的.dex文件，这一步骤通常被称为pre-dexing
（2）将所有.dex文件都包含近APK,不做任何修改
（3）最重要的是module对应的.dex文件不会被合并，因此避免了决定哪些类放到主dex文件的耗时计算
（4）这样的配置在开发阶段只法伤改动module的.dex文件会重新计算生成打包到APK文件中，其他module的.dex文件维持不变，从而实现快锁增量构建。
注：但是这种方式只能在Android5.0设备上进行测试。
