手游SDK知识详析

一、SDK概念

     SDK ,即 Software Development Kit软件开发工具包的意思,通俗点说,就是辅助开发某一类软件的相关文档、范例和工具的集合,不过我们平时所说到的Sdk其实会更加简单一些,就是一个封装了各种功能模块的依赖库与对接文档罢了,比如,我们按照对接文档接入腾讯语音SDK,那么我们软件就具备了实时语音功能。

二、手游SDK涉及对象

游戏研发:也称CP(Content Provider, 即内容提供商),即开发游戏的公司/主体
游戏发行:也就是跟有流量的渠道合作联运的一种游戏推广方式,既然是联运的话,基本就是收入分成,比如:玩家充了钱,研发占5成,渠道占5成,以前说到发行基本都是上5+7渠道:
     7大硬核渠道:Oppo、Vivo、华为、魅族、金立、酷派、联想
     5大主流平台:应用宝、小米、360、UC(阿里游戏)、百度
不过此一时,彼一时,现在7大硬核渠道很多已经没落,比如:金立、酷派那些几乎都快倒闭了,反而其他手游渠道逐渐崛起,比如:九游、TapTap都是用户流量比较大的渠道,要是游戏品质比较好,同时渠道关系维持得比较好或者舍得花钱,你的游戏还可以出现在他们渠道主页推荐位上,那么曝光率就会大大提高,下载你游戏的用户自然也会更多,同时发行还有个叫长尾渠道
     长尾渠道的定义:中小自有量渠道,主要是一些中小型规模的细分渠道,例如:今日头条、当乐、果盘、海马等,它们未必全部和游戏有关,但却在导流方面有着不俗的表现。相对于为数不多的几个主流大渠道来说,“长尾渠道”规模庞大,几千个渠道商占据着约40%的市场份额,实力绝对不容小觑。

游戏买量:也就是在广告媒体上投放广告买量,常见的广告媒体有:头条系产品(抖音、今日头条、西瓜视频等)、快手、广点通、百度、UC等,这种方式基本都是按照按广告效果计费(当然也是有按分成的),比如:
     CPA方式(Cost Per Action):按玩家下载安装或者注册数来计费,比如:约定有1个玩家下载安装或者注册,那么就给广告媒体10元;
     CPS方式(Cost Per Sale):这种方式跟发行联运有点类似,也是玩家在游戏内充钱了,两者再进行分成,若是玩家仅仅是下载安装而不付费的话,广告媒体是没有收入的;
     CPM方式(Cost Per Mille):这种方式一般是按游戏广告展示1000次计费,也就是说只要玩家看到这条广告,就算一次展示,比如:约定展示1000次,需要给广告媒体支付20元;当然有些广告媒体还会统计玩家看广告的时长来灵活计费;
     CPC方式(Cost Per Click):按玩家点击广告数计费,也就是只有玩家看到同时点击了这条广告,才需要给广告媒体付费,要是没点击是不需要给钱给广告媒体的
在这里插入图片描述

概述:一般而言,要是游戏研发公司比较小,没有自己发行的团队的,都是会选择找第三方专门做发行/买量的公司去发行/买量,不过发行相对于买量来说,工作量会稍微小一些,只要是自己独创的、高品质的游戏都是比较容易跟渠道谈合作,提前预热,然后接入渠道的SDK上架发行即可,当然要想上渠道主页推荐位,那还是得看商务的能力了;因为发行相对简单一些,所以稍微大点的游戏公司会组建自己的发行团队,既做研发又做发行,比如:腾讯、网易、37等。买量的话,因为需要在各个广告媒体上投放广告,所以涉及大量广告素材的设计、建广告计划以及广告效果分析等各项工作,所以工作量相对比较大,一般游戏公司都是会选择找专门做游戏买量公司去买量,那么跟买量公司谈合作时候就会涉及到分成,因为买量公司需要去广告媒体投广告,需要比较大的成本,所以分成一般都占5成以上
在这里插入图片描述

