序
工欲善其事，必先利其器
由上一篇Android手游发行兵器谱可知，统一SDK的想法来源于设计分享工具ShareSDK。同样的中心思想，可是其本质却有着不一样一面。如下图对比：
ShareSDK原理思想：
统一SDK原理思想:
由上图可知，ShareSDK的方式是集成，就是如果你想分享渠道有多少个，那么ShareSDK就会把相应的分享SDK都加入都一个包中，形成一个集成渠道的包。统一SDK的方式的嵌入，替换方式嵌入，就是统一个SDK包中无法共存着两个渠道的SDK，即如果统一SDK已经接入了UC,该SDK只能是UC统一SDK,无法再在这个UC统一SDK中加入其它渠道SDK,即使这样，他们的接口却要保持高度的一致，即百度统一SDK和UC统一SDK的接口都是一样的。导致这两种方式不一致的主要原因是游戏包的大小。一个渠道SDK小的5M,大的10M左右，如果把这些渠道SDK都集成在一起，并且接入到游戏中的话，游戏的包体就变得异常的大，所以没有采用集成的方式，分享的SDK的只是代码块，极少存在图片资源，加密资源所以相对会小很多。
法则：
经上述理解之后,下面进入紧张的打造兵器阶段。
首先先看我去年在完成统一SDK之后，准备升级统一SKD之前做的一个市场竞品调查分析(因为涉及公司利益，所以抽取其核心部分)。
分析报告的下载地址：http://download.csdn.net/detail/a_asinceo/9063747
由该表可以得出一批统一的接口，分别为，1.初始化2.登录3.支付4.退出5.注销6.资源回收7.用户中心8.提交玩家信息9 页面的生命周期，因此报告其实对于刚开始做统一SDK的人员来说非常重要，在于竞品之间的对比，可以得出共性，知道什么是必须做，什么是不是很必须的。以下我就抽取几个重要的接口来说明一下。
法则一：初始化
渠道商的SDK基本上都会有初始化的接口，用来初始化SDK的一些状态和验证游戏的真实性(appid是否存在)。很多渠道SDK在初始化的接口上都需要游戏传入相应的渠道参数，而这些参数通常没有特定的字段名称，特定的方法名传入，特定字段属性，所以统一SDK的需要担任起其中任务，让这些不特定的因素隐藏起来，给予游戏一个特定的元素，这一原理也运用于其他接口中.
因此统一SDK的做法如下：
1.GameId是统一SDK服务器生成的游戏对应的唯一标示id,该id保存在Gameinfo表中，该表还保存其他一些游戏属性数值，例如该游戏货币名称，游戏货币比率，用于验证的appkey等，固定不变的数值。平台id是统一SDK根据不同平台分配的特定id值，如UC的平台id为1，百度为2，所以Gameid来代表游戏，平台id来代表渠道，两者结合起来就可以找到某游戏某平台id下的平台信息，平台信息保存在平台信息表中，字段包括GameId和平台Id,以及第三方平台的参数信息。
2.获取到第三方平台信息之后，即可对第三方平台SDK进行初始化。
3.处理初始化结果。
注意：与服务器的交互协议细节都不给出来，但应该尽可能地预留多扩展字段。
法则二：登录
登录接口，涉及最多问题的就是用户的唯一标示，因为在目前的手游行业，几乎所有的游戏都是混服的，所以用户的唯一标示就显得异常中，在我的人生经历中，经常会出现这样的一个问题，用户角色找不回。导致这个问题出现就最根本原因就是用户id没有保持唯一，所以用户id的唯一性必须拥有。
由于不同平台之间可能存在相同的用户id，所以我们需要为这些用户id作区分，所以我把这个工作交给了cp自己来做。我的意思是，把获取到的第三方平台的用户id,简称userid，第三方平台id，即platformId都交给游戏，让游戏来创造一个用户唯一标示。例如他们可以利用platformId_userid的形式，可以采用userid_platformId等形式创造。
这样做的好处有2个：
第一，游戏在需要查找用户的时候，更容易看出真正的第三方平台id
第二，游戏在统计用户的时候，可以区分平台。
缺点就是游戏需要多做工作。
在做统一SDK的登录接口的时候，我没有采用现在流行的token的形式，只是做了加密验证，当然这里这个加密验证也不是简单的MD5。但目前token的形式的确会安全一点，至少减少用户刷登录。
统一SDK的登录流程：
1.游戏平台需要做账户验证，有些平台则不需要。
2.之所以账户验证与获取签名分为两个步骤，是因为这两个获取签名是一个固定逻辑的方法，而账户验证可能需要根据不同平台的参数拥有不用的验证逻辑。
3.要求CP的账户验证在服务器端进行，是因此不要在客户端暴露信息，增加账户安全性。
法则三：支付
支付接口的调用相对登录接口就简单多了，这里主要涉及一个关键要素统一SDK的orderid。该id在支付前传到第三方SDK的服务器，第三方SDK服务器在完成这一笔支付之后，通知统一SDK的时候，需要把这个订单号带上，以便统一SDK的服务器可以找到这一笔订单，从而修改订单状态，发货通知游戏服务器。
由于客户端存在破解的问题，所以支付结果都是由服务器发出为准，因此这里要求游戏应该与其服务器保存长连接的关系，从而发货通知由游戏服务器发起。为何不建议使用短连接？游戏可以在收到客户端支付完成的回调的时候去轮询服务器是否又充值成功的订单。这种方式存在一个问题，如果SDK客户端因为某种异常没有发出回调，则游戏客户端就出现掉单的现象。所以最好的方式就是保持长连接。
支付流程如下：
法则四：框架
与以上统一SDK的中心思想一样，SDK的业务逻辑都写在框架层，这样SDK的实现层每接入一个第三方SDK,只需要修改实现层中的代码，这些实现层代码正是调用第三方SDK业务的代码。因此统一SDK的框架是对整个SDK的接入作一个高度的业务逻辑的统一，使代码的实现与业务逻辑完全分离，其中的好处就是----------是个程序猿都懂的。
总结：
当然，以上的法则正是整个统一SDK的灵魂精髓，它不但清晰的描述了业务逻辑，也规范了游戏CP的接入，同时也有着很好的扩展性能。代码的优越 就是在于代码是否稳定，是否可扩展，是否可阅读。因此有了以上的详细说明，整个统一SDK的图纸应该可以在脑海中生成了。
写在文章的最后，这里只给出了重要的几个接口流程，其他的接口流程就很少存在与服务器之间的交互，所以不再一一说明，如果有感兴趣的，可以留言，我会解答的。
Ps:码字真不简单，不要那么快留言，我要喝口水先。