关于这个系列有两个开源库：
手游SDK框架Demo
打包Apk工具
如果对您有帮助，欢迎star
1.什么是游戏SDK
在介绍SDK框架搭建之前，先简单介绍一下游戏发布流程：
游戏 >- 接入应用商店/渠道SDK >- 应用商店/渠道上架游戏 >- 玩家
整个过程与其他产品应用类似。 所以这里的痛点就是各种应用商店/渠道SDK，给游戏带来了访问问题。 游戏需要对接不同的SDK，参数较多，接口不一致，后期维护更新，非常耗费人力。 很多开发者在这里很困惑：如果我们在通道层封装一个统一的外部接口不是很好吗？ 很简单的事情。 真的吗！ 这也是很多自研游戏公司最初的做法，就是简单封装渠道的SDK。 如果游戏只是想通过渠道方便地访问，那么这样做是没有问题的。
不过游戏图片，游戏SDK的作用不应该只是简单接入打包渠道那么简单。 原因简单分为以下几类：
1、用户，任何产品都应该有自己的用户体系，否则从长远来看是走不远的。 通常情况下，所有用户都是通过渠道平台吸引的。 这也是很多人羡慕微信的原因，因为微信拥有庞大的用户基础。 但要吸引流量，就需要付费购买用户。 购买的用户怎么办？ 他们会迷失吗？ 不可能的！ 您只能添加自己的标签成为自己的用户并与频道共享用户。 但游戏通常都有自己的游戏服务器，每个游戏服务器都有相应的账号系统，无法通用。 那么这个时候就需要有一个账户中心来管理用户，然后这些用户就可以玩自己的不同的游戏。 游戏SDK可以作为完美的过渡桥梁，甚至可以创建自己的渠道来吸引用户使用自己的帐户系统。
2.利润。 任何产品的利润来源都是基于产品的附加值和广告促销。 除了游戏附加值通过渠道红利带来的现金流外，游戏还有更多的与广告推广有关。 这会涉及到第三方广告SDK，或者您自己的广告SDK。
3. 数据。 任何产品的质量都是由数据来衡量的。 游戏用户数据、付费数据、玩家反馈等数据都是游戏质量的指标。 投资人/老板需要看这些才能知道市场上哪些游戏好。 挣钱。 这里会有一个数据上报SDK，用于上报和分析游戏数据。
综合考虑各种因素，游戏能做到这一点吗？ 是的，但是相对来说比较困难。 游戏是基于引擎开发的，更多的是对玩法的研究。 这时，这些需要考虑的因素更多的是由游戏的中间件来处理。 这就是我们的游戏SDK。
为此androidsdk游戏接入开发前途，游戏行业大致分为三大角色：游戏自研者、游戏发行商、游戏渠道商。 一般来说androidsdk游戏接入开发前途，游戏自研者更注重游戏产品的研发； 游戏发行商更多地负责游戏的发行和运营； 而游戏渠道商则更多地负责网络游戏产品的推广。
游戏自研 ---- 游戏发行 ---- 游戏渠道 ---- 玩家
腾讯、网易等巨头就是这些的综合体，拥有自己的游戏研发团队、游戏发行团队、游戏渠道团队。 但对于很多小公司，尤其是自主研发的小公司来说，他们没有那么多的渠道资源。 这个时候，他们就必须找到游戏发布的原因。 只有游戏能够通过大渠道发行，才有收入来源，游戏才能生存。
不过，这里会有一个利润分享比例。 很多自研公司辛苦制作的游戏交给发行公司后，分成比例很低，有的甚至可以被发行公司报废。 因此，很多自研游戏公司都想自己做发行，甚至创建自己的渠道，帮助别人上架游戏3D场景，以实现自身利益的最大化。
因此，游戏SDK的一般分类可以分为两类：
1、聚合SDK：封装各大渠道的SDK，提供统一的对外接口。
2、渠道SDK：公司自有的SDK通常具有用户入口、支付逻辑、数据统计等功能，可以封装成聚合作为自己的渠道使用。
2、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的架构设计，后续将更多关注客户端的设计与实现。 欢迎阅读下一篇文章...
如果您觉得我的文章对您有帮助，请不吝点赞。 您的支持将是我继续创作的动力！
