64K 方法数也被称为65K方法数问题，本质上都是指Android Dalvik 可执行文件.dex 中的Java方法数引用超过65536，64K的计算方法是65536除以1024，65K的计算方法是65536除以1000，Android 官方的叫法是64K。
Android Apk 文件本质上是一个压缩文件，它里面包含的classs.dex 文件是可执行的Dalvik 字节码文件，这个.dex文件中存放的是所有编译后的Java 代码。Dalvik 可执行文件规范限制了（事实上最初设计上的一个失误）单个.dex文件最多能引用的方法数是65536个，这其中包含了Android Framework、App 引用的第三方函数库以及App自身的方法。
Android 5.0(api 21)之前，系统使用的是Dalvik 虚拟机来执行Android 应用，默认情况下，Dalvik为每个Apk 只生成一个classes.dex 文件，为了规避单个.dex 文件方法数超过64K 的问题，我们需要拆分这个单一的classes.dex 文件，拆分后可能存在类似于classes.dex、classes2.dex、classes3.dex 等多个.dex 文件，具体有多少个需要看开发者的配置以及应用的总方法数，在应用启动时，会先加载classes.dex 文件，我们称之为主（Primary）dex文件，应用启动后才会依次加载其他的.dex 文件，这些统称为（Secondary）dex文件。为了规避64K限制，Google 推出了一个名为MultiDex Support Library 的函数库，当我们下载了Android Support Libraries 之后，可以在/extras/android/support/multidex/目录中找到这个函数库。
5.0 开始，Android 使用名为ART 的虚拟机来代码Dalvik 虚拟机，ART 天然支持从APK 中加载多个.dex 文件，在应用的安装期间，它会执行一个预编译操作，扫描Apk 中的classes(..N).dex 文件并将它们编译成一个单一的.oat 文件，在应用运行时去加载这个.dex 文件，而不是一个一个的加载.dex 文件。
当你的App 开始接触碰到64K 方法数的天花板时，并不建议立即使用MultiDex Support Library 来将apk 中的单一的.dex 文件拆分成多个，从而规避64K 方法数限制引起的编译错误问题。
最佳的实践是永远保持应用的方法不超过64K,永远没有机会使用MultiDex Support Library ，因为使用MultiDex 是下下策，在大多数情况下会降低应用的性能，这个后面会说的。因此，我们有必要先来了解哪些方法可以将应用的方法数降低到64K 一下。
1、检查硬的直接和间接第三方库
2、使用Proguard 移除无用的代码
这个不多说，参考官方文档
