在Android项目开发中，尤其是开发类似淘宝，京东，微信，直播等大型项目中，由于产品的迭代，业务模块的快速增长，到了一定的规模后难免会遇到65536/64K方法数的问题。
它是个什么鬼？
这个问题，网上还有其他人说65方法数问题，本质上都市指Android Dalvik可执行文件.dex中的Java方法数引用超过65536，64K的计算方法是65536/1024，65K的计算方法是65536/1000，Android的官方说法就是64K这种说法。
也就是说64K方法数问题就是在构建APP的时候出现编译，导致构建的失败。同时，在旧版本和新版本的构建系统中提示也会不一样。卧槽，我们不一样。。。。
旧版本错误提示
com.android.dex.DexIndexOverflowException:method IDnotin[0,0xffff]:65536新版本错误提示
trouble weriting output:
Too many field references:131000;max is 65536.
You may try using --multi-dex option64K限制的原因
Android APK 文件本质上是一个压缩的文件，它的里面包含的classes.dex文件是可执行Dalvik文件，这个.dex文件中存放的是所有便宜后的java代码。Dalvik可执行文件规范限制了单个,dex文件最多能够引用的方法数是65536个，这其中包含了Android Framework、APP引用的第三方函数库以及APP自身的方法。
使用MultiDex解决问题
、
Android5.0版本之前
在Android5.0(API 21)前，系统使用的是Dalvik虚拟机来执行Android 应用，默认情况下，Dalvik为每个APK只生成一个classes.dex文件，为了规避单个.dex文件方法数超过64k的问题，我们需要拆分这个单一的classes.dex文件，拆分后可能存在类似于classes.dex、classes2.dex、classes3.dex等多个.dex文件，具体多小个需要看开发者的配置以及应用的方法总数。在启动应用时，会先加载classes.dex文件，我们叫做主的.dex文件，应用在启动后时才会依次加载其他.dex文件，这些叫做从
的.dex文件。
为了规避这些问题，Google推出了一个名为MultiDex Support Library的函数库，当我们下载了Android Support Libraries之后，可以在SDK/extra/android/support/multidex/目录中找到这个函数库。
Android5.0之后版本
Android5.0 之后开始，Android使用名为ART的虚拟机来代替Dalvik虚拟机，ART天然支持从APK中间中加载多个.dex文件，在应用安装亲戚间，它会执行一个预编译操作，scanAPK中所有classes.dex文件并将他们以便宜成一个单一的.oat文件,在引用运行时去加载这个.oat文件，而不是一个一个的加载.dex文件。
如何避免出现64K限制
1，有效减少方法数，避免使用降低性能的MultiDex Support Library。
如何减少方法数
1，减少使用第三方函数库，尽量避免使用。
2，使用Proguard移除无用代码：配置并在Release版本中使用Proguard,它的压缩功能通过分析字节码，能够检测并且一处没有使用到的类、字段、方法和属性。
如何配置MultiDex
最后实在是没办法了，来吧。配一配解决问题。
Android 的Gradle插件在Android Build Tool21.1 就支持使用MultiDex了。
首先配置APP module的build.gradle文件
defaultConfig {
multiDexEnabled true
}android-support-multidex.jar
或者
compile 'com.android.support:multidex'引入MultiDexApplication
如果自身有BaseAppcation就直接继承MultiDexApplication。
如何应用已经有自定义Appcation类，而且你不想或者不能修改它的弗雷，那么也可以通过腹泻attachBaseContext方法并初始化MultiDex。
因为attachBaseContext是在oncreate之前执行的。是应用最早执行的方法。
在此，使用MultiDex Support Library会有一些损耗，必须进行一下优化，请看下编博文之谈。
如果对您有帮助，请点赞，留言，顶了
