apk逆向工程之方法数超上限65535（1）

前段时间为游戏出渠道包，当拿到游戏母包的时候，有点吃惊，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等，我就姑且认为诸位都会了，因为不会这些是打不出渠道包的