color: #EB5E28
animation: heathing 1s ease infinite
}
@keyframes heathing {
0% {
transform: scale(0.75)
}
20% {
transform: scale(1)
}
40% {
transform: scale(0.75)
}
60% {
transform: scale(1)
}
80% {
transform: scale(0.75)
}
100% {
transform: scale(0.75)
}
}
假定这个元素id=heart，则答案如此。
websocket是个很优秀的工具，网络上很多例子不适合，也不合乎逻辑，是发送心跳包不错，但是如何通过发送心跳包判断是否断开，这个大家说法不一样，99%的言论说是判断有没有接收到客户端反馈，有没有接收到服务端反馈。如果你这么想，你的程序就会不间断的掉线，实际上他没掉线。自己下载一个360流量监测工具，或者用调试窗口看流量消息，程序就让timer一直发数据包。你会发现他发送有规律，接收数据是没有时间规律，有时候反应快点就很快 接收了，有时候反应慢了（很多未知因素可能来自操作系统）那就迟点接收咯。你如果规律型的去判断有没有接收到数据，那就很有可能误判，而且这个可能性是100%。最后你会发现你的逻辑不间断性掉线，甚至你会怀疑是websocket的问题。
其实websocket通信就像打电话，我打对方接才算通，对方挂断我自然在手机上看到断开了，都没办法把话说出去，心跳包就是保持通话，你不说话了不代表就断开了，你说了对方没回应也不代表就挂断了。webScocket有个事件叫OnError，都不知道用来干嘛的，我看很少有人使用过，这个就是挂断了话都说不出去触发的。
前段时间看网络上说腾讯应提问socket服务端会及时感知客户端断开吗？都是说不行，其实可以，服务端在每秒发送心跳包，发送报错就表示断开了。触发了OnError事件就让用户列表下线，客户端也能立即感知，timer判断socket.state，他一直是open就是在线的，不是就断开了。怎样维持心跳的思路我说清楚了，大概实现就是这样：
onOpen客户端接入，在这个事件发送一个命令，通知他服务端已经接通，让他汇报自己的信息包括用户称呼之类的，客户端接到通知，发送消息汇报自己，服务端onMessage接收到汇报更新用户列表。onClose也是要客户端关闭socket，服务端触发才能下线。还有一个onError事件怎么用？服务端timer定时发送一个数据，发送不出去自然就触发了onError，T用户下线。
客户端就计时器一直判断socket.state咯。
