前言

根据上一篇游戏SDK（一） 客户端整体架构，介绍了游戏SDK 及 游戏SDK的需求分析。根据需求分析，对游戏SDK的设计分为3大块：

1. 客户端：接口统一，做好逻辑转发和处理。具体渠道具体实现，互不影响。
2. 服务端：接口统一，做好逻辑转发和处理。具体渠道具体实现，结果统一。
3. 打包工具：可视化界面，不同渠道的参数配置及平台统一参数配置。打包多任务管理等。

游戏SDK聚合渠道SDK的正常逻辑时序图如下：（以支付为例，登录类似）

根据以上需求分析及一般逻辑时序图，梳理一下游戏SDK的业务场景：

1. 游戏只接入 SDK 接口，不关心具体渠道的实现。不同的渠道是针对国内的，海外基本就是 Google Play 和 Apple 渠道。
2. SDK的业务主要集中在登录、支付、数据上报。
   1. 登录主要是注册、登录、绑定、切换账号。不同的游戏类型需要的登录流程可能不一样，这也是在设计SDK架构时需要考虑的，比如休闲游戏不需要登录界面，使用游客登录，重度手游一般需要登录界面。海外包含的登录有Facebook登录、Twitter登录、Google 登录等，国内的登录包含手机号登录、微信、QQ 登录，不同渠道选择的登录方式不一样。
   2. 支付逻辑主要包含：渠道支付、补单。海外的支付有：Google 支付、Apple支付，在某些国家也有可能有PayPal等第三方支付方式。国内的还会有支付宝、微信支付。另外还有SDK平台的积分点等平台币支付。
   3. 数据上报逻辑：数据上报的渠道也有可能不同，比如海外的是Facebook、Appsflyer等，国内的可能是 Talkingdata 等。同时有些游戏SDK还会开发自己的数据统计平台。
3. SDK插件无痛拔插。有时候A游戏需要 SDK 内的A插件功能，比如平台币支付功能，但是在B游戏上线到Google 平台时又不需要此功能，或者需要新增其他功能等等不同的业务场景。
4. 平台开发的公共辅助功能，比如网络检测、日志上报、激活码兑换码等等，这些属于平台开发的辅助游戏功能，不区分渠道。
5. 除了以上业务逻辑外，还需要考虑CP快速接入已经快速打不同的渠道包，这时候就需要一个打包工具以及相关配置后台。（这部分暂时先不讨论）
6. 游戏SDK需要一个测试demo，同一个demo可以切换不同的渠道测试。（其实这里就相当于本地的打包工具）

如果针对不同游戏不同的需求，我们都需要出不同游戏SDK，不仅工作量大，还需要大量人力来维护。CP接入也非常不灵活，因此考虑设计一个通用的游戏SDK架构。

游戏SDK架构设计

大体的项目结构如下：

- sdk-demo  // sdk 测试 demo 
- sdk-api   // sdk 接口模块
- sdk-manager    // sdk 业务分发管理
- sdk-channel   // 登录支付渠道
	- sdk-channel-huawei  // 具体的渠道sdk ，这里仅做示例
	- sdk-channel-xiaomi
	.... // 其他
	- sdk-channel-googleplay  // 公司自行开发的Google play渠道sdk 也放在这一层
	- sdk-channel-guoneiguanwang    // 公司自行开发的国内官网渠道sdk 也放在这一层
- sdk-data    // sdk数据上报
	- sdk-data-appsflyer   // AF 数据上报 ，这里仅做示例
	....// 其他
- sdk-plugin   // 游戏sdk插件
	- sdk-plugin-yuyin   // 语音插件，这里仅做示例
	...    // 其他
- sdk-core // 游戏SDK公共业务
- sdk-common // 基础库
- buildSrc   // 一些打包编译脚本
- doc  // 文档
...  // 其他分类看项目需要

游戏SDK架构介绍：

游戏SDK项目整体采用模块化开发。（其实可以使用组件化开发，但是做好打包脚本就没有必要使用组件化开。）

1. API层： CP只需要接入这一层，不需要关注其他的业务及渠道。这一层定义接口，包括初始化、登录、支付、其他接口、环境切换等。
2. 业务分发层： 在这一层做渠道分发管理，当CP调用到接口时，如果通过配置文件分发到不同的渠道实现。当渠道有返回结果时，在该层统一返回接口层。游戏数据上报的平台有很多，国内与海外也不一样，不同的项目选择上报的数据平台也不一致，比如A游戏上报到Facebook、firebase，B游戏上报到 talkingdata、appsflyer，如何分发也在这里处理。
3. 渠道业务层： 这里主要是不同渠道的具体实现，包括：初始化、登录、支付、数据上报、绑定账号、切换账号、退出等等接口。
   1. 对于国内的各个渠道集成渠道SDK即可，例如华为渠道，登录接口集成华为SDK的登录接口即可。
   2. 对于海外Google play 渠道：一般是由公司开发封装成一个渠道SDK，包括功能有登录（公司平台账号登录、第三方登录比如Facebook、Twitter的登录等），支付（Google pay），绑定账号、登出账号、退出游戏，权限申请等。这个公司自行开发的渠道SDK后面可以单独开一篇说明。
   3. 对于国内官网渠道：一般是指公司自行开发封装的一个渠道SDK，将APK放到公司官网上，供玩家下载。包括功能有登录（公司平台账号登录、第三方登录比如qq登录、微信的登录等），支付（支付宝、微信支付 ），绑定账号、登出账号、退出游戏，权限申请、协议弹窗等。
4. 数据业务层： 聚合不同的数据上报平台SDK，比如集成FB、firebase等。如果公司有自己的数据统计平台，在这一层作为一个数据统计平台开发。
5. 公共业务层： 激活码功能、用户自动补单功能等这些不是渠道特有功能如果在渠道实现，不同的渠道就需要实现多遍，这显然不合理。再者，作为一个游戏SDK，会有游戏SDK的平台，平台如何管理渠道用户及管理用户的支付等相关信息，也需要在渠道登录之后，统一转换为游戏SDK平台的用户，这个操作是统一的，公共业务实现。
6. SDK插件层： 不同的游戏项目需要的功能不一样，比如网络检测插件检测用户手机网络是否通畅对于重度手游来说比较必要，但是对于休闲游戏就不必了。作为插件可以由不同项目各自选择。
7. 基础库： 共工具类，包括网络工具、文件工具等。这个工具模块和公共业务模块不一样，这个模块的工具类和业务无关，可以放到任何项目使用。公共业务模块也会有工具类，但是这些工具类和业务相关。另外，在这里的工具类，有UI的和没有UI的建议分开处理，方便后续剥离。
8. 文档： 做游戏SDK的，文档是必不可上的，除了一般的开发文档介绍需求、技术实现原理外，还需要一份简洁易懂的接入文档提供给CP。

以上对游戏SDK架构设计作了说明和介绍，代码如何实现且看下回分析。