引言：本文旨在提供读者制作一个自己的聚合SDK的思路，抛砖引玉，让更多的读者对聚合SDK有好的理解。
这是最好的时代，这是最坏的时代，这是智慧的时代，这是愚蠢的时代；这是信仰的时期，这是怀疑的时期；这是光明的季节，这是黑暗的季节；这是希望之春，这是失望之冬；人们面前有着各样事物，人们面前一无所有；人们正在直登天堂；人们正在直下地狱。——《双城记》
双城记的开头，正是现在手游行业的一种写照，充满着希望的行业，也伴随着混沌的行业。随着手游市场的蓬勃发展，不论从研发游戏，运营游戏，还是到发行游戏，维护相关的平台，整个行业都在不断的壮大。人上一百形形色色，游戏上一百，色色行行，渠道上一百，感叹活久见。
正是因为行业规模的庞大且新兴，很多事物并没有统一的业界标准。在任何一款游戏，要最终推到用户手上，不可避免的需要和各大渠道打交道。无论你是独立发行，还是联合运营，或多或少，会和App Store，Google play，国内各大发行渠道，阿里游戏，应用宝等等之类的打交道。而和他们打交道最直接的交互，就是需要接入相对应的sdk模块。
众多渠道的sdk良莠不齐，作为游戏开发商的cp，尤其是众多中小cp，第一次接入几家甚至几十家的渠道sdk已经需要花费巨额大的时间和人力成本，而当渠道sdk更新，需要将这些sdk再次接入到自己游戏中，又或者说，游戏发生了更新，需要重新的将这些sdk接入到自己游戏中时，则又要再次耗费巨大的时间和人力成本。聚合sdk正是基于这种情况下，才会被提出的概念。我们希望的，只是一个简单粗暴的，可以快速接入，没啥技术经验的人也能使用的一键式自动打包工具，只需要传一个工程文件，就可以直接出渠道包。
那么，我们就长话短说，我们来看看，我们要实现这套聚合的sdk，需要做哪些事情。
主要需求：
首先，我们需要明确想要做成的东西是个怎么样产品
1.游戏客户端和游戏服务端，只需要关注游戏本身内容，无需关注不同渠道的sdk差异性，降低渠道sdk和游戏客户端的耦合性
2.公司应用必须要支持多个项目的统一管理，但不能有集中式单点的风险，数据需要分离和整合不同的表现
3.公司发展后各种部门的交互流程和人员成本，让非技术的运营人员也可以打包，并且使用流程管理来进行出包版本管控
4.该聚合sdk必须要有扩展性，能应对日后新增的各种其他类型sdk。
主要模块：
针对这些需求，我们将产品分割为以下几个大模块。
1.用作客户端接入部分的统一框架 SDK_Client
2.用作服务端统一的逻辑转发和处理中心SDK_Server
3.用作打包功能的逻辑和多线程的任务调度SDK_Package
4.用户可视化操作界面和功能配置界面SDK_Manager
这四大模块，是我们最终的目标，一键式傻瓜化打包工具的组成。让用户只要传一个游戏项目，就能直接打出指定的渠道包。
主要的关系图：
接下来我们来看看主要的几个关系图
我们看看 packager的主要工作原理
1.取得相关游戏的配置文件
2. 取得指定渠道的配置文件
3.利用打包脚本，合成渠道包
4.提供渠道包的下载链接
manager和package组成客户端打包工具，manager负责管理和配置，package负责编译，关系图：如下
1.用户通过manager，上传一个原始的游戏
2.manager根据用户操作，找到相应的渠道SDK，渠道参数
3.manager分配给packager组打包的任务
4.packager 组找到空闲的packager节点，将该任务指定到具体的pakcager
5.选中的packager根据接收到的任务以及参数，打出指定渠道包
sdk的client和server与游戏客户端和服务端的交互架构
可以看到相对的结构图如上
1. 游戏渠道包，包含了游戏客户端以及聚合sdk客户端，渠道sdk三部分
2. 游戏客户端，将聚合sdk客户端发送过的sdk数据转发给游戏服务端
3. 游戏服务端，将游戏客户端发送的sdk数据转发给聚合sdk服务端
4. 聚合sdk服务端和渠道sdk服务端进行逻辑交互，以及相关的数据有效性验证，验证通过后，发回给游戏服务端正确的数据结果
5. 游戏服务端根据聚合sdk服务端返回的数据结果，处理游戏内的逻辑
6. 游戏客户端，将游戏服务端返回的经过验证后的sdk数据结果转发给聚合sdk客户端
以上所有，是我们对一套聚合sdk的总体架构以及构思的分析。整套我们最终目标要做成的一键式傻瓜化打包工具，是需要一步一个脚印，积少成多堆积出来的。但是有了明确的思路和方向，相信众读者会对聚合sdk不再陌生，也能更好的使用聚合sdk。
聚合sdk的其中每一个模块的具体实现，需要注意点，我们会在日后慢慢分析。
这个项目已开源，大家有兴趣可以自己研究或者参照项目编写自己的聚合SDK