Xiao Hei finally has his own home: http://www.uusstory.com/ , welcome to sit down.
Inscription: Many people who do game development are estimated to have taken over the channel SDK more or less, what UC, Dangle, 91, Xiaomi, 360... According to statistics, there are currently no less than 100 channels in the domestic market. Including some small channels without SDK. The method of accessing the SDK for each channel is mostly the same. However, it is these small differences that make the access of the SDK produce endless variables. So, before accessing the SDK, if you have no experience, or have not been pitted by the SDK, then when you read this series of articles, you are lucky, you can avoid all this. If you have been trapped before, and you are still being trapped, now is your moment of liberation.
There is not much technical content to complete the access of one SDK, but it can be connected to 100 SDKs, and it can be easy to maintain, clear in structure, safe and reliable, and it is not so easy to do it once and for all. This is why there are so many introductions of packaging tools and SDK access methods in the world...and they are also different.
With the outbreak of mobile games, more mobile games are being made, and more people have been cheated. Then there will always be some talented people who are not willing to suffer, and start to use their brains to seek a set of services that can serve themselves and serve. A unified SDK access framework for others. As the saying goes, where there is pain, there is need. Therefore, SDK access to this small market (or this market is also very small) has emerged, such as Prism SDK, AnySDK, Easy Access and other companies or institutions that specialize in SDK access. They consider themselves the saviors of the age. Their appearance will bring a bright light to the vast number of children's shoes who are still enduring the hardship of SDK access. However, in fact?
This unified SDK access framework itself has some contradictions with the actual situation. Because, without exception, they all require that game developers go to their servers for server-side login authentication and payment callbacks when accessing their abstract framework. However, this is what makes almost all game developers discouraged. why? Because, for game developers, what is more important than user data and payment data? Isn't it more uncomfortable to let these data go to someone else's server than to let their wives sleep in someone else's house for two nights?
However, things like Prism SDK and AnySDK are really good. No, it's a little bit painful. So the question is, can you implement and maintain a framework like Prism SDK or AnySDK yourself, as the company's own unified SDK access solution? The answer is, of course. It's just that he needed to be forced once, and then he was freed. Because for the first time, each channel SDK still has to be connected by itself. However, thinking that these things are all their own, develop and maintain by themselves, one word: practical. Oh, wrong, two words.
In this series of tutorials, we will implement a set of things like Prism SDK or AnySDK from beginning to end. So, let's first analyze what we need to do to access an SDK.
1. First, the client needs to access multiple SDKs. In order to reuse multiple games, we cannot directly access each SDK in the game, but need to separate the game and SDK access.
2. Since the above mentioned that the SDK access and the game are separated, then we need to abstract an SDK access framework, the game only needs to access this framework, and then each channel SDK implements this framework.
3. We need to implement a packaging tool. It is impossible for 100 channel packages to manually click and package one by one, which will kill people.
4. On the server side, in order to support multiple games, we need a unified user login authentication center and a unified payment center.
Therefore, our set of things should have the following parts:
1. Unified SDK access framework
2. Each SDK access implementation
3. One-click packaging tool
4. Unified login authentication center and payment center
Okay, the overall idea is there. We are also similar to Prism SDK and AnySDK. How can we not have a name? Let's call him U8 SDK for now. Now, let's analyze it again. Generally, SDK access has two parts. Part is login, part is payment. Then our u8 sdk is naturally the same. We need to plan the entire login process and the entire payment process.
Let's look at the login process first. If you don't use this framework and directly access the SDK, what is the login process? Here we can see the login flow chart of the UC SDK:
1.“游戏客户端”调用“SDK 客户端”的登录功能，“SDK 客户端”引导用户输入 用户名密码，当用户使用“UC 账号”登录时，“SDK 客户端”调用“SDK 服务器” 接口进行身份验证；
2.“SDK 服务器”密码验证通过后返回sid 及用户相关信息（包括：ucid、用户昵 称等）；
3.“游戏客户端”在“SDK 客户端”回调通知后，可向“SDK 客户端”获取sid；
5.“游戏服务器”可向“SDK 服务器”请求验证sid（调用用户会话验证接口，详见《UC 优视游戏SDK 开发参考说明书-服务器接口》）；
6.“SDK 服务器”将sid 的验证结果和对应的ucid 返回给“游戏服务器”；
7.“游戏服务器”将sid 的验证结果及ucid、用户昵称返回给“游戏客户端”
那么，我们现在要加入我们统一的登陆认证中心，而且，我们这个框架，本身就是针对多款游戏的，所以，我们不可以让游戏服务器直接和每个渠道的SDK 服务器进行交互，所以我们增加一个统一登陆认证服务器，姑且叫U8 Server。那么，我们就设计一下u8 sdk的登陆认证流程：
1、客户端接入抽象SDK框架，根据当前具体是哪个SDK渠道，调用登陆界面，然后传入用户名和密码，进行SDK登陆操作
2、SDK登陆成功，会返回sid等信息
3、游戏客户端可以通过SDK抽象层的接口，获取到这个sid
4、游戏客户端拿着这个sid以及接入之前向u8 server申请的appid,渠道号等信息，Http访问u8 server进行登陆认证。
5、u8 server 根据当前传递的appid, 渠道号，去对应的SDK服务器进行认证
6、SDK服务器认证成功，会返回SDK服务器那边的用户信息
7、U8 Server拿到用户信息，生成一个u8 server统一的用户信息并存储。然后，紧接着返回给客户端一个有效的token。
8、客户端拿着这个token，去访问游戏服务器(多数是游戏登陆服务器)
9、游戏服务器，拿着这个token去u8 server 进行登陆认证。
10、u8 server 判定token有效，则返回给游戏服务器当前用户的用户信息
11、游戏服务器拿到用户信息，证明当前登陆成功，返回给客户端服务器列表等数据，登陆成功。
我们再看一个登陆认证的顺序图，可以更直观地看到这个流程的顺序：
通过这个新的登陆流程和之前老的登陆流程进行一个简单的对比，大家就可以看出。老的登陆认证流程，对于每一款游戏的服务器，都需要和每个渠道SDK进行交互。但是新的流程，每个游戏服务器只需要和U8 Server 进行交互就可以了，全部由U8 Server进行第三方SDK的登陆认证操作。同样的，每开发一款游戏，客户端也只需要接入抽象的SDK接入层，而不再需要去接入每个渠道的SDK了。所有客户端的操作，和服务器端的操作，都只需要做那么一次就OK了。
那么，接下来，我们再来看看支付流程，如果不使用这套框架，我们直接接入SDK，支付是什么样子，我们以UC SDK为例：
1.“游戏客户端”调用“SDK 客户端”API 接口，提交充值信息； “SDK 客户端”引导用户选择不同的充值方式，输入充值金额。
2.“SDK 客户端”将sid、gameid、serverid 以及对应的充值信息提交给“SDK 服务器”；
3.“SDK 服务器”接收充值请求后，将返回对应“订单号”给“SDK 客户端”；
4.“SDK 客户端”将回调通知“游戏客户端”对应的充值“订单号”；
5.“游戏客户端”将接收到的“订单号”及相关的游戏角色信息（由游戏自行决定） 提交给“游戏服务器”；
6.“SDK 服务器”在处理完充值请求后，将通过异步方式通知“游戏服务器”充值 结果。
7.“游戏服务器”向“SDK 服务器”返回是否成功接收充值结果的标志（SUCCESS或FAILURE）。充值结果的成功或失败与此处的接收标志无关，不论充值是否成功，只 要“游戏服务器”能够接收并识别充值结果通知，都应该向”SDK 服务器“返回成功标 志（SUCCESS）
那么，我们现在要加入我们统一的支付中心，同样针对多款游戏的，所以，我们不可以让游戏服务器直接和每个渠道的SDK 服务器进行交互，我们也增加一个统一支付服务器，我们把支付中心的功能也加到U8 Server里。我们再看下新的支付流程：
1、游戏客户端，首先请求游戏服务器要充值
2、游戏服务器拿着该用户的id和一些支付成功之后需要原样返回的数据，去访问U8 Server申请订单号
3、U8 Server生成一个唯一的订单号，同时数据库中生成一条订单记录，状态是正在支付状态
4、游戏服务器将订单号返回给客户端
5、游戏客户端，拿到订单号之后，带着订单号以及游戏里充值相关的数据，调用SDK抽象接口的支付接口，调用对应的SDK支付界面，进行充值操作。
6、当前SDK的渠道实现在调用SDK支付界面之前，需要把刚刚的订单号，放到渠道SDK支付参数的自定义参数中。这个每个渠道都是一样的。
7、渠道SDK支付成功，立马返回一个状态
8、同时，渠道SDK服务器会异步通知游戏开发商设置的支付回调地址。注意，游戏接入的时候，这个回调地址要设置到u8 server提供的一个地址。
9、u8 server收到充值回调，根据验证结果等判定，立马给渠道SDK服务器返回一个成功或者失败的状态。
10、然后u8 server根据自定义参数中的orderID，查询到对应的订单信息，再根据订单信息，获取到当前用户信息和对应的游戏信息，然后调用接入游戏之前，游戏服务器提供给u8 server的支付回调地址。这个回调地址，游戏服务器只需要提供一个给u8 server就可以了。因为游戏服务器只和u8 server交互。
11、游戏服务器收到回调，验证成功与否，里面返回给u8 server一个成功或者失败的信息。同时，给对应的玩家加游戏币。
这样，大家通过对比两个支付流程图，可以清晰地发现，新的流程，可以做到只接入一次，后面多款游戏，可以共同使用。那么这个就作为我们这个框架的支付流程。我们再发个顺序图，可以更直观地看下整个流程：
所以，通过对整个框架需要实现的功能的分析，我们设计了一套可以实现统一SDK登陆认证和支付中心的架构。那么接下来，我们就会具体的来实现每一个部分。包括抽象的SDK接入框架，游戏客户端怎么接入这个抽象的SDK接入框架，各个渠道SDK怎么整合到这个SDK框架中来，怎么实现一键打包工具，怎么实现这个统一的登陆认证中心和支付中心。