集成SDK——面向移动游戏联运——总体设计与思考

很多做游戏开发的人估计都或多或少接过了渠道SDK，比如UC，Dangle，91，小米，360...据统计，目前国内市场的渠道不下100个，包括一些没有SDK的小渠道。各通道的SDK接入方式大多相同。但是，正是这些微小的差异，使得SDK的接入，产生了无穷的变数。所以，在接入SDK之前，如果你没有经验或者没有被SDK骗过，当你看到这一系列文章的时候，你是幸运的，你可以避免这一切。如果你以前被困住了，并且继续被困住了，那么现在是你摆脱它的时候了。

完成一个SDK的访问并没有太多的技术含量，但是访问100个SDK就没那么容易了，而且维护简单，结构清晰，安全可靠一劳永逸。这也是为什么世界上有这么多打包工具和SDK访问方法的介绍...而且他们也不一样。

在这一系列文章中，我们来看看U8SDK aggregate SDK框架从无到有，从简单到完整的开发过程。这里先介绍一下初始框架的整体思路，以及U8SDK在实际使用中对方案的改进。

在我们开始开发U8SDK之前，我们可能有一个简单的头脑风暴:

1.首先，客户端需要访问多个传输通道SDK。为了让我们访问的SDK能够被多个游戏重用，我们不能直接访问游戏中的每个SDK，而是需要将游戏和SDK访问完全解耦。

2.为了将SDK访问从游戏中分离出来，我们需要抽象出一个SDK访问框架，屏蔽各种渠道SDK的差异，为游戏层提供统一的API调用；这样游戏只需要访问这个框架，不需要关心每个具体的联运通道SDK。

3.然后我们需要实现一个一键式打包工具。游戏层连接到上面抽象的统一API后，可以为Android生成一个父包apk，为iOS生成一个父项目(xcode项目)。然后通过一键打包工具，就可以打印出各种联运渠道的渠道包。

4.除了客户端部分，整套聚合SDK还需要服务器部分。服务器部分的逻辑分为两部分:核心业务服务和后台管理系统；核心业务服务主要处理各种渠道的登录认证和支付回调逻辑；后台管理系统主要处理游戏管理、频道参数配置、用户数据查询、订单数据查询、统计分析等功能。

鉴于上述几点，我们的聚合SDK框架应该包括以下部分:

接过渠道SDK的同学应该知道，对接渠道联运SDK最重要的两个功能点是登录和支付。在聚合SDK框架的设计中，这两个过程自然是最重要的。接下来，我们将设计整个聚合SDK的登录流程和支付流程。

我们先来看看登录流程。如果不使用聚合SDK框架直接访问SDK，那么渠道联运SDK的登录流程是怎样的？我们可以在这里看一下UC SDK的登录流程图:

使用聚合SDK后，游戏和渠道SDK要完全解耦；所以我们需要把游戏服务器和渠道SDK服务器的直接交互，变成聚合服务器和渠道SDK服务器的交互。我们来看看U8SDK中的统一登录流程设计:

我们来看一下整个登录过程的序列图，可以更直观的看到这个过程的顺序:

通过新登录流程和旧登录流程的简单对比，我们可以看到，在旧登录认证流程中，对于每一款游戏，游戏服务器都需要与各个频道SDK服务器进行交互；但使用聚合SDK后，游戏服务器只需要和U8服务器进行交互，U8服务器会完成第三方SDK的登录和登录认证。

接下来，我们来看看支付流程。如果不使用这个框架，可以直接访问游戏中的联运通道SDK，我们以UC SDK为例说明付费流程:

同样，使用聚合SDK后，游戏和渠道SDK也要完全解耦；所以我们需要把游戏服务器和渠道SDK服务器的直接交互，变成聚合服务器和渠道SDK服务器的交互。我们来看看U8SDK中的统一支付流程设计:

对比两个支付流程图，我们可以清楚的发现:在新流程中，游戏服务器和渠道SDK服务器通过聚合服务器完全解耦；各频道SDK功能的变化不会影响游戏服务器。我们再发一个序列图，更直观地看整个过程:

通过以上分析，我们大概了解了聚合SDK框架中需要实现的功能和相关流程。然后，我们将详细实现每一部分:包括抽象层SDK接入框架、一键打包工具、聚合服务器、通道SDK接入等等。

我们在哔哩哔哩录制了一个视频教程。如果对U8SDK感兴趣可以看一下:U8SDK视频教程。

同时，如果你也对手机游戏聚合SDK的开发感兴趣，欢迎关注U8SDK技术博客:www.uustory.com，也可以加入我们的聚合SDK技术交流QQ群:207609068(1600+手机游戏SDK相关技术人员)。