小海终于有自己的家：欢迎坐下。

序言：许多从事游戏开发的人可能或多或少地接管了SDK频道，例如UC，，91，小米，360 ...根据统计，目前的国内市场目前拥有不少于100个渠道，包括一些没有SDK的小型渠道。 SDK访问每个通道的方法几乎相似。但是，正是这些很小的差异导致了对SDK访问的无限变量。因此，在访问SDK之前，如果您没有经验或没有被SDK欺骗，那么当您看到这一系列文章时，您很幸运可以避免所有这些。如果您以前被骗并且仍然被骗了，那么现在是您解放的时候了。

没有太多的技术内容可以完成对SDK的访问，但是它可以访问100个SDK，并且可以易于维护，清晰的结构，安全可靠，并且一劳永逸地做到这一点并不容易。这就是为什么包装工具的介绍如此之多的原因，以及SDK访问方法的引入……并且它们都不同。

随着手机游戏的爆炸，越来越多的人被骗了，总会有一些有能力的人不愿遭受痛苦，并开始使用大脑寻求一个可以为自己和他人服务的统一SDK访问框架。俗话说，如果有痛苦，就会有需求。因此，专门从事SDK访问这个小市场（或这个市场也很大）的公司或机构，例如 SDK，Easy 等。他们认为他们是时代的救世主。他们的外表将为大多数仍在忍受SDK访问遇到困难的孩子带来光明。但是，事实是什么？

这个统一的SDK访问框架本身与实际情况有一些矛盾。因为毫无例外，他们都要求，当游戏开发人员访问其抽象框架时，服务器端登录身份验证和付款回调将转到其服务器。但这是几乎所有游戏开发人员都不鼓励的。为什么？因为对于游戏开发人员而言，还有什么比用户数据和付款数据更重要？让这些数据放在别人的服务器上比让妻子在别人的家中睡两个晚上，这会更不舒服吗？

但是，像 SDK一样，这组事情真的很好。不，这有点心痛。因此，问题是，您可以将像公司自己的统一SDK访问解决方案实施并维护 SDK或框架吗？答案当然是。但是我需要努力工作一段时间，然后我将有空。因为这是第一次，每个频道SDK仍需要自行访问。但是，当您想到这些事情时，您将自己开发和维护它们，一个词：脚踏实地。哦，这是错误的，这是两个词。

在这一系列的教程中，我们将实施一组 SDK或类似于的棱镜。因此，让我们首先分析连接到SDK时需要实现的内容。

1。首先，客户需要访问多个SDK。为了重复使用多个游戏，我们无法直接访问游戏中的每个SDK，而需要将游戏和SDK分开。

2。由于上述SDK访问和游戏分离是分开的，因此我们需要抽象一个SDK访问框架。游戏只需要连接到此框架，然后使用每个频道SDK来实现此框架。

3。我们需要实现一个包装工具。包装100个频道是不可能的。手动单击一个人打包，这将杀死人。

4。在服务器端，我们还需要一个统一的用户登录身份验证中心和一个统一的支付中心，以支持多个游戏。

因此，我们的一组事情应该具有以下部分：

1。统一SDK访问框架

2。实施各种SDK访问

3。一键包装工具

4。统一登录身份验证中心和支付中心

好的，我们有一个总体想法。毕竟，我们只是 SDK之类的很棒的东西，我们怎么能没有名字？我们现在称他为U8 SDK。现在，让我们再次分析。通常，SDK访问有两个主要部分。部分是登录，部分是付款。那么我们的U8 SDK是相同的。我们需要计划整个登录过程和整个付款过程。

让我们首先查看登录过程。如果您不使用此框架并直接连接到SDK，则登录过程是什么样的？在这里，我们可以看到UC SDK的登录流程图：

1。“游戏客户端”调用“ SDK客户端”的登录功能。 “ SDK客户端”指导用户输入用户名和密码。当用户使用“ UC帐户”登录时，“ SDK客户端”调用“ SDK ”接口进行身份验证；

2。传递“ SDK服务器”的密码验证后，返回SID和与用户相关的信息（包括：UCID，用户昵称等）；

3。“游戏客户端”回电通知后，“ SDK客户端”可以从“ SDK客户端”获得SID；

5。“游戏服务器”可以从“ SDK ”请求SID验证（调用用户会话验证接口，请参阅“ UC Game SDK开发参考手册 - 服务器接口 - 有关详细信息”）；

6。“ SDK服务器”将SID的验证结果和相应的UCID返回到“ Game ”；

7。“游戏服务器”将SID，UCID和用户昵称的验证结果返回到“游戏客户端”

因此，我们现在将加入我们的统一登录身份验证中心，我们的框架适用于多个游戏，因此我们不能允许Game 直接与每个通道的SDK服务器进行交互，因此我们添加了一个统一的登录身份验证服务器，该服务器称为U8。因此，让我们设计为U8 SDK的登录身份验证过程：

