Android 游戏 - 聚合SDK

前言小叙

如果不是生活所迫，谁愿意搞得自己一身才华。

这句话我很喜欢~

在一家发行游戏公司呆了已经四个年头，从懵懵懂懂到糊里糊涂，从似懂非懂到啥也不懂，其实也就是四个年头吧。

第一年的时候，刚入门，稍微懂点技术，但实际上回头看，那时候技术其实等于0，一天天过的是浑浑噩噩的。

第二年稍微上道了，当时的心态有点炸，感觉自己啥都会一样，其实现在想想，也还是个笑话~

第三年，脑子不再生锈了，开始主动学习了，此时我发现了一个惊天大秘密： 越学习越无知！ 此处的无知并不是真的无知，而是学到了新的技术点，能看的稍微远一点了，才知道自己的知识储备真的少的可怜，甚至等于0！

今年是第四年，但愿且行且珍惜。

---

无论是国内还是海外，对接过的游戏项目大约50款是有的，遗憾的是没有超级爆款。

对接过的SDK接近百家吧，但是现在已经逐渐不再接入渠道发行了，改投放了，这就很需要后面说到的渠道分包技术了。

以下内容均属于自我感悟学习内容，所有内容是基于Android书写，其实iOS等也是同理同源，万变不离其宗。以下概念、定义都属于自己的理解，仅供参考。

可能还有很多一时没想到的问题，暂时能想到的都写出来了，以后想到了新内容再做补充。

一、聚合SDK架构思想

1、渠道SDK(三方SDK)

理解聚合之前，先应该明白什么是渠道SDK。

1.渠道SDK

百度SDK、360SDK、应用宝SDK，海外有谷歌SDK，这些SDK都是应用商店自身的SDK，包含他自己的登陆、支付等体系。如果游戏发行这些渠道，就可以使用他们的SDK一系列服务（登陆、支付等），一般情况下都是需要与渠道方分成的，这个非重点，不多说了~

2.内部SDK

内部SDK，其实属于我自定义的一个命名，因为本质上和渠道SDK是一样的，拥有登陆、支付一系列，不过它属于发行、推广、运营公司的SDK。

它可以封装在聚合SDK中，也可以作为一个独立的SDK体系单独写成一个Moudle，需要根据实际需要判断，我这边是直接写在聚合SDK中的，将他作为聚合SDK的一部分。

因为这样CP对接时，可以直接完成登录支付一系列操作，而不需要先接入你的聚合，再专门接入内部SDK，如果这样体验实在是太差劲了~

3.常见渠道SDK

最牛的应用商店，海外谷歌、国内应用宝。国内小渠道多如牛毛~

接过很多渠道，国内小渠道特别多，在附录有我接过的一些渠道的列表，还要好多小渠道实在忘了记不起来了~

2、聚合SDK

在游戏行业，所谓的聚合SDK，可以理解为桥梁，一个中间层，沟通游戏与渠道SDK之间的中介。

因为我这边是直将内部SDK接写在聚合SDK中的，将他作为聚合SDK的一部分。

所以后面不再提内部SDK的概念，默认：

聚合SDK = 聚合层 + 内部SDK

作为中介层，肯定是游戏发行、推广、运营公司的专属SDK，方便合作，方便对接，方便维护。

3、游戏研发(CP)

游戏研发也就是专门开发游戏的公司，一般称为CP。

这类公司开发好游戏以后，不一定会自己去推广自己的游戏，重研发不重推广，术业有专攻。这时候就有发行、推广、运营公司来了：合作一波？你有游戏，我有资源！

4、架构思想

上面画了一个简单的示意图，以登陆与支付为例，聚合层是沟通游戏研发与渠道SDK的桥梁，让他们可以通话，但是通话内容是经过聚合层加密的，也就达到了发行公司代理发行运营的目的。可以让你们通话，但不让你们直接见面，再通俗的说，聚合=中间商。

这个图，画的不怎么好，大致意思就是作为聚合，可以兼容接入多家游戏，多家渠道，形成一个通道。

作为游戏研发来说，我授权你发行公司对我的游戏发行，这时候，我只要接入你的聚合SDK就可以了，然后你就可以根据需求，接入不同的渠道，完成多渠道发行。

二、聚合SDK对外接口及注意事项

聚合SDK对外接口，最重要核心的是登陆+支付，其他的都是附属产品。

