由于实际需求，项目可能要分发多个渠道，接入融合的sdk是当前情况的首选。但是当我们接好融合sdk，不同的子包sdk接入之后，不同的sdk有自己独特的表现方式，导致一个不可描述的bug出现，这种bug可能只在某个sdk下才会出现的。
那么我们面临的情况就是logcat下这个子包，发现可能的问题，出一个融合的母包交给发行，发行那边再出一个子包测试，解决的话，皆大欢喜，不行的话，如此循环。效率低不算，还涉及多方的协同合作，时间线拉的比较长，出现疑难杂症的话，迟迟得不到解决，非常的影响心情。
为了解决这种情况，那么下面提供一个比较快捷的测试方法，即不需要涉及到发行打子包的操作，我们自己出完包，就可以同步修改到子包上面的方案。
一、需要准备的工具
1、你需要可以运行jdk的环境，以及apk解包工具apktool，这里使用的是apktool-2.3.4.jar
二、了解原理
1、可以使用命令java -jar apktool-2.3.4.jar d -f aa.apk -o bb
aa.apk是你要解包的apk，bb是解包之后生成的文件夹名字。
android工程通过解包之后，一般的目录结构都是固定的，如下面所示
smali文件目录就是我们android代码编译之后的产物，不管是我们的代码，亦或者是sdk的代码都是在这里有对应的生成文件。举个例子，下面就是smali目录下面可能有的文件夹
例如okhttp3文件，他的前身就是okhttp3.x.jar包，我们写的代码一般都是在com文件下面，认准自己代码的文件夹名即可。
三、实际操作
大致的操作流程就是，首先，我们修改代码之后，打一个包，打好包之后通过apktool去解开这个包，得到上面说的目录；然后把有问题的子包也是解开出现上面的目录，然后两个目录进行对比，把smali目录下面，自己代码相关的目录直接对比到子包的smali对应目录下。最后把子包达成apk进行调试。
综述，有了上面的操作方式，不管要怎么实验我们的修改都可以自己一个人搞定。摒弃了多方协同的情况，在相同的时间内，可以出更多的apk去测试我们的修改是否可行，效率得到了倍数的提升！