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问题。

你可能感兴趣的:(Android-65536方法数限制)