1.对外接口一般有：

• 初始化
  • Application 中初始化，最佳的是让CP使用或继承我们的Application
  • Activity 中初始化
• 登陆（包含注册）
• 注销（切换账号）
• 支付
• 生命周期
• 数据接口（需要CP传入区服名、区服ID、角色、角色ID、角色等级等等）
• 退出
• 其他
  • 分享
  • 手机号绑定

2.注意事项

对外接口，一般没什么特别的地方，不过要满足多渠道发行，接入多个SDK，所以对外的接口，要满足以下几点：

• 接口级别，一般需要在对外文档提出 必接/选接
• 接口固定，不可随便变动，这会影响版本更迭效率，影响接入方的时间成本，容易造成项目延期
• 接口完整性，因为市场每家渠道各不相同，所以要早做兼容，即使有些接口你什么也不做，也需要暴露出来让CP接入
• 简单明了！重点！能封装的事情，尽量封装
• 使用单例供别人调用，保证只有一个实例，而且接入显得简单，现在大多数渠道都是这样做的

三、内部SDK接口设计

1、初始化

1.初始化接口分两处

• 1.Application 中初始化

通常会要求CP对接时直接使用自己的Application或者继承自己的Application，这个要求的目的，不仅仅是自己SDK初始化可能要做一些更前置的操作，因为大多数的渠道SDK也会要求在此处调用它的初始化。

• 2.Activity 中初始化

此处的初始化以及后面的所有接口，一般情况下，最好要求CP将接口在主Activity中调用。

2.初始化时可以做些什么

• 数据初始化，这没啥说的
• 版本更迭
• 通告设计，比如暂时游戏维护，可以初始化时进行通告，限制进入游戏等
• 游戏区服控制，因为有些游戏前期可能会进行测试服进行公测，或者接入的渠道SDK在游戏未正式上线前，是不允许走正式服的
• 开始执行心跳接口

2、登陆与注册

1、登陆方式

• 正常注册账号登陆
• 手机号登陆
• 游客登陆
• 一键注册登陆（也称快速登陆）
• 三方登陆
  • QQ登陆
  • 微信登陆
  • 微博登陆
  • 其他

2、登陆优化项目

• 自动记录登陆账号
• 下次启动APP自动登陆
• 手机登陆后，下次可自动登陆，涉及到另类token
• 切换账号后未登录，下次运行不再自动登陆
• 同一设备，自动下发账号密码（已不推荐使用）
• 账号截图保存

3、游客登录

这块单独将游客细说一下，游客登录属于体验级登录，一般情况下，游客登录会有游戏体验时间、充值限制。

主要是为了规避国家日益严格的监管。因为现在国家开始不让使用快速注册体验游戏，总之就是有很多的限制。

游客模式就可以让玩家快速进行游戏体验，如果玩一两个小时以后，就可以对用户进行限制，要么实名认证转为正式账号，要么再见，好处有很多，再具体我也不甚清晰，但这个功能，还是需要的，最佳体验是可以服务器控制游客模式的开启。

4、账号绑定以及找回密码

①绑定方式

• 绑定手机号
• 绑定邮箱

②账号绑定的优点

• 找回密码
• 防止用户遗忘密码
• 用户联系信息的收集（利于分析推广）

③适当的激励

玩家一般情况是不会主动绑定账号的，除非真的很喜欢你的游戏了才会主动绑定。无论是否绑定，最好做出一些激励操作，比如绑定账号奖励道具等，这些功能的实现有益于游戏的推广。

3、支付

1.支付方式

支付方式，目前SDK集成最常用的有两种：

• 支付宝
• 微信

2.支付参数

支付参数一般有：

• 订单号
• 金额（建议使用整型）
• 商品ID
• 商品名称
• 商品描述
• 货币名称
• 商品数量
• CP透传参数

一个支付接口，一般会有以上这些参数，支付是最重要的一个环节，加密、补单机制，必不可少。

4、数据接口

数据接口，主要用来收集玩家的角色选区等内容，用来进行数据分析。

①常见需要收集的参数有：

• 区服ID
• 区服名
• 角色名
• 角色ID
• 角色等级
• 创角时间

②常见调用场景：

• 选区时
• 创建角色
• 选择角时
• 进入游戏
• 角色升级时
• 退出游戏

