WebSocket在微信小程序中的应用

为什么需要websocket？ 传统的实时交互的游戏，或服务器主动发送消息的行为（如推送服务），如果想做在微信上，可能你会使用轮询的方式进行，不过这太消耗资源，大量的请求也加重了服务器的负担，而且延迟问题比较严重。如果是自己开发的app，为了解决这些问题，很多团队会自建socket，使用tcp长链接、自定协议的方式与服务器进行相对实时的数据交互。有能力的团队，采用这种方式自然没什么大问题。不过小团队可能就要花费很多时间去调试，要解决很多难题，这个在成本上就划不来。 H5引入了webSocket来解决网页端的长链接问题，而微信小程序也支持websocket。这是一个非常重要的特性，所以本系列的文章会专门拿出一篇来讨论websocket。 webSocket本质上也是TCP连接，它提供全双工的数据传输。一方面可以避免轮询带来的连接频繁建立与断开的性能损耗，另一方面数据可以是比较实时的进行双向传输（因为是长链接），而且WebSocket允许跨域通信（这里有个潜在的跨域安全的问题，得靠服务端来解决）。目前除IE外的浏览器已经对webSocket支持得很好了，微信小程序再推一把之后，它会变得更加流行。 我们来设计一个新的demo，一个比较有趣的小游戏，多人版扫雷，准确地讲，多人版挖黄金。 游戏规则是这样的：把雷换成金子，挖到金子加一分，每人轮流一次（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)即可。