TypeSDK总体设计思路和架构

引言:本文旨在提供读者制作一个自己的聚合SDK的思路,抛砖引玉,让更多的读者对聚合SDK有好的理解。

       这是最好的时代,这是最坏的时代,这是智慧的时代,这是愚蠢的时代;这是信仰的时期,这是怀疑的时期;这是光明的季节,这是黑暗的季节;这是希望之春,这是失望之冬;人们面前有着各样事物,人们面前一无所有;人们正在直登天堂;人们正在直下地狱。——《双城记》

       双城记的开头,正是现在手游行业的一种写照,充满着希望的行业,也伴随着混沌的行业。随着手游市场的蓬勃发展,不论从研发游戏,运营游戏,还是到发行游戏,维护相关的平台,整个行业都在不断的壮大。人上一百形形色色,游戏上一百,色色行行,渠道上一百,感叹活久见。

       正是因为行业规模的庞大且新兴,很多事物并没有统一的业界标准。在任何一款游戏,要最终推到用户手上,不可避免的需要和各大渠道打交道。无论你是独立发行,还是联合运营,或多或少,会和App Store,Google play,国内各大发行渠道,阿里游戏,应用宝等等之类的打交道。而和他们打交道最直接的交互,就是需要接入相对应的sdk模块。

       众多渠道的sdk良莠不齐,作为游戏开发商的cp,尤其是众多中小cp,第一次接入几家甚至几十家的渠道sdk已经需要花费巨额大的时间和人力成本,而当渠道sdk更新,需要将这些sdk再次接入到自己游戏中,又或者说,游戏发生了更新,需要重新的将这些sdk接入到自己游戏中时,则又要再次耗费巨大的时间和人力成本。聚合sdk正是基于这种情况下,才会被提出的概念。我们希望的,只是一个简单粗暴的,可以快速接入,没啥技术经验的人也能使用的一键式自动打包工具,只需要传一个工程文件,就可以直接出渠道包。

       那么,我们就长话短说,我们来看看,我们要实现这套聚合的sdk,需要做哪些事情。

主要需求:

       首先,我们需要明确想要做成的东西是个怎么样产品

       1.游戏客户端和游戏服务端,只需要关注游戏本身内容,无需关注不同渠道的sdk差异性,降低渠道sdk和游戏客户端的耦合性

       2.公司应用必须要支持多个项目的统一管理,但不能有集中式单点的风险,数据需要分离和整合不同的表现

       3.公司发展后各种部门的交互流程和人员成本,让非技术的运营人员也可以打包,并且使用流程管理来进行出包版本管控

       4.该聚合sdk必须要有扩展性,能应对日后新增的各种其他类型sdk。

 

主要模块:

       针对这些需求,我们将产品分割为以下几个大模块。

       1.用作客户端接入部分的统一框架 SDK_Client

       2.用作服务端统一的逻辑转发和处理中心SDK_Server

       3.用作打包功能的逻辑和多线程的任务调度SDK_Package

       4.用户可视化操作界面和功能配置界面SDK_Manager

 

       这四大模块,是我们最终的目标,一键式傻瓜化打包工具的组成。让用户只要传一个游戏项目,就能直接打出指定的渠道包。

 

主要的关系图:

       接下来我们来看看主要的几个关系图

我们看看 packager的主要工作原理

TypeSDK总体设计思路和架构_第1张图片

1.取得相关游戏的配置文件

2. 取得指定渠道的配置文件

3.利用打包脚本,合成渠道包

4.提供渠道包的下载链接

 

manager和package组成客户端打包工具,manager负责管理和配置,package负责编译,关系图:如下

 TypeSDK总体设计思路和架构_第2张图片

 

1.用户通过manager,上传一个原始的游戏

2.manager根据用户操作,找到相应的渠道SDK,渠道参数

3.manager分配给packager组打包的任务

4.packager 组找到空闲的packager节点,将该任务指定到具体的pakcager

5.选中的packager根据接收到的任务以及参数,打出指定渠道包


sdk的client和server与游戏客户端和服务端的交互架构

TypeSDK总体设计思路和架构_第3张图片


可以看到相对的结构图如上
1. 游戏渠道包,包含了游戏客户端以及聚合sdk客户端,渠道sdk三部分
2. 游戏客户端,将聚合sdk客户端发送过的sdk数据转发给游戏服务端
3. 游戏服务端,将游戏客户端发送的sdk数据转发给聚合sdk服务端
4. 聚合sdk服务端和渠道sdk服务端进行逻辑交互,以及相关的数据有效性验证,验证通过后,发回给游戏服务端正确的数据结果
5. 游戏服务端根据聚合sdk服务端返回的数据结果,处理游戏内的逻辑
6. 游戏客户端,将游戏服务端返回的经过验证后的sdk数据结果转发给聚合sdk客户端

 

       以上所有,是我们对一套聚合sdk的总体架构以及构思的分析。整套我们最终目标要做成的一键式傻瓜化打包工具,是需要一步一个脚印,积少成多堆积出来的。但是有了明确的思路和方向,相信众读者会对聚合sdk不再陌生,也能更好的使用聚合sdk。

       聚合sdk的其中每一个模块的具体实现,需要注意点,我们会在日后慢慢分析。

这个项目已开源,大家有兴趣可以自己研究或者参照项目编写自己的聚合SDK

项目地址:https://code.csdn.net/typesdk_code

项目地址:https://github.com/typesdk

       

你可能感兴趣的:(开源手游渠道聚合TypeSDK,unity,cocos,android,ios,开源)