阐述Android开发时报64K或65536错误问题
发布时间：2021-11-15 14:52:23 所属栏目：教程 来源：互联网
导读：问题:那这个65536倒底是怎么计算的了? 有两种说法 项目工程的方法总和包括library 方法引用次数的总和 第一种是目前大部分网上的说法;第二种是本人听说的但当时很是疑惑 1.项目工程的方法总和包括library 这种说法并没有说错,但不完全对,为什么了,如果你什么
|
问题:那这个65536倒底是怎么计算的了? 有两种说法 项目工程的方法总和<包括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工程时注意下它们的方法数  （编辑：东莞站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
