android方法数限制,Android-65536方法数限制

从编译apk 遇到65536(64k) 方法数限制问题说起。

一.方法数限制包含

1.android framework

2.app应用的第三方函数库

3.app自身的方法数。

(dalvik为每个apk只生成1个dex)

为解决64k问题 谷歌推出 multiDex support libaray 来拆分多个dex ，本身这是一个设计缺陷，

拆分多个dex以后。dalvik虚拟机在程序启动时加载主dex，启动后加载从dex文件。

android 5.0之前使用dalvik 虚拟机，之后采用art 虚拟机，art的优势在于天然支持加载apk中的多个dex文件，安装程序期间，art会执行一个预编译操作，扫描apk 中的 XXX.dex,这些dex文件会被打包成一个.oat文件，在程序运行时加载这个.oat文件，不再是一个一个加载dex文件。

二.如果避免64k问题呢？

1.最好的方法就是永远保持应用的方法数小于64k，使用multiDex 进行分包是下下策。

2.引入第三方库要谨慎，综合评估 要引入库的 体积、方法数、性能等。

3.使用produard 配置release 版本，使用produard的压缩功能通过分析字节码，检查并移除不用的类，字段，方法和属性。

使用multidex 第二个弊端是需要继承 MultiDexApplication ，如果项目中已经自定义了application并且继承了其他必须继承的application 则需要重写 applicaiton的 attachBaseContext方法并初始化MultiDex。

三.使用MultiDex 的局限性

1.应用程序首次启动时 Dalvik虚拟机 会对所有的dex执行一个dexopt操作，生成odex文件，这个过程很复杂也很耗时，如果应用的从dex文件太大，可能会导致出现anr。

2.dalvik 的线性内存分配器 linearAlloc 本身有一个bug，使用MultiDex分包的应用会启动失败。

所以建议将应用的minSdkVersion 指定为14来规避可能发生的问题。

3.dalvik 线性内存分配器linearAlloc的限制，使用MultiDex的应用在出现很大的内存分配时，可能会导致应用程序崩溃，根本原因是虚拟机用力加载类的对内存大小被硬编码了。android2.3以下是5m，以上是8m，android 4.0开始分配内存改为16M。 及时到了16m 使用5.0以下的系统运行还可能出现64k问题，从而导致崩溃。使用5.0以上就不会存在linearAlloc 的问题。

4.引入MultiDex机制后，必然出现主dex和从dex，应用启动所需要的类都必须放到主dex，否则会出现 NoClassDefFoundError 错误，如果应用中我们自己应用的第三方库 有通过反射java类，或者调用NDK层代码的java方法，这些可能就不会放到主dex文件中，如果在应用启动时需要用到，必然出现问题。

总结：使用MultiDex机制属于无奈之举，MultiDex需要在主线程完成解压，dexopt、加载操作，会影响启动速度和性能，使应用产生启动时黑屏和Anr问题。