整套SDK的核心思想，就是让我们的SDK接入成本，能够控制在1，而不是N。啥意思呢？就是，我们接入第一款游戏的时候，我接了这些SDK，当我接入第二款，第三款游戏的时候，这套SDK可以尽可能的复用，而不是每开发一款游戏，又从头去接各个渠道sdk。所有的游戏都能够使用同一套SDK接入框架，来快速完成SDK的接入工作。那么，我们怎么做到呢？请看总体的思路：
打包工具原理图
游戏A，游戏B，游戏C是三款不同的游戏，对于他们来说，他们只需要调用SDK抽象层提供的接口，就完成了所有SDK的接入工作。这个时间，也就是几个小时的时间吧。
但是，我们知道，各个渠道SDK针对不同的游戏，都有不同的APPID，APPKEY等配置信息。所以，我们需要将这些配置信息也放在配置文件中。打包的时候，不同的游戏根据不同的配置，通过打包工具得到各个SDK的渠道包。
那么，像UC，当乐这些SDK是怎么接入的呢？
其实很简单，每个SDK接入，都是单独建立一个工程，引入SDK抽象层的jar包，然后，实现SDK抽象层中的插件接口。然后接好之后，会将SDK需要的资源，classes.dex，以及libs等需要的资源和代码，放在打包工具对应的SDK配置目录中。比如，UC的SDK，会在打包工具config/uc目录下，放置接好之后的SDK资源和代码。
同时，我们还需要两个配置文件。一个是channel.properties。我们用他来配置，该渠道的参数配置信息。比如APPID，APPKEY等。同时也配置下，需要将哪些目录拷贝到apk里面的哪些目录中。同时，各个SDK接入都需要在AndroidManifest.xml中配置一些activity，service，permission等。我们把这些信息，放在SDK_Manifest.xml中。然后打包的时候，将这个文件的信息合并到母包的AndroidManifest.xml中。
我们再来看打包工具。你可能会奇怪，打包工具是怎么将只接入了抽象层的游戏母包输出为各个SDK的渠道包。这里，我们就要来看看打包工具所做的工作：
打包工具流程图
1、打包工具的输入，就是需要打包的apk包，也叫母包。游戏里面引入sdk抽象层的jar包，调用抽象层的接口。完成接入，然后打成apk。
2、打包工具会首先用apktool d 对母包进行反编译。反编译到该渠道对应的临时工作目录中
3、重命名包名。我们知道在AndroidManifet.xml中的package就是包名，为了防止后面我们重新生成R文件导致冲突，我们对每个渠道都设置一个后缀。比如UC，后缀叫.uc。当乐，后缀.dl 等等。如果渠道SDK有明确要求，使用他们提供的后缀，那就使用他们提供的后缀。如果没有，就自己设置一个。
4、拷贝SDK资源。将该渠道对应的SDK资源，从对应的SDK配置目录中，拷贝到反编译后的临时工作目录中。
1）拷贝SDK的assets目录，libs目录，res目录等
2）将classes.dex也反编译成smali格式，拷贝到反编译临时工作目录中
3）和SDK_Manifest.xml中的内容合并到游戏目录的AndroidManifest.xml中。
5、生成游戏中需要使用的配置。
1）对于之前SDK目录中配置的APPID，APPKEY等信息，根据需要，对于需要添加到AndroidManifest.xml中的，我们就将他添加到AndroidManifest.xml中的meta-data中。
2）对于SDK目录下配置的插件信息，我们会在assets目录下，生成一个channel.properties文件。这样SDK抽象层会读取这个配置来实例化对应的插件。
6、重新打包，采用apktool b重新将合并之后的资源和代码，进行打包
7、签名和优化。部分渠道要求使用他们提供的签名文件，所以，我们对签名文件也采用了配置。可以根据不同的渠道来配置不同的签名文件。
8、经过以上步骤，一个渠道包就生成了。
通过上面这个打包流程，我们已经知道单个渠道包是如何生成的了。那么，像第一张图片中所表示的那样，我们打包工具是同时打出各个不同渠道SDK的渠道包。我们是如何来实现的呢？请看下图：
每个游戏，都有一个全局配置，里面配置了当前需要打包的渠道。这样，打包工具首先会读取该配置，然后按照上面的打包流程，对各个渠道进行打包。最终在输出目录下生成各个渠道对应的渠道包。
至此，我们对SDK里的打包工具有了一个比较全面的了解。但是，这还不够完善。比如，我们可以将参数从配置中脱离出来，采用界面化的管理方法。这样，你就可以将这套工具给运营或者策划去使用，程序开发人员，就不再需要负责打包的工作了。
打包的效率和速度上，也可以继续不断地进行优化。删除不必要的文件操作，减少不必要的流程等。