引言：本文旨在提供读者制作一个自己的聚合sdk的思路，抛砖引玉，让更多的读者对聚合sdk有好的理解。
有了基本思路和架构，那么任何一个程序一个解决方案，都会有一个基本的设计原则。作为聚合sdk，我们要秉承哪些基本原则呢。
1.和游戏项目的低耦合性
2.聚合sdk具有易用性
3.具有较强的拓展性
1.先来探讨怎么去做低耦合性。
作为聚合sdk，最直接需要面对的问题就是跨平台问题。我们要先有一个概念，那就是游戏的开发平台以及游戏的发型平台是完全不同的。游戏的开发平台，是指游戏用什么语言，在什么样的生产环境开发。游戏的发行平台，指的是游戏在什么样的终端上运行。
实现的逻辑关系如下：
2.作为聚合sdk接入层，接入各大渠道自己的sdk代码实现部分，即各大发布平台的实现层，只需要在typesdk的框架下，实现各个逻辑接口的功能，而不用关心具体是谁去调用，是怎么调用的。
3.而开发平台的接口申明，发布平台的统一接口的规范，这一整套，就是聚合sdk客户端部分的主要框架。
4.接口的调用，和接口的实现完全的分离，实现了游戏逻辑代码和渠道sdk的解耦。整个聚合sdk体系相互独立，又相互有关，使得整体的功能实现，可以达到模块化，功能化，区分话的目的。让整个项目可以由多人共同开发，大大提高开发进度。
2.如何做聚合sdk具有易用性
人们都爱和简单的人相处，人们也爱使用简易容易上手的东西。iphone的成功，其中有一点那就是其外观的简洁，其系统的易于理解。
聚合SDK使用对象有两类，1.
说到简单，不得不提及一个和简单有关的词，统一，凡事简单的事物，都能让用户很快的形成统一的使用习惯。那么从代码设计上来说，统一中最具有代表性的就是，程序中的单例模式。
我们设计一个单利的类（TypeSDKClass），让用户的一切接口调用，回调函数接收，事件处理等等事物，都从这一个入口出发，也只从这一个入口导出，其内部结构无论如何复杂，用户不需要关心。他们只要记得，我想做一件事，我找到那个单例TypeSDKClass从他提供的方法和需要实现的回调中，都能满足我的需求就行。
并且，这个单例对象TypeSDKClass不需要关心他如何创建，如何销毁，只需要我想用的时候，随时随地能用。
有了单例对象为主体，在程序设计中，不可避免的是数据传递。
最易用的易懂的数据结构，hashmap类应该算其中之一。我们程序提供接口中传递的参数，使用的数据结构是一个经过包装过的hashmap，有一套容易理解的通过key来存取对应的value值。
用户并不需要关心这个数据结构在跨平台传递时候是如何工作的，只需要在使用的时候感觉容易理解，容易使用。
3.我们来说说拓展性
各大渠道的sdk都是发展的，各大发行平台同样也是在不断发展的，安卓从2.0已经成了现在的7.1，ios保持着一年一个大版本的稳定节奏，新老版本的更替，部分老的接口被弃用，部分新的接口被启用。更多的情况是，有了新的功能，来提升游戏的体验性和功能性。
作为我们的聚合sdk，要能保持与时俱进，才能不断绽放新的生命活力。而与时俱进最好的办法就是具有很强大的拓展性。
我们在游戏的发布平台，需要设计一个接口，该接口可以通过函数名来调用指定的函数，而该函数的参数，也需要是string类型。这样一来有几个优势。
1.函数名是string类型，接入聚合sdk的cp并不需要重新的更新开发平台（unity或者coco2dx）的聚合sdk部分，只需要新增几个string字段就能调用函数
2.参数是string类型，那就是可以把我们之前的hashmap类型数据转成string类型的json，既有了通用型，也不乏丰富性。
3.通过string类型函数名来执行函数，哪怕该函数不存在（例如运行设备版本过低，并不支持该功能），我们可以在发布平台层面，做相应的逻辑处理，而不会造成游戏的崩溃。
4.不论以后会有多少新的功能出现，我们做到了以不变应万变。一招鲜吃遍天。我们只需要不断的在运行平台的实现接口层面不断的新增新功能接口的实现，就可以做到，在游戏客户端部分，随时随地的使用到我们支持的新功能。
以上这些是博主对一套聚合sdk设计中，需要秉承的一些原则的看法，当然肯定还有其他的原则，比如代码规范中的hasmap数据结构类型的key值是string类型，而string类型的内容，要有统一的命名规则，这样可以避免因为书写的错误，造成数据操作的bug。
博主抛砖引玉，希望更多的读者不吝言辞，可以提出你们的看法和建议。
在下一篇，我们会主要讲解发行平台层面（安卓和ios）的聚合sdk实现详细思路和结构。让大家都能对聚合sdk有自己的看法和理解，最终能做出属于你自己的聚合sdk。