移动平台游戏网络重连方案

1、背景

移动网络信号波动频繁,给移动游戏开发者带来诸多困扰,处理不好会造成较差的用户体验以及重复扣道具等严重问题。因此弱网络问题在TDR技术评审中作为客户端重点挑战项,并且弱网络专项测试达标后方能上线。本文就过往项目中遇到的问题给出一种比较通用解决方案。

2、网络连接方式

通常游戏客户端都是通过创建socket与服务器取得连接,但也会根据使用场景划分成两种连接方式:TCP连接和HTTP连接。

1) TCP连接即我们常说的长连接。这种连接方式下socket连接一旦建立,通信双方即可相互发送数据,直到一方终止连接。目前公司的移动端联网游戏多采用这种数据通讯方式。

2) HTTP连接即我们常说的短连接。这种连接采用的是“请求-响应”的通讯方式,每次交互由客户端发起请求,服务器收到请求后才能回复数据,数据传输完成后,socket连接便断开。在下载CDN资源或云配置时通常会采用这种连接方式。

 3、网络检测

3.1 检测设备的网络环境

iOS和Android都提供了检测本地网络环境的方法,具备我们需要的功能:

1) 网络环境标识,区分当前网络环境:WIFI/WWLAN/NOTREACHABLE等。

2) 网络切换感知,网络环境切换后会收到系统消息。

在苹果开发者网站(developer.apple.com)上有一个reachability的例子,对底层网络组件做了封装,可实现此上的功能。Android上提供了Connectivity Manager服务,可加以封装实现同样的功能。附录中提供了相关的开源代码,并分别封装了reachability在iOS和Android平台上的实现。

3.2 检测心跳超时和回包超时

心跳即每一定时间间隔(假定15秒)客户端和服务器进行一次请求/应答,来判断对方是否存活。若客户端发送请求成功后,长久(假定60秒)未收到服务器的回应,则认为连接已经中断或者服务器宕机。若服务器长久(假定300秒)未收到客户端请求,则可以认为客户端已经离线。另外常规的业务数据包也可以认为是心跳包的扩展,所以每次业务数据包通信成功,客户端和服务器都要重新计时。一般心跳包是一个空的数据包,以节约流量,但通常也会包含少量字段,比如客户端和服务器的时间同步信息等。

一些关键协议,比如进入房间的请求,需要等待服务回应后才能扣除体力进入房间。但网络不稳定时,可能客户端的请求发送成功,服务器的回应却迟迟没有收到,这种情况下,客户端需要做一个超时控制,比如15秒后客户端还没有收到回包,则给出提示,不能让客户端无限的等待。这种因果关联的一对协议我们称作请求-应答协议,建议所有关键协议都采用这种机制。有一点要注意,这种异步操作有一个等待的时间,一般这段时间都会屏蔽输入(转菊花/show activity indicator),避免用户进行其他操作导致重复请求。这也要求我们在代码逻辑层面上避免多个关键协议的嵌套和并发。

3.3 检测发包失败

一般来讲reachability足够灵敏可靠,设备网络发生变化时能及时感知,只要监听到状态切换为NOTREACHABLE便可认为断线了(需要排除瞬断的情况),但reachability也有限制,无法感知到传输层连接断开。举个例子:手机和无线路由器连接正常,但是无线路由器和modem连接中断,这时reachability是检测不到网络断开的。此时需要依据socket错误码来判断网络情况。

3.4 检测socket状态

以上几种机制都是在应用层做网络状况检测,基本上可以应对大部分情况,但有时为了更好的用户体验,我们需要更加精准的检测方式。获取socket底层错误码及状态能为我们提供更多的判断依据。因实际项目中并未用到这方面的内容,便不在这里扩展。

3.5 检测网络延迟

某些类型的游戏对网络延迟特别敏感(如实时对战类游戏),较高的网络延迟将会导致惨不忍睹的体验。这些类型的游戏不但要从技术层面做优化,同时也要根据用户当前的网络延迟加以限制。比如平均延迟在1000ms以上便提示无法游戏。我们可以采用两种方式评估延迟:信号强度(received signal strength indication)和收发包时间统计。