5、设备数据获取

这个是比较重要的，应该说是非常重要，尤其是对专注于投放的游戏公司。

获取数据这块，尤其是IMEI，可以参考我其他文章看看吧。

设备数据，最重要的数据一般有：

• IMEI1、IMEI2、MEID(稳定，但不一定能稳定的获取)
• 设备ID（这个值不固定，可以是自定义）
• Android 广告ID（针对海外）
• OAID

其实还有很多关于设备数据的ID，这里不进一步叙述。

6、政策相关

受国家管控，SDK需要添加的内部功能：

• 实名认证
• 防沉迷
• 家长守护工程
• 注册协议+隐私协议

这里大致提一下，不做详细的叙述，发行游戏，现在这些都是需要的。

7、客服系统

优秀的聚合SDK，客服系统必不可少。

玩家掉单啊什么的，能够找到客服随时解决，可以极大提高用户粘性。

我们的SDK使用的是七鱼客服。

四、聚合SDK踩坑（不可忽视）

1、命名规范

在开始准备编写自己的SDK时，确定名字后，所有的命名都需要规范。

特别注意的是，资源等命名，需要加上自己独特的前缀，避免与CP或渠道SDK冲突。

比如常见的颜色命名，红色：

<color name="nb_red">#FFFF0000</color>

如果不加上 nb_ 作为前缀的话，很容易冲突。

2、文档书写

索引

对外的文档书写，如果内容较多最好加上索引，我一般使用markdown编写文档，在文档开头简单一行 [TOC] 就可以生成索引，很方便。

文档内容

需要简单明了，不要做过多赘述，层次要清晰，需要使用正规官方一点的话语编写文档，不要像我写这篇文章，很多情况都使用了白话，随意的说。

一般分层：

• 一、文档说明
• 二、接入前注意事项
• 三、SDK接口接入
  • 登陆
  • 支付
  • 其他等等
• 四、服务端协议
• 五、常见问题
  • 登陆问题
  • 支付问题
  • 其他等等
• 附录
  • 更新日志
  • 快速更新升级
  • 其他等等

3、回调设计

无论是初始化、登陆等接口，都需要回调告知成功或者失败，回传数据等操作。

回调的设计，建议是在初始化出，做统一的回调处理，当然具体还是需要根据实际情况操作的，下面是一段示例：

		NBSDK.getInstance().init(this, new NBResult(){
			@Override
			public void onResult(int nbResultCode, final Map<String, String> result) {
				switch(nbResultCode){
				case NBResult.INIT_SUCCESS:
					showLog("初始化成功");
					break;
				case NBResult.INIT_FAILED:
					showLog("初始化失败");
					break;
				case NBResult.LOGIN_SUCCESS:
					showLog("登录成功:" + result.toString());
				case NBResult.LOGIN_FAILED:
					showLog("登录失败");
					break;
				case NBResult.PAY_SUCCESS:
					break;
				case NBResult.PAY_FAILED:
					showLog("支付失败:" + result.toString());
					break;
				default:
					
				}
			}
		});

以上示例就是将所有的回调统一在初始化处处理了，比如注销等等都可以在此处统一回调。

4、三方库的使用

建议尽量能不使用三方库，就不要使用。使用三方库，库如果与游戏或者渠道SDK冲突的话，幸运点的情况是你简单升级或者CP愿意修改自己使用的库版本，这样问题也不大。

怕就怕版本差异过大，每一方都不愿意改自己的版本和代码。聚合SDK作为中间层，往往就是妥协的一方，只能改自己的SDK兼容了。

再有种情况，有些三方库有资源的引用，类似R.id.mengduo,如果遇到伪研发（上游聚合，实际不是游戏研发，他只有apk没有游戏工程，只是在合作中他处于你的上游）。此时他无法提供游戏工程，反编译处理，这种资源引用就会是个极大的问题，你遇到可能会哭哦。

5、HTTP 与 HTTPS

Android9.0 默认是禁止所有的http请求的，作为聚合SDK是需要兼容做下兼容的。免得游戏工程或者渠道SDK使用HTTP导致崩溃出现。

6、Eclipse 与 Android studio

Eclipse 现在已经很少有CP在用了，但不排除有些老游戏还在用。

Android studio是主流，所以我们将SDK打成库时，现在一般只需要提供 aar 文件即可，即使有CP使用Eclipse 对接，也可以自行拆库对接。

