android手游渠道接入业务+技术全讲解

整整三个月没更新博客了，这也是我开始正式工作的三个月，android开发虽然以前也接触过一点，但是过的时间太久了基本没印象了所以这段时间都在工作加学习，工作主要就是在做android渠道接入，接近两个月时间了感觉自己也算是比较有了一些心得了，终于可以写点东西了。
手游行业的火爆是不需要说太多了，除了忠实的游戏玩家，很少还有人守在电脑前玩PC游戏了，而很多我们耳熟能详的游戏诸如梦幻西游、热血传奇、穿越火线等也都推出或即将推出手游版，腾讯网易畅游盛大等巨头也纷纷发力，都想在手游领域立于不败之地。一款游戏的品质如何那自然取决于策划和研发人员，而这款游戏在上线后是否能够成功，还是看推广做的如何，是否覆盖各个渠道，我们公司最近做的一款游戏，几乎就把各个渠道接了个遍。没办法，得渠道者得天下。在国内android平台有着众多渠道，没有哪个渠道在用户体验上有绝对的优势，这就导致游戏开发人员对每个渠道都必须足够的重视。
渠道的接入有个特点，技术实现不难但极端麻烦，游戏客户端与服务端的联调、游戏服务端与渠道的数据校验以及游戏客户端本身在接入渠道SDK时都会出现许多问题，但是经过这么长时间的摸索，我发现各个渠道在接入过程中出现的问题都是类似的，效率也就随之提高，比如我接的第一个渠道花了近一周的时间才大体完成，而现在我一般一到两天就能结束一个渠道的接入。我们去百度上搜索“手游渠道接入”，几乎找不到任何技术层面的文章，可能是众多大神不屑于写这方面，也可能确实没什么技术含量，但我个人看来确实还是有很多问题需要注意的，相信也有很多像我一样的新手朋友刚开始时肯定会蒙圈，那么这篇文章就作为我的一个总结，以及给跟我一样的新手朋友做个导向，顺便给没接触过手游渠道接入的朋友也做个介绍，大神请无视，就酱。
一个手游渠道接入的完整流程分为三部分：商务沟通、技术接入、提交审核，作为一只程序猿我当然只做第二部分，但经过多次与商务同事及渠道人员沟通，对其它流程也有所了解，那么我接下来就总结一个完整的渠道接入流程。

一．商务沟通
我们拿到一个渠道接入文档后，最先看到的一般就是接入说明，这里要进行的是到渠道后台申请appId等渠道参数，参数个数以及参数名各个渠道都不相同，一般除了appId还会有appkey、payKey等等，appId与应用是一对一的关系,一个 appId只能分配给一个应用使用。若多个应用使用一个 appId会导致不能正常计费,影响收入;还会导致 SDK 升级失败、各项统计数据出错等。程序中的 appId必须和平台申请时填写的包名对应起来,否则会提示应用被禁用,程序没有审核通过也是一样。具体的参数当你在渠道后台申请了之后都会有详细的说明，这里要做的就是拿到这些参数，接下来我们要用到的。

二．技术接入
这一部分是一个渠道接入的核心环节了，渠道SDK的接入主要是参照渠道给的SDK文档，一般的文档都会分为两个主要的部分：登录和支付，任何渠道都会有这两个部分，此外还可能有会注销、上报数据、悬浮窗、启动闪屏等特殊要求，如果渠道的SDK文档中有提到这些要求，作为技术人员我们是一定要满足的，否则可能会无法通过渠道的审核，下面我就逐个地介绍一下。
1.登录
登录流程大致如下：

首先调用渠道方提供的登录接口进行登录，一般情况下这个接口会有三个回调，分别是登录成功、登录失败、登录取消，之所以说一般情况下，是因为有些渠道比较个性，有的渠道是没有提供登录取消接口的，有的渠道登录的回调监听也不是在登录接口里面，这就需要我们仔细地阅读渠道文档，严格按照渠道的方式写码。
登录成功后渠道会返回给游戏客户端一个验证ticket（任何渠道都会返回），有些渠道还会返回一个渠道用户ID，这时需要做的是将这个ticket传给游戏服务器，游戏服务器拿到这个ticket后再到渠道服务器进行校验，这个过程是防止有人冒充登录，校验成功后游戏服务器需要通知游戏客户端，此时客户端进入游戏。
登录过程中的技术问题主要出在以下几点：
(1)初始化失败。绝大多数渠道都会提供一个初始化接口，这个接口一定要在登录前调用，一般需要在这个接口传递在渠道后台申请的appId和appKey，如果参数不对会导致初始化失败，也就无法登录成功。
(2)资源文件、jar包、mainfest配置出错，有些渠道在mainfest配置里有appKey等参数，拷贝之后一定要改成当前应用的参数值。
(3)服务端校验未通过，一般情况下如果资源及配置确认没问题，那基本就是服务端校验没通过导致登录失败，此时要检查客户端传给服务端的ticket是否正确。
2.支付
支付流程大致如下：

