在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会有一些损耗,必须进行一下优化,请看下编博文之谈。
如果对您有帮助,请点赞,留言,顶了