7、Java版本管理

这块其实也算不得版本管理，只是说写SDK时，尽量不要使用新特性语音，需要尽最大可能性的做好兼容。如果你的SDK使用了Java 8 的lambda表达式，是不是别人都需要为你指定版本呢？是不是都要在 build.gradle文件中android节点下增加以下内容呢：

compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }

这种情况要尽量避免。

8、权限获取

获取权限，聚合SDK是否获取权限应该做一个开关，因为可能游戏也会获取权限，如果同时获取，在玩家还没给权限的情况下，有些手机是会重复弹出权限询问框的，所以这个开关最好是让CP可以控制。

9、支付补单

无论是客户端还是服务端，都有自动补单的能力，服务器一定要完善，对新的补单请求要做及时处理。能完善以下几点，基本就能规避掉单问题。

• 客户端补单：
  • 初始化检查掉单，掉单则补单
  • 点击充值时检查掉单，掉单则补单
• 服务端补单
  • 客户端主动发起补单请求，进行补单
  • 间隔一段时间后自动查询是否有掉单，进行补单

补单主要服务端做的好，一般都没啥烦恼。

10、登陆防刷号

这个功能，是怕有些别有用心的人，处于不好的目的不断的注册新账号，此时就要做登陆防刷号处理。

常用的手段是获取设备ID，或者IP地址，直接进行注册限制，甚至是封号限制，这个服务器做的标准一些的话，完全自动防刷号是可以实现的。

11、反射引用资源

作为聚合SDK，必须要使用反射引用资源替代R…引用。

因为很多情况下，可能遇到伪研发没游戏工程，或者你接入的渠道SDK要对apk反编译处理，做更多的分包。如果你是有R引用资源，往往会报错。

关于反射引用资源，建议看看此文。

五、聚合SDK必备技术

1、分包技术

分包技术，建议看此文。。

2、反编译技术

反编译技术，作为中间层的SDK是必须要会一些的，假如CP不给你游戏工程的情况下，只接入了你的聚合SDK，而你的公司需要发行多家渠道，要你在apk的基础上接入新的SDK，你该怎么做呢？

当然是反编译啊~

这里不需要你多⑥，常规的一般性问题还是需要有能力解决的。

反编译进行：

• 换参数
• 换素材
• 换库
• 回编译
• 签名

这方面我简单有些经验，但是觉得不是啥牛叉的东西，就不班门弄斧了~

3、apk参数替换技术

apk参数替换技术，就是一个你的APP，在不反编译、不依赖服务器处理的情况下，将apk参数替换掉，或者做一些新的配置。这个主要是方便运营，解放技术。此技术也将作为单独的一文发布，尚未书写。

4、悬浮球设计

聚合SDK的悬浮球，不但要好使，而且不能要权限，才是一个好的悬浮球，如果你的SDK需要悬浮球，不妨看看此文。

5、设备ID获取技术

最重要ID，当前也就一掌之数，可以看看此文。

附录

渠道列表：

• 海外：
  • 谷歌
  • Facebook（往往是作为谷歌发行时的一个登陆方式接入）
  • onestore（相当于韩国的应用宝，事实是它所占韩国市场份额很小）
• 国内
  • 应用宝
  • 华为
  • OPPO
  • vivo
  • 百度
  • 360
  • 小米
  • 联想
  • 酷派
  • UC
  • 搜狗
  • 斗鱼
  • 安智
  • 魅族
  • 努比亚
  • 三星
  • papa
  • quick
  • share
  • 朋友玩
  • PPTV
  • letv
  • 4399
  • 51
  • 51K
  • 9377
  • 爱趣玩
  • 木蚂蚁
  • 拇指玩
  • 芒果tv
  • 草花
  • 赤炎
  • 楚游圈圈
  • 当乐
  • 怪猫
  • 果盘
  • 海马（模拟器）
  • 蓝叠（模拟器）
  • 夜神（模拟器）
  • 互娱39
  • iTools
  • 金立
  • 快看
  • 金山云
  • 掌阅
  • 乐嗨嗨
  • 米娱
  • 乐游
  • 墨仙
  • pps
  • 勇士
  • 阅文
  • 幽谷
  • 耀星
  • 小7
  • 闲兔
  • 盛天