在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 option

64K限制的原因

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会有一些损耗，必须进行一下优化，请看下编博文之谈。

如果对您有帮助，请点赞，留言，顶了

简述Android(安卓)解决65536/64K方法数限制方案