首先调用渠道方的支付接口，与登录不同的是，这个支付接口是需要传一些参数给渠道的。这些参数可以从游戏服务的获取，一定有的参数是支付的订单号，可能有的是商品名称、单价等。支付就涉及到钱的问题，那么就要考虑到安全，所以大多渠道这个支付流程是需要加密的，渠道服务器收到渠道请求后会通知游戏服务器为这个用户发货，此时游戏客户端需要与游戏服务端进行校验，以防渠道方恶意通知发货，校验成功后游戏服务器进行发货，客户端进行订单查询，用户可以收到购买的商品。
支付过程中的技术问题主要出在以下几点：
(1)调用渠道支付接口时参数传错，不要小瞧这个参数问题，很多渠道在支付时都需要很多参数，有一个参数不对就会导致支付失败，而很多时候我们根本看不出错误出在哪。需要注意的几个参数：订单号一定要传渠道方的订单号、金额注意渠道要求的是元还是分、支付通知地址是否需要在客户端传递(支付通知地址即渠道通知的服务器地址)。而很多时候问题也是出现在渠道方，比如我之前接过的一个渠道，一直支付失败，卡了20天，最终发现是有一个参数必须传null，而渠道文档上并未对此作出说明。所以有时候如果出了问题而又找不出原因那么一定要及时与渠道方沟通，避免浪费时间。
(2)无法调起支付界面或者直接崩溃，这种情况一般是资源文件、jar包、mainfest配置出错，这里需要注意的是assets目录下的文件一定要手动拷贝到游戏工程中。
(3)客户端付款但游戏服务端未发货，这种情况可能是支付通知地址填写错误，支付通知地址一般有两种方式填写：一是写在渠道后台，二是在支付时由客户端传给渠道方，具体情况按渠道要求，有些渠道在支付的参数里看起来没有要传支付地址，但实际上是要写在附加参数里，这就需要与渠道沟通才能确定了。
(4)服务端校验未通过，为防止渠道恶意通知发货，游戏服务端与游戏客户端是需要校验的，这个校验一般使用己方的订单号，所以在校验时注意要将己方的订单号传给游戏服务端，而不能传渠道的订单号。
(5)点击商品后提示“无法支付”，这个问题是很常见的，有可能是资源没有拷贝，也可能是商品没有在渠道方创建，有些渠道是需要在它们后台逐个创建商品的，创建之后会分配一个商品id，在调用支付接口时将这个商品id传给渠道，这样才能调起支付页面。
(6)未修改包后缀名，每个渠道都会要求修改包后缀名，这个最好在调试阶段就要改好，否则会导致各种问题。
3.注销
如果渠道提供了注销接口，那么在注销时我们就一定要调用这个接口。
有些渠道没有提供注销接口，而是提供了切换账号接口。我们知道游戏里面是有注销选项的，玩家点了注销应该回到登录界面，而如果渠道没有提供注销接口，我们就要在玩家选择注销后做一个标记，等玩家再次登录的时候就不要在调用登录接口，而是调用注销账号接口，这样行为上是满足了需求的。
4.添加闪屏
游戏闪屏就是当玩家点击游戏图标进入游戏时跳出的画面。这个接入过程如果仔细一些，资源配置等都不缺少，那么一般是不会出问题的，当然如果你有一个地方不注意就可能会导致程序崩溃。需要说明的是很多渠道都要求把闪屏加在第一屏，否则是不能通过渠道审核的。
5.悬浮窗
这个地方是经常出现问题的，悬浮窗里面有一个重要的功能是切换账号，有些渠道会单独设置一个悬浮窗切换账号的监听和回调，而有些渠道就直接把回调设置在登录的回调里，这时还需要游戏客户端在登录时做一个判断，是登录的回调还是使用悬浮窗切换账号的回调。

三．提交审核
接入完成后，需要提交至渠道后台审核，审核通过后才能上线，如果接入过程中严格按照渠道的要求进行，那么一般都会通过的。

四．更新SDK
渠道的SDK是需要不定期更新的，不更新就不能使用，这也是渠道接入最头疼的地方，更新的时候首先要细读文档，查找哪些地方有变动，哪些是新加入的功能，哪些接口不能再使用，这里要注意，有些渠道废除的接口虽然不能再使用，但是在代码中是不会报错的，而当你运行到这里时程序就会崩溃。再有要注意渠道参数是否更改，如果需要重新在渠道进行配置那么参数可能就会改变，记得在代码中也要随之修改。

一个渠道的完整接入流程就大致是这样，接入的过程比较简单，但是后期的更新是很繁琐的，对此我们可以考虑使用第三方的SDK更新，一般只要一次接入，后面的更新都是由第三方SDK来做，节省的时间是相当可观的。并且不再需要关心渠道方的任何接口与数据交互，只需要接入第三方SDK的接口即可，详细方法可以到各家第三方SDK的官网上查看。

更多相关文章

随机推荐