三、手游SDK诞生缘由

     因为游戏买量公司/游戏发行公司(SP)游戏研发(CP)合作时候涉及到分成的问题,那么玩家在游戏内充值了多少钱,双方都是需要有明确的流水记录才方便对账。假如支付功能都是CP自己提供,玩家支付完再通知SP,正常来说也是没问题,但是要是CP为了分少一些收入给SP,可以选择通知少一些支付数据给SPSP也是没法发现的,所以支付功能需要由SP提供,然后游戏接入SP提供的支付功能,那么为了方便游戏快速接入SP的支付功能,SP需要开发属于自己的SDK,这个SDK对外提供一个支付接口给游戏快速调起支付界面,然后玩家支付成功之后,SP再通知游戏给玩家发币,整个支付流程下来,SPCP都是有玩家充值的流水记录,谁都做不了假,因为要是SP这边收到玩家的钱却不去通知游戏那边的话,玩家的游戏角色是收不到游戏币的在这里插入图片描述

     对于SP来说,收入分成上的问题是解决了,但是因为登录功能模块是CP提供的,SP自己花大价钱打广告买量买回来的用户,自己却没有丝毫跟这个用户相关的记录,最终也没法进一步将其转化为自己的用户,始终还是感觉像是为他人做了嫁衣,而且要是后续CP反悔不继续跟这个SP合作了, 那么CP把支付功能换回自己的支付功能即可,SP导进来的用户因为是用了CP的登录功能,那么就算不跟SP合作,那些用户还是可以登录游戏的,所以就算解除合作,对于CP来说没太大损失,但是对于SP来说就损失大了,买回来的用户就算继续在游戏充值也跟自己没有一点关系。所以,登录功能也应该由SP提供,游戏通过调用SP提供的登陆接口接入SP的登录功能,一来可以保障SP的权益,二来也方便SP的客服更好地服务玩家
     SP投放广告肯定不能漫无目的地去投,需要不断地根据之前导入进来的用户数据去判断各个渠道的用户质量,所以就涉及到数据收集功能,需要游戏接入SP提供的数据上报接口,把玩家相关数据上报到SP后台,SP后台对数据进行统计分析来进一步优化投放策略
     综上所述,登录支付数据收集这三大模块是SP所提供的手游SDK必不可少的功能,除此之外,为了响应国家政策,实名认证与防沉迷模块也是必不可少,同时为了更好地服务玩家,还相应地衍生出找回密码在线客服留言咨询等功能点
在这里插入图片描述

四、手游SDK包含的功能模块

在这里插入图片描述
手游SDK主要包含五大模块:登录模块支付模块数据收集模块用户中心模块防沉迷模块

1、登录模块

     登录模块主要包括:注册登录找回密码等功能,登录功能又可以细分为:账号密码登录第三方账号授权登录手机号+验证码登录
     对于第一次接触手游SDK的新人来说,可能对游戏接入SDK登录的整个流程比较模糊,下面来看看游戏经过SDK登录整个流程的时序图:
在这里插入图片描述

2、支付模块

     支付模块一般包括:支付宝微信支付,有些还会有银联支付扫码支付等,游戏调用SDK支付接口时序图如下:
在这里插入图片描述

3、数据收集模块

在这里插入图片描述

4、用户中心模块

     用户中心模块(即悬浮窗部分内容)不是必须的模块,不过为了更好地服务玩家,是SDK完善与优化的重点模块
在这里插入图片描述

5、防沉迷模块

     国家为了防止未成年人沉迷网络游戏,切实保护未成年人身心健康,出台了相关的防沉迷政策,同时还设立专门的投诉渠道:游戏企业防沉迷落实情况举报平台,积极国家的号召,加强游戏的实名认证与防沉迷功能也是必不可少的。
     我们来看看游戏需要落实的关键点:

Ⅰ、实名认证违规

(1)无实名认证;

(2)虚假实名认证。

落实措施:

  • SDK客户端需要在玩家注册完成之后,进入游戏之前,弹出实名认证界面,让玩家登记真实姓名与身份号码,然后把玩家实名认证信息上报到国家防沉迷系统进行实名认证,认证成功则进一步判断是否未成年,认证失败则不允许进入游戏。

Ⅱ、游戏时段时长违规

(1)非周五、周六、周日及法定节假日20时—21时提供游戏服务;

(2)超出1小时游戏时长限制;

(3)其他违规情况。

落实措施:

  • SDK服务端提供接口查询登录的用户是否允许在当前时间段玩游戏,若是返回不允许,则玩家无法进入游戏
  • 若是允许进入游戏,则SDK客户端开启心跳包,定时发起请求,查询该玩家的可玩时长,若是可玩时长为0,则强制退出游戏,为了做得更人性化一些,可以提前10分钟提示玩家合理安排游戏时间。

Ⅲ、未成年人付费违规

(1)未满8周岁的用户可充值;

(2)8周岁以上未满16周岁的用户,单次充值超50元;

(3)8周岁以上未满16周岁的用户,月累计充值超200元;

(4)16周岁以上未满18周岁的用户,单次充值超100元;

(5)16周岁以上未满18周岁的用户,月累计充值超400元。

落实措施:

  • 玩家下单时候,SDK服务端检查该用户是否未成年人,然后检查充值金额是否超出限制,若是超出,则弹出提示不允许充值

五、手游SDK接口设计原则

1、接口函数设计得尽量简洁,接入简单
比如:角色信息上报接口
A设计的接口如下:

public uploadUserData(String type, String roleId, String roleName, int roleLevel, long roleCTime, String serverId, 
String serverName, int vipLevel, long roleLevelUpTime, String chapter, String gender, String profession,
long professionId, long power, long balanceId,String balanceName, long balanceNum, long partyId, String partyName,
long partyProfessionId, String partyProfessionName, int roleOtherLevel)

