你好,游客 登录 注册 搜索
背景:
阅读新闻

诠释Android开发时报64K或65536错误问题

[日期:2017-05-21] 来源:Linux社区  作者:qjay_dev [字体: ]

相信一位有经验的安卓开发人员,都会遇到过以下错误<如果你还没遇到类似情况,要么你是高手,要么就是你的开发经验还没到触发这种情况的条件>

Android_64k.png

上图中的错误主要是由于我们打包后classes.dex文件里方法数量超出的65536个
Google官方文档:https://developer.android.com/intl/zh-cn/tools/building/multidex.html

问题:那这个65536倒底是怎么计算的了?

有两种说法

  • 项目工程的方法总和<包括library>
  • 方法引用次数的总和
    第一种是目前大部分网上的说法;第二种是本人听说的<但当时很是疑惑>

1.项目工程的方法总和<包括library>

这种说法并没有说错,但不完全对,为什么了,如果你什么都不做的话,正常编译打包确实是可以按照这种说法来进行计算,但肯定我们还是可以做点什么的?<后话>

2.方法引用次数的总和

这种说法如果单独拿出来讲,基本是错的,为什么?
我们想想,引用次数,也就是调用次数,那意思是说,我只要调用方法的次数超出了65536次,那是不是就会报出65536的限制问题了了?
答:No,本人测试过;测试方法很简单:
1.写个方法;
2.然后用for循环<循环次数肯定是大于65536的>,每次循环调用同一个方法,编译后,安然无样;
3.for循环后我不死心,递归,编译后,安然无样,所以说这种说法站不稳脚.

正确的计算方法

本人经过各种测试,测试过程就不说了,得出了几个结论

  1. 两种说法单独拿出来说都不算对
  2. 说法1比说法2要靠谱一点
  3. 两种说法相结合,才算是完美的答案

下面分析情况来说明计算方法
关键:是否混淆

  • 无混淆

    当你的工程在编译的时候没有采取任何混淆措施,那么计算方式参考说法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工程时注意下它们的方法数

本文永久更新链接地址http://www.linuxidc.com/Linux/2017-05/144061.htm

linux
相关资讯       Android开发 
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数

       

评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款