相信一位有经验的安卓开发人员,都会遇到过以下错误<如果你还没遇到类似情况,要么你是高手,要么就是你的开发经验还没到触发这种情况的条件>
Android_64k.png
上图中的错误主要是由于我们打包后classes.dex文件里方法数量超出的65536个
Google官方文档:https://developer.android.com/intl/zh-cn/tools/building/multidex.html
有两种说法
项目工程的方法总和<包括library>
方法引用次数的总和
第一种是目前大部分网上的说法;第二种是本人听说的<但当时很是疑惑>
1.项目工程的方法总和<包括library>
这种说法并没有说错,但不完全对,为什么了,如果你什么都不做的话,正常编译打包确实是可以按照这种说法来进行计算,但肯定我们还是可以做点什么的?<后话>
2.方法引用次数的总和
这种说法如果单独拿出来讲,基本是错的,为什么?
我们想想,引用次数,也就是调用次数,那意思是说,我只要调用方法的次数超出了65536次,那是不是就会报出65536的限制问题了了?
答:No,本人测试过;测试方法很简单:
1.写个方法;
2.然后用for循环<循环次数肯定是大于65536的>,每次循环调用同一个方法,编译后,安然无样;
3.for循环后我不死心,递归,编译后,安然无样,所以说这种说法站不稳脚.
本人经过各种测试,测试过程就不说了,得出了几个结论
两种说法单独拿出来说都不算对
说法1比说法2要靠谱一点
两种说法相结合,才算是完美的答案
下面分析情况来说明计算方法
关键:是否混淆
无混淆
当你的工程在编译的时候没有采取任何混淆措施,那么计算方式参考说法1
有混淆
当你的工程在编译的时候采取了混淆措施,那么计算方式如果按说法2来讲,并不对,应该是:程序中被使用/调用的方法数量的总和
情景说明看完上面后基本就说完了,但对于有混淆的情况时,要知道几点
情景一
有一个类 class A,里面有10个方法,但整个工程中用到了class A中的某一个方法,这时如果你的工程采用了混淆,那么class A中其余的9个方法并不会统计进去
情景二
有一个接口 interface A,里面有10个方法,然后有一个实现类class B;
如果你整个工程中是调用了class B里的某一个方法或某几个方法,那么情况和<情景一>一样,代码是么写的:
B b = new B(); b.xxx();如果你是采用的多态的形式编写的代码,类似写法:
A a = new B(); a.xxx();那么方法数量是interface A 与 class B 里面被调用的那些方法之和,通俗的讲就是调用的这个方法要当两个来计算
总结用混淆来尽量让64k的错误晚点到来
少用多态的写法来避免同一方法被重复核算
在不必要的情况下,尽量把逻辑写在一个方法中
同样的操作抽出成基类,在基类中统一实现
不要没事就重写父类的方法,主要表现在Activity与Fragment中的生命周期方法
如果你的app最低只兼容到4.0,Fragment就可以不用v4包中的
一句话:能不用兼容包的就不要用兼容包的,引入jar或library工程时注意下它们的方法数