1) 信号强度(RSSI)检测:这种判断网络延迟的方式不具客观性,因为网络延迟不仅取决于信号强度,同时受到带宽、传输节点数、网络硬件吞吐量等一系列因素的影响。但在其他参数相对固定的情况下,我们仍然可以参考信号强度来评判网络状况,同reachability类似,RSSI能及时给我们当前网络状态的反馈。在Android平台上使用WifiManager类可以获取具体RSSI值及信号强度等级。不幸的是iOS 5.0及以后的系统都不再支持RSSI的获取(当然jailbreak之后还是可以的)。

2) 收发包时间统计:即在客户端和服务器时间同步的情况下,每个数据包带一个时间戳信息,基于过往的数据包计算平均网络延迟。这种检测方式相对合理,但是时效性较差,在网络波动频繁时不能及时正确评估,相反在连接平稳的网络环境中,会得到理想的效果。

在Android平台上要取得一个合理的网络延迟,可以结合以上两种方式。iOS平台上暂时还只能采用第二种方式。

4、断线重连机制

当检测到断线后,便可以启动重连模式。根据当前的游戏状态确定重连策略,一般有以下三种方式:

1) 静默重连,即在用户无感知的情况下进行重连。一般检测到断线后,可以先尝试静默重连一定次数(比如3次)。如果在游戏对战过程中断线,一般也会尽量尝试静默重连并且忽略重连次数,因为此时弹出提示框会打断对战体验的完整性。静默重连提供了一种友好的用户体验,能应付一些短暂的网络中断(比如进出电梯或者进程从后台唤醒等)。

2) 显式重连,在静默重连一定次数(假定3次)之后,仍然无法连接成功的情况下,此时需要弹出提示框,中断游戏流程,告知用户当前网络环境较差,引导用户在网络较好时再尝试连接。

3) 服务器故障重连,这种情况下客户端无论如何是连接不到游戏服务器的。此时客户端也需要给出正确的引导,而不是误当作断线故障处理。因此我们在断线重连失败之后多加一个步骤:尝试连接CDN服务器,若CDN服务器可以正常连接,那么说明网络畅通,我们去获取CDN上的云配置,检查是否有服务器日常维护的标识,如果有则给出服务器日常维护的公告,否则可以认为服务器宕机,则给出服务器故障的公告。此步骤中若CDN服务器也无法连接,说明网络确实不畅通,可以继续走重连流程或者等待。

 5、网络协议的制定规范

要做到良好的重连体验,不仅需要良好的解决方案,也需要有协议上的支持。通常协议制定时可以参考以下规则:

1) 登录协议尽量简单,仅包含必须的字段(如玩家等级,金钱,体力等)。一般重连即需要走重新登录和鉴权流程,精简的登录协议能提高重连效率和节约流量。用户的非关键校验数据(比如背包数据,排行榜,卡牌信息)等可以延迟到界面开启时再请求或者使用本地缓存数据。

2) 协议的解耦,不同业务逻辑需要的请求包不同,这里就需要进行协议解耦,减少冗余数据,降低传输的包量,提高单包发送成功率。

3) 支持数据包压缩,对于较大的协议包(比如排行榜数据,好友数据等)需要做针对性的压缩,提高单包发送成功率。

4) 关键协议需要添加序列号,避免客户端重复请求造成的多次扣费等问题。

  6、CDN资源下载方案

随着硬件和技术的发展,移动游戏品质也和PC端游越来越接近,当然资源量也越来越接近。受限于移动网络带宽,较大的安装包给玩家设置了较高的门槛,因此目前的手游产品也越来越多的考虑微端方案。即安装包只包含部分游戏关卡,或者只作为一个下载器,而完整的游戏资源放在CDN资源服务器上,然后按需下载,这也是一般页游的思路。这种情况下,我们对比了几种打包机制给大家参考。

<todo>测试数据稍后提供</todo>

附录1:断线重连流程图

附录2:RSSI信号强度分级