然后CP接入时候就需要一堆参数写入在一个括号内,而且看不到哪个位置是哪个参数

SdkApi.getInstance().uploadUserData(RoleParam.TYPE_ENTER_SERVER, "1", "圣斗士", 1, 1632481994,"1", "飞天1服", 1, 1632481995, "无", "女",
 "法师",1, 100, 0, "元宝", 120, 1, "乌龙院",1, "长老", 1);

游戏研发对接时候基本就是下面这个表情
在这里插入图片描述
B设计的接口如下:

public uploadUserData(RoleParam roleParam)

CP接入时候只需要复制demo的代码,修改一下即可

 RoleParam roleParam = new RoleParam()
                        .setType(RoleParam.TYPE_ENTER_SERVER)//TYPE_ENTER_SERVER(登录),TYPE_LEVEL_UP(升级),TYPE_CREATE_ROLE(创建角色),TYPE_EXIT_SERVER(退出)
                        .setBalanceId(1L)//货币id,balance指充值现金货币,即用现金直接购买的货币,
                        .setBalanceName("灵玉")//货币名称
                        .setBalanceNum(1000L)//货币数量
                        .setChapter("大闹金銮殿")//章节/关卡
                        .setPartyName("昆仑派")//帮派、公会
                        .setPartyId(1L)//帮派公会id
                        .setPartyProfessionId(1L)//帮派职称id,帮派会长/帮主必传1,其他可自定义
                        .setPartyProfessionName("白虎堂堂主")//帮派职称名字
                        .setRoleId("1")//角色id
                        .setRoleName("小智")//角色名
                        .setRoleLevel(11)//角色等级
                        .setRoleOtherLevel(2)//角色其他等级,比如:转生、飞升、地元等
                        .setRoleCTime(System.currentTimeMillis() / 1000)//角色创建时间,(单位:秒)不可用本机时间,获取服务器存储时间
                        .setRoleLevelUpTime(System.currentTimeMillis() / 1000)//角色升级时间,(单位:秒),获取服务器存储时间
                        .setServerId("1")//服务器id
                        .setServerName("世外桃源")//服务器名
                        .setVipLevel(1)//vip等级
                        .setGender("女")//角色性别
                        .setProfession("法师")//角色职业名称
                        .setProfessionId(1L)//角色职业id
                        .setPower(1000L);//战力值
SdkApi.getInstance().uploadUserData(roleParam);

B设计接口函数时候,将接口参数封装成了对象,同时在对对象的字段进行赋值时候,支持链式调用,简洁明了

2、接口设计时候尽量考虑周到,不要随意变动,即要符合开闭原则,对修改封闭,对扩展开放
     假如某天有个新需求需要在角色上报接口增多一个参数,那么还是以上面案例为例

  • A设计的接口要么在原来接口的基础上增加一个参数,要么增加一个新接口,若是在原来接口基础上增加新的参数,那么以前旧游戏都得重新对接这个接口,要不就会报错;若是新增一个接口函数倒是可以做到兼容旧的游戏,但是显然后面要是不断有新的加参数需求,那么接口函数的数量会不断增加
  • B设计的接口只需要在RoleParam中增加一个字段即可,对于旧游戏不给这个新增的字段赋值也是可以正常运行的,新对接的游戏就约定给新字段赋值即可

3、SDK对接文档尽可能写得通俗明了,参数的含义清楚标注,每个接口有清晰的示范案例
4、所需对接的接口设计得尽可能少,减轻CP对接成本
     比如:Android SDK一般是需要知道各个activity的生命周期变化的, 但是游戏所在Activity不是SDK自身的Activity,所以有些人在设计接口时候,就会设计一堆的生命周期相关的接口函数给游戏去调用,其实对Android有深入了解的人,是不会这样设计的,因为一来设计的接口太多,没法确保游戏研发不会漏掉,二来增加了研发的工作量,研发对接SDK的周期会更长,要想实现监听各个activity声明周期的变化可以在application中注册一下Activity生命周期回调即可

application.registerActivityLifecycleCallbacks(mLifecycle);

5、少依赖第三方库
      比如:网络请求、数据库操作之类,能自己实现的尽量自己实现,要是什么功能都是依赖第三方库,一来SDK的体积会变得很大,二来要是游戏也有依赖相同的第三方库但是所用的版本不相同时候,就容易出现依赖冲突
6、资源命名加公司前缀
     比如:Android SDK项目的对接,一般是提供aar或者jar+res给游戏接入,因为最终游戏的android资源跟SDK的资源是合并在一块的,所以假如SDK有个布局资源名为:login.layout, 刚好游戏android资源中也有一个同名的话,那么游戏打包时候就会报错,所以最好的做法就是资源命名的时候加公司前缀,比如:com_facebook_login.layout,这样就可以避免资源冲突问题

  • 13
    点赞
  • 51
    收藏
    觉得还不错? 一键收藏
  • 4
    评论
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值