手游SDK — 第一篇（序言）

各位看官，大家好！这个系列的文章的目的是跟大家介绍下什么游戏SDK，也是自己工作的一些总结。希望看完这个系列文章可以帮助大家快速搭建客户端的SDK架构方案及打包系统解决方案。

• 手游SDK — 第一篇（序言）
• 手游SDK — 第二篇（SDK架构设计篇）
• 手游SDK — 第三篇（SDK架构设计代码实现篇（上）- 基础库）
• 手游SDK — 第四篇（SDK架构设计代码实现篇（下）- 项目需求开发）
• 手游SDK — 第五篇（游戏打包篇（上）- 打包系统设计）
• 手游SDK — 第六篇（游戏打包篇（中）- 自动化打包）
• 手游SDK — 第七篇（游戏打包篇（下）- 自动化打包踩坑记录）
• 手游SDK — 第八篇（游戏打包番外篇- 桌面UI设计）
• 手游SDK — 第九篇（浅谈适配H5游戏）

关于该系列有两个开源库：
手游SDK框架Demo
PackageApkTool
如果有帮助到你，欢迎star

一、什么是游戏SDK

在介绍搭建SDK框架之前呢，跟大家大概介绍下游戏的发布流程：

  游戏 >- 接入应用商店/渠道SDK >- 应用商店/渠道上架游戏 >- 玩家

整个流程跟其他产品app都是相似的。所以这里痛点问题就是应用商店/渠道SDK各种各样，给游戏带来的接入难题。游戏需要接入不同的SDK，参数多、接口不统一，还有后期的维护更新都是很大的人力成本。在这里很多开发者就疑惑了：我们在渠道层封装一层对外的统一接口不就好了么？很简单的事情哈。确实！这也是很多游戏自研公司刚开始的做法，简单的封装渠道的SDK。如果游戏只是想简单的上渠道而已的话，这样子做是没有任何问题。

但是，游戏SDK的作用不应该只单单是接入封装渠道这么简单。下面简单分几类来说明下原因：

1、用户，做任何产品都应该有自己的用户体系，不然是没法走长远的。通常情况下所有的用户都是通过渠道平台进行引流的。这也是很多人羡慕微信的原因，因为微信有巨大的用户基础。但是引流就需要交钱买用户。买来的用户怎么办，流失么？不可能！只能打上自己的标签变为自己用户，跟渠道共享用户。但是游戏通常都会有自己游戏服务器，每个游戏服务器都有对应的账号体系，是没办法通用的。所以这时候就需要一个账号中心来管理用户，然后这些用户就可以玩自己的不同游戏了。而游戏SDK刚好可以作为中间桥梁完美过渡，甚至自己做成渠道，引流用户到自有的账号体系。

2、利润，任何产品的利润来源都是基于产品的附增价值和广告推广。游戏除了跟渠道分红游戏附增价值带来的现金流，还有更多的是广告的推广。这里就会涉及到三方的广告SDK，也可以是自有的广告SDK。

3、数据，任何产品的好坏都是数据来衡量的，游戏用户数据、支付数据、玩家反馈等数据都是衡量游戏质量的指标，投资人/老板需要看这些，才知道市场上什么游戏能挣钱。这里就会有数据上报的SDK，将游戏数据进行上报分析。

综合各方面的因素，游戏能做这些么？可以，但是相对比较难。游戏是基于引擎开发的，更多的是做游戏玩法的研究。这时候这些要考虑的因素更多的让游戏的中间件来做处理。也就是我们的游戏SDK。

基于这样的原因，所以游戏行业大概就会分为三大角色：游戏自研商、游戏发行商、游戏渠道商。通常游戏自研商更多、更专注的做游戏产品的研发；而游戏发行商更多的负责游戏的发行和运营；游戏渠道商更多的是上线游戏产品做推广。

    游戏自研  ---- 游戏发行 ---- 游戏渠道 ---- 玩家

像腾讯、网易这样的巨头就是这些的综合体了，有自己的游戏研发团队、游戏发行团队、游戏渠道团队。但是对很多小公司来说，特别是自研的小公司没有那么多的渠道资源，这时候就必须找游戏发行的原因，游戏能上大的渠道发行，才会有收入来源，游戏才能活。

但是呢，这里就会有利益的分成比例了，很多游戏自研公司辛苦做出来的游戏给到发行公司后，分成比例很低，甚至有些还能被发行公司搞废了。所以很多游戏自研公司都想自己做自己的发行，甚至做成自己的渠道，帮别人上架游戏，做到自己的利益最大化。

所以，游戏SDK的大体分类就能分为两种：
1、聚合SDK：封装各大渠道的SDK，对外统一接口。
2、渠道SDK：公司自有的SDK，通常会有用户入口、支付逻辑、数据统计等功能，可以封装到聚合中当成自己渠道。

二、SDK的需求分析

项目的需求：做成什么样的产品？

1、游戏客户端和服务端只需要关注游戏本身内容，无需关注不同渠道的SDK的差异性，降低渠道SDK和游戏客户端的耦合性；
2、必须有拓展性，能应对日后新增的各种类型SDK，不局限与渠道SDK；
3、必须能统一性的管理多个项目、多个渠道SDK配置、其他类型SDK配置；
4、方便后续的交互流程、人员交接成本、做到非技术人员也可以通过流程管理和版本控制来发布对应的游戏版本，上架不同的渠道。

项目的设计功能模块：

1、客户端接入部分统一框架，并做好逻辑转发和处理；
2、服务端接入部分统一框架，并做好逻辑转发和处理；
3、游戏打包部分，做好用户可显化操作界面和配置界面，后台处理打包多任务的逻辑调度任务。

项目设计思路：

SDK架构设计图.png

整体架构设计分为四部分：游戏渠道包、游戏服务器、SDK服务器、渠道服务器
1、游戏渠道包：包含游戏资源、SDK资源、渠道SDK资源；
2、游戏服务器：接收聚合SDK的数据，并将数据转发到SDK服务器，做数据校验；
3、聚合SDK服务器：处理聚合SDK客户端上报的渠道数据和游戏转发的数据，与渠道SDK做数据和逻辑交互。
4、渠道服务器：处理渠道SDK上报数据和聚合SDK服务器数据逻辑。

逻辑时序图：

登陆.png

支付.png

PS：这里有个关注点就是，游戏的发货流程是服务端通知发货还是客户端回调发货，这个到时可以根据具体情况分析。

三、总结

哈哈，各位看官，讲个这么多不知道有没有将明白，这篇开篇的废话比较多，而且涉及的面比较广，我也只能大概概括下整体项目的思路。还希望多多指教。因为这是针对手游SDK的架构设计，后续更多的是关注客户端的设计实现。欢迎走到下一篇...

如果觉得我的文章对你有帮助，请随意赞赏。您的支持将鼓励我继续创作！