apk逆向工程之方法数超上限65535(1)

  • 时间:
  • 来源:互联网
版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/sese12138/article/details/103256524

前段时间为游戏出渠道包,当拿到游戏母包的时候,有点吃惊,1.6G;虽然现在的游戏普遍都这么大,但是我接过的包一般都是3、4百兆这样子的

接下来就是按照惯例打包了,自认为不会出什么问题,但是到回编译的时候,出现了一个很熟悉的错误,在写APP的时候遇到过,很多理论书籍上都写过得问题,方法数超上限(具体为什么超上限,为什么会是65535,可以看看相关资料,因为我不一定会写这方面的文章),Unsigned short value out of range:81325

(其实我也是查了半天才知道这个错误的意思)

既然是方法数超上限,那就需要用到分包了,首先确认母包中的Application(或者是我们提供给CP的中间jar中调用了MultiDex.install(this);最好使用的事反射,因为有的可能不需要分包,那么分包jar就不用打入其中)像这样:


接下来就是进入正题了,开始分包

经过讨论之后,首先确认,我们打入的渠道SDK不是母包必须依赖的,也就是说这些SDK可以放在classes2.dex中(中间jar通过反射获取渠道桥接文件,因为是反射所以不是必须依赖),还要一个就是,确保MultiDex.install(this);执行在任何一个classes2.dex中的任何一个类和方法调用之前调用就行了

接下来就简单了,只要将打包脚本改一下,将渠道SDK中的jar打入到classes2.dex中就可以了,当然,如果母包已经有多个classesx.dex,那就根据最高的数字+1生成一个新的

修改完毕之后,打包测试,正常运行(由于诸位的脚本可能各不相同,所以这里只讲了思路,没有直接上代码)

接下来上报提审的时候,出现了问题,UC包在上传的时候回检测包体中的有没有他的sdk,但是他只会检测classes.dex文件,所以这时候还是需要将ucSDK中的一些核心类文件放在classes.dex中,具体怎么做,需要看渠道的检测,然后将那些被检测的类文件放进去就行了(由于只有可别渠道会出现这些问题,所以协力就不细说了)

由于现在还没想到完美的分包方式,就是确保所有渠道都会通过的方式,所以这里文章就叫(1)了

提一下:如果发现渠道检测的文件加入classes.dex中之后还是出现了方法数超限的问题,那就需要CP方,那边讲母包分一下包了

总结:

简单来说就是安装Google说的那套,加入android.support.multidex.MultiDex包

然后在application中加入MultiDex.install(this);

之后将渠道SDK放入classes2.dex中就行了

当然这一切都是都是用脚本实现的了,至于其中一些具体细节,回编译,jar转dex等,我就姑且认为诸位都会了,因为不会这些是打不出渠道包的

本文链接http://element-ui.cn/news/show-113.aspx