断线重连的需求一断线重连原理二游戏内自动重连不刷新三刷新游戏自动重连重连数据locationreplace重置url重连四实际项目中处理重连机制最后的总结断线重连的需求，尤其是手机上，会因为网络的不稳定或者其他原因，导致用户的socket链接断开。这个时候如果直接让玩家退出游戏，重新登录，无疑是非常影响用户体验的事情。所以根据这个需求，就有需要程序来实现断线后自动重连回去的技术，是用户能够再次快速开始游戏进行战斗。
一、断线重连原理
原来其实很简单，就是在断线的时候，根据用户的点击（有些时间短的就不用点击，默认是自动重连回来），程序自动识别，是要刷新重新进入游戏还是帮用户自动重连。客户端会根据自动重连标记，帮用户自动做事情。比如自动登陆、选角色、进入场景、请求同步后台数据等等。
根据实现机制，大致可以分两种实现方法。主要是游戏内自动重连（不刷新）和刷新游戏自动重连，后面会详细讲两种实现机制，以及相关的利弊。
二、游戏内自动重连（不刷新）
立即学习“Java免费学习笔记（深入）”；
这种是比较难的，因为不刷新游戏，那么会因为一段时间的断开游戏，导致客户端数据跟服务器数据不同步了。比如怪物的位置、获得的奖励、进度等等。这些需要一开始就设计好，如果策划在后期要求加这个，那几乎是无法实现的，改动太大了。所以假设要这么多，大概是类似下面的做法。（如果真要详细，得一篇新的Blog了:）
1. 客户端和服务端协定好那些数据需要客户端自己同步
2. 断线多久内可以自动重连（策划以及技术上的实现来互相评估）
3. 服务端提供自动重连的协议，同时用户断线第一时间不应该就销毁掉相关数据(这里比较复杂，比如自动战斗是否要一直在服务器挂着，以及其他的一些关联操作)
4. 客户端不刷新游戏，使用新接口重新连接服务器，自动更新和同步相应的数据（比如同步怪物位置或者其他人物位置等等）
这种技术一般用于回合制之类的游戏，一般不涉及战斗系统。如果arpg的话，只能短暂的时间内可以自动重连，不然的话变数太大。或者需要做一些变种，比如单纯场景的怪物之类的刷新下，但是世界boss之类的场景就得重新载入之类的特殊处理。
三、刷新游戏自动重连
我个人感觉这个是简单粗暴又实用的做法。大部分游戏都适合使用，只要一刷新，游戏的数据都没了，全部重新开始，客户端只需要根据标记来做一些自动化的操作，容易很多。，同时服务器也不用更改，稳定也不容易出错。唯一不好的就是用户体验会稍微差一些。
重连数据
字符串数据：
//ip + 用户标识 + 服id + 服名字 （数据根据自己项目情况） var reload:string = ip + "#" + token + "#" + serverId + "#" +serverName; //后面的reload字符串都是这里的内容
重连标识：
reload //字符串
注意：刷新只能刷新自己的页面。（比如在iframe里面的时候）
Location.replace重置url重连
这种比较简单，也不会有什么兼容性的问题。就是重连的时候，把之前的登录用户以及服务端地址给记录起来
通过url来附带参数，最后再实际使用中解析出来，通过判断属性是否重载，
Location 对象的replace()方法：用新的文档替换当前文档。
通过传入新的url(其实是原url + 附带重连数据)
location.replace(oldUrl + "reload#" + reload);
是必须走url，而且还需要和原来的参数进行兼容处理。在游戏游戏中可能是这样的url了：
地调试1
http://localhost:63342/game/index.html?reload=1&host=ws://192.168.0.10:1050/ws&token
cookie 是存储于访问者的计算机中的变量。每当同一台计算机通过浏览器请求某个页面时，就会发送这个 cookie。你可以使用 JavaScript 来创建和取回 cookie 的值。
利用cookie的本地存放功能，也比较方便，但是会有些手机浏览器可能会无法读取到。
document.cookie = "reload#" + reload;
1.使用Html5的window.localStorage
localStorage 属性允许你访问一个 local Storage 对象。localStorage 与 sessionStorage 相似。不同之处在于，存储在 localStorage 里面的数据没有过期时间（expiration time），而存储在 sessionStorage 里面的数据会在浏览器会话（browsing session）结束时被清除，即浏览器关闭时。
应该注意的是，无论是 localStorage 还是 sessionStorage 中保存的数据都仅限于该页面的协议。
既然是H5游戏，当然重点是使用这个了，先看下localStorage的API
。
window.localStorage.setItem("reload", reload);读取：
var reload = window.localStorage.getItem("reload");1.使用Egret的本地保存
使用Egret会更方便，他进行了封装，H5和打包成本地都可以支持。localStorage.ts
egret.localStorage接口
//保存数据
export let getItem:(key:string)=>string;
//删除数据
export let removeItem:(key:string)=>void;
//将所有数据清空
export let clear:()=>void;
Web实现类WebLocalStorage.ts
namespace egret.localStorage.web {
function getItem(key:string):string {
return window.localStorage.getItem(key);
}
function setItem(key:string, value:string):boolean {
try{
window.localStorage.setItem(key, value);
return true;
}
catch(e){
egret.$warn(1047, key, value);
return false;
}
}
function removeItem(key:string):void {
window.localStorage.removeItem(key);
}
function clear():void {
window.localStorage.clear();
}
localStorage.getItem = getItem;
localStorage.setItem = setItem;
localStorage.removeItem = removeItem;
localStorage.clear = clear;
}可以看到内部其实也是采用了window.localStorage来进行实现，同时做了一场处理，最后是通过localStorage接口进行赋值给外部调用。下面是实际使用方法：
//使用egret的本地存放方法做
egret.localStorage.setItem("reload",reload);
//游戏中获取
var reload:string = egret.localStorage.getItem("reload");四、实际项目中处理重连机制
这里的代码是刷新之后重新进入游戏，然后通过之前的数据（url或者本地缓存）解析出相应的数据来进行判断。
解析url
var reload:string = location.href;
本地缓存获取数据
var reload:string = egret.localStorage.getItem("reload");
console.info("reload数据:" + reload);
if(reload && reload != "")
{
var cooks:string[] = reload.split("#");
console.info("断线重连刷新过来的");
this.session.isReload = true;
this.session.host = cooks[0];
this.session.token = cooks[1];
this.session.serverId = Number(cooks[2]);
this.session.serverName = cooks[3];
}通过游戏内的变量进行判断处理
if(this.session.isReload)
{
//开始自动重连，走额外的协议以及自动处理
}
else
{
//走正常的流程
}最后的总结
断线重连这里主要是讲了一些思路以及实际项目中的应用。代码算是伪5代码了，读者应该根据自己项目实际情况来设计，做一些相应变化，原理是一样的。
我们有一个项目是有遇到过其中的一个问题，因为一开始没有考虑自动重连的问题，在客户端和服务器都没这里的考虑。所以没办法做到不刷新游戏来进行重连（主要是成本太大，又是arpg游戏），最终是选择了游戏自己刷新来实现的机制的。当然也会遇到一些坑，比如接入一些平台，只能刷新自己的html，无法刷新平台的html（游戏内嵌），导致平台的sdk的问题（影响充值、关注等等）。不过最终都是有通过变通之类的进行解决了。
相关推荐：
