WebSocket是现在很主流的协议,大范围使用在即时通讯,协同协作等功能中,它很好的弥补了HTTP协议的不足,可以很容易的实现长连接。
如果你使用的是HTTP协议,假设一个场景:
我是张三,准备和李四聊天,我发给李四一个“你好”,程序中经历的过程是我的客户端将“你好”发送给服务端,服务端经过简易包装,准备发给李四的客户端。
那么,如果是HTTP协议,服务端如何将“你好”发送给李四的客户端?
HTTP的特点是,只可以客户端请求,服务端响应,也就是基本的request response,服务端理论上是不可以主动给客户端推送消息的。就好像一个渣男,只有我可以给你发消息,你才能回复我,你不能主要给我发消息~~
基于这种现状,服务端想将“你好”发送给李四的客户端,只有一种可能,李四的客户端不断的请求服务端,也就是经典的“轮询”。虽然也可以实现既定的功能,但是很明显这种实现非常的消耗资源,很“愚蠢”,很消耗服务端的资源,因为大量的请求是没有任何意义的。
WebSocket协议的出现就是为了解决这种历史问题,服务端可以主动向客户端推送消息,真正意义的实现了双向平等通信。
近期,我在给一个同学做微信小程序项目时,需要做即时通讯的功能,这也是我第一次在微信小程序中使用WebSocket,之前都是在Web端用原生写的。
微信小程序中几乎给你用的所有东西都要经过一层封装,当然WebSocket也不例外,
在早期,微信提供了以下独立的WebSocket API
wx.sendSocketMessage(客户端发送消息)wx.onSocketOpen(监听连接建立)wx.onSocketMessage(监听服务端发送的消息)wx.onSocketError(监听连接异常)wx.onSocketClose(监听连接关闭)由于状态不容易管理,且API过于独立,所以微信后续推出了SocketTask对象,可以理解为一个实例,基于这个实例进行各种WebSocket事件的监听和处理,比较容易管理。
这个SocketTask对象其实使用起来也很简单,也是那几个事件:
SocketTask.send(),客户端发送消息给服务端SocketTask.close(),关闭WebSocket连接上面这两个是主动的、单次的、干净利索的动作,不是监听某些事件。
SocketTask.onOpen(),监听WebSocket连接的建立SocketTask.onClose(),监听WebSocket连接的关闭SocketTask.onError(),监听WebSocket连接出现的错误SocketTask.onMessage(),监听服务端发送给客户端的消息上面这四个是监听事件,是长期的动作。
举个例子,我向张三说一句“你好”,这是单次的、主动的、干净利索的动作,我偷偷跟踪张三看看他最近几天在干嘛,这是长期的监听动作。
首先要使用的就是WebSocket连接的建立,这是一切的前提,只有连接成功的被建立,才可以进行后续的操作。
我在微信小程序中,一般都是在app.js中创建SocketTask实例,因为SocketTask是面向全局的而不是某几个页面。
this.globalData = {}
this.globalData.SocketTask = wx.connectSocket({url: 'ws://xxxxxxxxxx'
});
因为是WebSocket协议,所以前缀是ws或者wss,然后我们将通过wx.connectSocket创建的SocketTask实例绑定在全局的globalData中,方便全局使用。
然后就可以开始各种事件的监听了。
监听连接打开
this.globalData.SocketTask.onOpen((res) => {console.log('websocket连接建立', res);
})
监听连接关闭(很有用)
this.globalData.SocketTask.onClose((res) => {console.log('websocket连接断开', res);
})
监听连接出现的异常
this.globalData.SocketTask.onError((err) => {console.log('websocket连接出现异常', err);
})
以上这些基本都可以放到app.js中。
监听服务端发给客户端的消息。
这个事件一般都会分布到各个页面。
比如我们在pages/message/message页面的js文件
// 创建app.js的应用实例
const app = getApp();Page({//xxx//xxxxonLoad(options) {// 将SocketTask对象解构出来const { globalData: { SocketTask } } = app;// 监听服务端消息SocketTask.onMessage((data)=> {console.log("websocket服务端发来的消息",data);})}
})
onMessage事件进行怎样的处理,取决于服务端的数据结构的设计,反正服务端发来的消息,都会放到监听事件的第一个参数里。
向服务端发送消息
这个方法也是普遍存在于各个页面。
比如在pages/chat/chat页面
// 创建app.js的应用实例
const app = getApp();Page({//xxxx//xxxxsendMessage() {const { globalData: { SocketTask } } = app;SocketTask.send({data: JSON.stringify({name: "李四",age: 18,xxxxx }) }) }
})
send方法里传递怎么样的数据也取决于实际的业务,只要放在data属性里即可,为了方便传输和接受一般都会通过JSON.stringify将数据转成字符串。
这个方法我用的比较少,作用是主动关闭连接,也是普遍存在于各个页面
// 创建app.js的应用实例
const app = getApp();Page({//xxxx//xxxxcloseChat() {const { globalData: { SocketTask } } = app;SocketTask.close({code: 1000,reason: xxxx,success: xxx,fail: xxx }) }
})
这个方法的参数也没有具体要求,可以都不传。
以上就是关于WebSocket在微信小程序中的基本使用,在使用过程中肯定会遇到各种问题,主要还是因为微信小程序的官方文档十分的不友好,大家都习惯了~~,多写写代码,多踩踩坑。
介绍完了WebSocket在小程序中的基本使用,接下来就说一说我遇到的最坑的一件事情。
我在微信开发者工具中写完了所有代码中,进行了功能的自测,都没啥问题。但是当我发布到线上后,出现了各种各样奇怪的问题。
经过我对服务端日志的排查和网上资料的参考,终于得出了一个原因,在微信小程序中WebSocket协议在一定时间内会自动断开,据说是一分钟~~。
我直接口吐芬芳,我在官方文档里可是一个字都没看到会自动断开的事情。。。
没办法,接受了店大欺客的客观事实后,寻找解决方案,其实解决方案也蛮多的。
我的方式是,将建立连接的代码封装一下,在SocketTask的onClose事件中监听连接断开后立即重连。
// app.js
App({onLaunch: function() {this.globalData = {};const initSocket = () => {this.globalData.SocketTask = wx.connectSocket({url: 'ws://xxxxxxxxx'});const openid = wx.getStorageSync('openid');if (!openid) {wx.login({success: (res) => {console.log(res);wx.request({url: 'http://xxxxxx/login',data: {code: res.code},success: (res) => {console.log(res);const { openid } = res.data;wx.setStorageSync('openid', openid);console.log(SocketTask);this.globalData.SocketTask.send({data: JSON.stringify({url: '/login',data: {openid: wx.getStorageSync('openid')}})})}})}})} else {this.globalData.SocketTask.onOpen((res) => {console.log('websocket连接建立', res);this.globalData.SocketTask.send({data: JSON.stringify({url: '/login',data: {openid: wx.getStorageSync('openid')}})})})}this.globalData.SocketTask.onClose((res) => {console.log('websocket连接断开', res);initSocket();})} }
})
这里面我参杂了一些我的业务代码,反正解决这个坑的原则是监听到WebSocket连接断开后就立刻重连。
工种号:Code程序人生