⼩程序之WebSocket
本⽂版权归 OSChina jsongo0 所有，转载请标明出处，以⽰尊重！
为什么需要websocket？
传统的实时交互的游戏，或服务器主动发送消息的⾏为（如推送服务），如果想做在上，可能你会使⽤轮询的⽅式进⾏，不过这太消耗资源，⼤量的请求也加重了服务器的负担，⽽且延迟问题⽐较严重。如果是⾃⼰开发的app，为了解决这些问题，很多团队会⾃建socket，使⽤tcp长链接、⾃定协议的⽅式与服务器进⾏相对实时的数据交互。有能⼒的团队，采⽤这种⽅式⾃然没什么⼤问题。不过⼩团队可能就要花费很多时间去调试，要解决很多难题，这个在成本上就划不来。
H5引⼊了webSocket来解决⽹页端的长链接问题，⽽⼩程序也⽀持websocket。这是⼀个⾮常重要的特性，所以本系列的⽂章会专门拿出⼀篇来讨论websocket。webSocket本质上也是TCP连接，它提供全双⼯的数据传输。⼀⽅⾯可以避免轮询带来的连接频繁建⽴与断开的性能损耗，另⼀⽅⾯数据可以是⽐较实时的进⾏双向传输（因为是长链接），⽽且WebSocket允许跨域通信（这⾥有个潜在的跨域安全的问题，得靠服务端来解决）。⽬前除IE外的浏览器已经对webSocket⽀持得很好了，⼩程序再推⼀把之后，它会变得更加流⾏。
游戏规则是这样的：把雷换成⾦⼦，挖到⾦⼦加⼀分，每⼈轮流⼀次（A挖完轮到B，B挖完A才能再点击），点中⾦⼦就算你的，也不会炸，游戏继续，直到把场上所有的⾦⼦都挖完游戏才结束。跟扫雷⼀样，数字也是表⽰周边有⼏个⾦⼦，然后⽤户根据场上已经翻出来的数字来猜哪⼀格可能有⾦⼦。
这种交互的游戏难点在于，⽤户的点击操作都要传到服务器上，⽽且服务器要实时的推送到其它玩家的应⽤上。另外⽤户⾃⼰也要接收对⽅操作时实时传过来的数据，这样才不⾄于重复点中同⼀个格⼦。简单讲，就是你要上报操作给服务器，⽽服务器也要实时给你推消息。为了简化整个模型，我们规定玩家必须轮流来点击，玩家A点完后，才能轮到玩家B，玩家B操作完，玩家A才能点。
我们分⼏步来实现这个功能。
⼀、实现思路
1、第⼀步，我们要先⽣成扫雷的地图场景
这个算法⽐较简单，简述⼀下。随机取某⾏某列就可以定位⼀个格⼦，标记成⾦⼦（-1表⽰⾦⼦）。mimeCnt表⽰要⽣成的⾦⼦的数量，⽤同样的⽅式循环标记mimeCnt个随机格⼦。⽣成完后，再⽤⼀个循环去扫描这些-1的格⼦，把它周边的格⼦都加1，当然必须是⾮⾦⼦的格⼦才加1。代码放在。
其中increaseArround⽤来把这格⾦⼦周边的格⼦都加1，实现也⽐较简单：
执⾏genMimeArr()，随机⽣成结果如下：
-1表⽰⾦⼦。看了下貌似没什么问题。接下去，我们就要接⼊webSocket了。
（这个是js版本的，其实⽣成地图场景的⼯作是在后台⽣成，这个js版本只是⼀个演⽰，不过算法是⼀样的。）
2、我们需要⼀个⽀持webSocket的服务端
本例⼦中，我们使⽤python的tornado框架来实现（tornado提供了tornado.websocket模块）。当然读者也可以使⽤socket.io，专为webSocket设计的js语⾔的服务端，⽤起来⾮常简单，它也对不⽀持webSocket的浏览器提供了兼容（flash或comet实现）。
笔者本⼈⽐较喜欢使⽤tornado，做了⼏年后台开发，使⽤最多的框架之⼀的就是它，NIO模型，⽽且⾮常轻量级，同样的rps，java可能需要700-800M的内存，tornado只要30-40M，所以在⼀台4G内存的机⼦上可以跑上百个tornado服务，⽽java，对不起，只能跑3个虚拟机。微服务的时代，这⼀点对⼩公司很重要。当然如果读者本⼈对java⽐较熟悉的话，也可以选择netty框架尝试⼀下。
webSocket⽤tornado的另⼀个好处是，它可以在同⼀个服务（端⼝）上同时⽀持webSocket及http两种协议。tornado的官⽅demo代码中展⽰了怎么实现同时使⽤两种协议。在本游戏中，可以这么⽤：⽤户
进⼊⾸页，⽤http协议去拉取当前的房间号及数据。因为⾸页是打开最多的，进了⾸页的⽤户不⼀定会玩游戏。所以⾸页还没必要建⽴webSocket链接，webSocket链接主要⽤来解决频繁请求及推送的操作。⾸页只有⼀个请求操作。选了房间号后，进去下⼀个游戏页⾯再开始建⽴webSocket链接。
3、客户端
使⽤⼩程序开发⼯具，直接连接是会报域名安全错误的，因为⼯具内部做了限制，对安全域名才会允许连接。所以同样的，这⾥我们也继续改下⼯具的源码，把相关的⾏改掉就⾏修改⽅式如下：
到asdebug.js的这⼀⾏，把它改成: if(false)即可。
if (!i(r, "webscoket"))
注：笔者⽬前使⽤IDE版本为 0.11.112301 修改代码部分为 if(!(0,l.checkUrl)(o,"webscoket")) ===》 if(false&&!(0,l.checkUrl)(o,"webscoket")) 即可
懒得修改的读者可以直接使⽤我破解过的IDE。发起⼀个websocket链接的代码也⽐较简单：
url: webSocketUrl,
});
在调⽤这个请求代码之前，先添加下事件监听，这样才知道有没有连接成功：
console.log('websocket opened.');
});
连接失败的事件：
console.log('websocket fail');
})
收到服务器的消息时触发的事件：
console.log('received msg: ' + res.data);
})
当链接建⽴之后，发送消息的⽅法如下：
wx.sendSocketMessage({
data:msg
})
消息发送
由于建⽴链接是需要⼏次握⼿，需要⼀定的时间，所以在wx.connectSocket成功之前，如果直接wx.sendSocketMessage发送消息会报错，这⾥做⼀个兼容，如果连接还没
建⽴成功，则⽤⼀个数组来保存要发送的信息；⽽链接第⼀次建⽴时，把数据遍历⼀遍，把消息拿出来⼀个个补发。这个逻辑我们封装成⼀个send⽅法，如下：
function sendSocketMessage(msg) {
if (typeof(msg) === 'object') { // 只能发送string
msg = JSON.stringify(msg);
}
if (socketOpened) { // socketOpened变量在wx.onSocketOpen时设置为true
wx.sendSocketMessage({
data:msg
});
} else { // 发送的时候，链接还没建⽴
socketMsgQueue.push(msg);
}
}
⼆、demo功能解析
1、⾸页entry
为了简化模型，把重点放在webSocket上，我们把⾸页做成⾃⼰填写房间号的形式。读者如果⾃⼰有时间和能⼒的话，可以把⾸页做成⼀个房间列表，并显⽰每个房间有多少⼈在玩，只有⼀⼈的可以进去跟他玩。甚⾄后⾯还可以加上观看模式，点击别⼈的房间进去观看别⼈怎么玩。
填写房间号的input组件，添加⼀个事件，取得它的值event.detail.value后setData到本page⾥⾯。
点击“开始游戏”，再把房间号存⼊app的globalData⾥⾯，然后wx.navigateTo到主游戏页⾯index。
这个页⾯⽐较简单。
2、主游戏页⾯
我们封装⼀个websocket/connect.js模块，专门⽤来处理websocket链接。主要有两个⽅法，connect发起webSocket链接，send⽤来发送数据。
index主页⾯：
初始化状态，9x9的格⼦，每⼀格⼦其实都是⼀个button按钮。我们⽣成的地图场景数据，分别对应着每⼀格。⽐如1表⽰周边的1个⾦⼦，0表⽰周边没有⾦⼦，-1表⽰这格是个⾦⼦，我们的⽬标就是到这些-1。得越多得分越⾼。
这⾥讨论⼀个安全性问题。相信⼀句话：在前端做的安全措施⼤都是不靠谱的。上图中的矩阵，每个格⼦背后的数据，不应该放在前端，因为js代码是可以调试的，可以下断点在相应的变量上，就可以看到整个矩阵数据，然后就知道哪些格⼦是⾦⼦，就可以作弊，这是⾮常不公平的。所以最好的⽅法是把这些矩阵数据存在后端，每次⽤户操作的时候，把⽤户点击的坐标发到后台，后台再判断相应的坐标是什么数据，再返回给前端。这个看似有很多数据传输的交互⽅式，其实是不会浪费资源，因为⽤户的每个点击操作，本来就要上报到后台，这样游戏的另⼀玩家才知道你点了哪个格⼦。反正都是要传数据的，所以肯定要传坐标，这样前端就完全没有必要知道哪个格⼦是什么数据，因为后台的推送消息会告诉你。
这样我们就绕过了前端存矩阵数据的问题。但是我们还是需要⼀个数组来存储当前矩阵状态的，⽐如哪个格⼦已经被翻开，⾥⾯是什么数据，也就是说要存储场上已经被打开的格⼦。所以在后台，我们要存储两个数据，⼀个是所有的矩阵数据，也就是地图场景数据；另⼀个是当前状态的数据，这个要⽤来同步双⽅的界⾯。
3、结束页⾯
游戏结束的判断条件，就是场上所有的⾦⼦都被挖完了。这个条件也是在后台判断的。
在每次⽤户挖到⾦⼦的时候，后台都会多⼀个判断逻辑，就是看这个⾦⼦是否是最后⼀个。如果是的话，就发送⼀个over类型的消息给游戏的所有玩家。
玩家终端接收到这个消息时，就会结束当前的游戏，并跳到结束页⾯。
没有专门的设计师，随便⽹上偷了张图⽚贴上去，界⾯⽐较丑。下⽅显⽰⾃⼰的得分和当前的房间号。
三、实现细节
1、代码结构
前端代码，分了⼏个模块：pages放所有的页⾯，common放通⽤的模块，mime放挖⾦⼦的主逻辑（暂时没⽤到），res放资源⽂件，websocket放webSocket相关的处理逻辑。
后台代码，读者稍微了解⼀下就⾏了，不讨论太多。⾥⾯我放了docker⽂件，熟悉docker的读者可以直接⼀个命令跑起整个服务端。笔者在⾃⼰的服务器上跑了这个webSocket服务，ip和端⼝已经写在前端代码⾥，读者轻虐。可能放不久，读者可以⾃⼰把这个服务跑起来。
2、消息收发
（1）消息协议
我们简单地定义下，消息的格式如下。发送消息：
{type: 'dig', …}
type是必带字段。
服务器返回的消息：
{errCode: 0, data: {type: 'dig', …} }
errCode为0的时候，表⽰请求处理成功，后⾯带上data字段表⽰返回的数据，⾥⾯的type也是必带字段，表⽰的是什么类型的消息。
因为webSocket类型的消息跟传统的http请求不太⼀样，http请求没有状态，⼀个请求过去，⼀会⼉就返回，返回的数据肯定是针对这个请求的。⽽webSocket的模型是这样的：客户端发过去很多请求，然后也不知道服务器返回的数据哪个是对应哪个请求，所以需要⼀个字段来把所有的返回分成多种类型，并进⾏相应的处理。
（2）发送消息
发送消息就⽐较容易了，上⾯我们定义了⼀个send⽅法及未连接成功时的简单的消息列表。
（3）接收消息
读者在阅读代码的时候，可能会有⼀个疑惑，websocket/connect.js⾥只有send发送⽅法，⽽没有接收推送消息的处理，那接收消息的处理在哪？怎么关联起来的？websocket/⽬录⾥⾯还有另⼀个⽂件，msgHandler.js，它就是⽤来处理接收消息的主要处理模块:
从服务器推送过来的消息，主要有这三种类型：1挖⾦⼦操作，可能是⾃⼰的操作，也可能是对⽅的操作，⾥⾯有⼀个字段isMe来表⽰是否是⾃⼰的操作。接收到这类消息时，会翻转地图上相应的格⼦，并显⽰出挖的结果。2创建或进⼊房间的操作，⼀个房间有两个⽤户玩，创建者先开始。3游戏结束的消息，当应⽤接收到这类消息时，会直接跳转到结束页⾯。
这个处理逻辑，是在websocket/connect.js的wx.onSocketMessage回调⾥关联上的。
在消息的收发过程中，每个消息交互，调试⼯具都会记录下来。可以在调试⼯具⾥看到，在NetWork->WS⾥就可以看到：
3、前端挖⾦⼦
代码如下：
var websocket = require('../../websocket/connect.js');
var msgReceived = require('../../websocket/msgHandler.js');
Page({
data: {
mimeMap: null,
leftGolds: 0, // 总共有多少⾦⼦
score: 0,    // 我的得分
roomNo: 0    // 房间号
},
x: 0, // ⽤户点中的列
y: 0, // ⽤户点中的⾏
onLoad: function () {
var roomNo = RoomNo();
this.setData({
roomNo: roomNo
});
// test
// websocket.send('before connection');
if (!websocket.socketOpened) {
// setMsgReceiveCallback
websocket.setReceiveCallback(msgReceived, this);
// connect to the websocket
websocket.send({
type: 'create'
});
}
else {
websocket.send({
type: 'create',
no: roomNo
});前端websocket怎么用
}
},
digGold: function(event) { // 不直接判断，⽽把坐标传给后台判断
// 被开过的就不管了
if (event.target.dataset.value < 9) {
return;
}
// 取到这格的坐标
this.x = parseInt(event.target.dataset.x);
this.y = parseInt(event.target.dataset.y);
console.log(this.x, this.y);
// 上报坐标
},
reportMyChoice: function() {
roomNo = RoomNo();
websocket.send({
type: 'dig',
x: this.x,
y: this.y,
no: roomNo
});
},
});
在page的onLoad事件⾥，先更新界⾯上的房间号信息。然后开始我们的重点，t发起webSocket链接，websocket是我们封装的模块。然后把我们msgHandler.js处理逻辑设置到服务端推送消息回调⾥⾯。接着，发送⼀个create消息来创建或加⼊房间。服务端会对这个消息做出响应，返回本房间的当前状态数据。digGold是每个格⼦的点击事件处理函数。这⼉有⼀个逻辑，⼀个格⼦周边最多有8个格⼦，所以每个格⼦的数据最⼤不可能⼤于8，上⾯代码中可以看到有⼀个9，这其实是为了跟0区分，⽤来表⽰场上⽬前的还没被翻开的格⼦的数据，⽤9来表⽰，当然你也可以⽤10，100都⾏。
wxml的矩阵数据绑定代码如下：
<view wx:for="{{mimeMap}}" wx:for-item="row" wx:for-index="i"
class="flex-container">
<button wx:for="{{row}}" wx:for-item="cell" wx:for-index="j"
class="flex-item {{cell<0?'gold':''}} {{cell<9?'open':''}}"
bindtap="digGold" data-x="{{j}}" data-y="{{i}}" data-value="{{cell}}">
{{cell<9?(cell<0?'*':cell):"-"}}
</button>
</view>
这个⽐较复杂些。两层for，第⼀层遍历⾏，第⼆层遍历⾏⾥的每个格⼦的数据。wx:for-item指定⾥⾯⽤到的item的名字，wx:for-index指定⾥⾯⽤到的key的名字。每个格⼦是⼀个button，class值做了两次判断，如果这个格⼦的数据⼩于0，表⽰它是⾦⼦，加上gold这个class，主要是为了给它加样式。⽽当数据是⾮9的时候，表⽰这个格⼦被翻开了，这时就加上open样式，把颜⾊设置成橙⾊。data-x和data-y⽤来记录格⼦的坐标，这样的话，⽤户点击的时候，就可以直接从dataset⾥取出坐标值，再把这个值发到服务端进⾏判断。
4、服务端实现
简单的提⼀下就好，因为后台不是本系列⽂章的重点，虽然这个demo的开发也花了⼤半的时候在写后台。前后端的消息交互，借助了webSocket通道，传输我们⾃⼰定义格
式的内容。上⾯有个截图显⽰了后台代码⽬录的结构，划分得⽐较随意，handlers⾥存放了的是主要的处理逻辑。webSocketHandler是⼊⼝，在它的on_message⾥，对收到的客户端的消息，根据类型进⾏
分发，dig类型，分发到answerHandler去处理，create类型，分发到roomHandler⾥去处理。
还有⼀点稍微提⼀下，本例⼦中的后台webSocket消息处理也跟传统的http处理流程有⼀点不⼀样。就是在最后返回的时候，不是直接返回的，⽽是⼴播的形式，把消息发送给所有的⼈。⽐如⽤户A点击了格⼦，后台收到坐标后，会把这个坐标及坐标⾥的数据⼀起发送给房间⾥的所有⼈，⽽不是单独返回给上报坐标的⼈。只是会有⼀个isMe 字段来告诉客户端是否是⾃⼰的操作。
总之，在做webSocket开发的时候，上⾯提到的，前后端都可能会有⼀些地⽅跟传统的http接⼝开发不太⼀样。读者尝试在做webSocket项⽬的时候，转换⼀下思维。
最后提下⼀个注意点：⼩程序的websocket链接是全局只能有⼀个，官⽅提⽰：“”

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。