1。客户端访问抽象SDK框架。根据当前的SDK频道，调用登录接口，然后传递用户名和密码以执行SDK登录操作。

2。SDK登录成功将返回信息，例如SID。

3。游戏客户端可以通过SDK抽象层接口获得此SID。

4。游戏客户端将此SID和信息应用于U8，然后访问U8，通道号和其他信息，并访问U8进行登录身份验证。

5。U8根据当前传递的频道编号对相应的SDK服务器进行身份验证。

6。SDK服务器身份验证成功，将返回SDK服务器上的用户信息。

7。U8获取用户信息，生成U8的统一用户信息并存储它。然后，立即返回客户。

8。客户​​端将其访问游戏服务器（主要是游戏登录服务器）

9。游戏服务器，将其使用到U8进行登录身份验证。

10。如果U8确定其有效，它将将用户信息返回给游戏服务器的当前用户。

11。游戏服务器获取用户信息，并证明当前登录成功。将其返回到客户端服务器列表和其他数据，并且登录成功。

让我们看一下登录身份验证的序列图，我们可以更直观地看到此过程的顺序：

您可以通过此新的登录过程和以前的旧登录过程之间的简单比较来查看。旧的登录身份验证过程需要与每个游戏服务器的每个通道SDK进行交互。但是，在新过程中，每个游戏服务器只需要与U8进行交互，并且U8将进行第三方SDK登录身份验证操作。同样，对于开发的每个游戏，客户端仅需要访问抽象SDK访问层，而不再需要访问每个频道的SDK。所有客户端操作和服务器操作只需要一次完成一次，这是可以的。

因此，接下来，让我们看一下付款过程。如果我们不使用此框架，我们将直接连接到SDK。付款是什么样的。让我们以UC SDK为例：

1。“游戏客户端”调用“ SDK客户端” API接口提交充值信息； “ SDK客户端”指导用户选择不同的充值方法并输入补给金额。

2。“ SDK客户端”将SID提交给“ SDK ”；

3。“ SDK ”收到充值请求后，它将将相应的“订单号”返回“ SDK客户端”；

4。“ SDK客户端”将通知“游戏客户端”的相应充值“订单号”到回调；

5。“游戏客户端”将接收到的“订单号”和相关的游戏角色信息（由游戏的自行决定）提交给“ Game ”；

6。“ SDK ”处理了充值请求后，它将异步通知“ Game ”。

7。“ Game ”将标志（或）返回“ SDK服务器”是否成功收到了补给结果。补给结果的成功或失败与这里的接收标志无关。无论补给是否成功，只要“游戏服务器”可以接收并识别补给结果通知，则应将成功标志返回“ SDK ”（）（）

因此，我们现在将加入我们的统一支付中心，该中心也针对多个游戏。因此，我们不能允许游戏服务器直接与每个通道的SDK服务器进行交互。我们还添加了统一的付款服务器，还将付款中心的功能添加到U8。让我们看一下新的付款过程：

1。游戏客户端首先请求游戏服务器进行充电

2。游戏服务器获取用户的ID和一些需要返回的数据，因为付款成功后，并访问了U8应用程序订单号。

3。U8生成了唯一的订单号，并且在数据库中生成订单记录，状态是付款状态

4。游戏服务器将订单号返回到客户端

5。在游戏客户端获得订单号之后，订单号和与游戏中充电有关的数据，请调用SDK抽象接口的付款接口，并调用相应的SDK付款接口以执行充电操作。

6。在调用SDK付款接口之前，当前的SDK频道实现需要将仅一合订单号放入频道SDK付款参数的自定义参数中。在每个频道中都是相同的。

7。频道SDK付款成功，状态将立即退回。

8。与此同时， SDK服务器将异步通知游戏开发人员付款回调地址集。请注意，访问游戏时，必须将此回调地址设置为U8提供的地址。

9.当U8收到基于验证结果的充值回调时，然后立即将成功或失败的状态返回到 SDK服务器。

10。然后U8根据自定义参数查询相应的订单信息，然后根据订单信息获取当前的用户信息和相应的游戏信息，然后在访问游戏之前将Game 提供的付款回调地址拨打到U8。此回调地址仅需要提供一个到U8。因为游戏服务器仅与U8进行交互。

11。游戏服务器会收到一个回调，以验证它是否成功，并且成功或失败的消息将返回给U8。同时，将游戏硬币添加到相应的玩家。

通过这种方式，通过比较两个付款流程图，我们可以清楚地发现新过程只能访问一次，并且可以一起使用多个游戏。然后，这是我们框架的付款过程。让我们发布一个序列图，以更直观地查看整个过程：

因此，通过对整个框架需要实施的功能的分析，我们设计了一组可以实现统一SDK登录身份验证和支付中心的体系结构。然后，接下来，我们将详细实施每个部分。包括抽象的SDK访问框架，如何访问游戏客户端进入此抽象SDK访问框架，如何将SDK从各个渠道集成到此SDK框架中，如何实现单击包装工具以及如何实现此统一的登录身份验证中心和付款中心。