将 WebSocket 放在 WebWorker 上有意义吗？

[laters]

websocket 高频率传递一些数据（有些数据很大）给 UI 页面， 是使用 web worker 将 socket 连接也放在 websocket 里接收数据并处理好发给 UI ，还是在 UI 中创建 websocket ，将接收的数据传给 worker ，worker 解析处理好 再返回给 UI

需要设计的操作 字符串解析， 编码解码，转码

[pannanxu]

有没有意义取决于目前是否页面卡顿，让在 webworker 里是否能够解决。

[Dididadada]

这个还是测试结果说了算，也许高频的跨 worker 通信效率更低呢，也可以试试在 wasm 中做数据处理

[zbinlin]

既然用了 web worker ，这不是应该就放到 web worker 中做的吗

[hanguofu]

伸手党求一份 WebSocket 的 web worker 代码，谢谢~~~

[laters]

@zbinlin 现在考虑的是 1. 将 websocket 的连接 接收 解析 处理数据 都放在 woker 中 2. websocket 的连接 接收数据放在 UI ， 解析 处理数据 放在 woker 中 ，不知道哪种性能更好

[laters]

@pannanxu 现在考虑的是 1. 将 websocket 的连接 接收 解析 处理数据 都放在 woker 中 2. websocket 的连接 接收数据放在 UI ， 解析 处理数据 放在 woker 中 ，不知道哪种性能更好

[MossFox]

高频传输数据的话，Socket 还是放在 Worker 里面吧，处理的那部分感觉放哪都可以，按照个人的习惯估计会 Worker 处理好然后发给 UI 。

以前整过一个走 WebSocket 的一秒 60 个包的延迟测试用的玩意，数据包非常小，解析耗时几乎可以不考虑，但有个界面层的折线图更新。
然后就发现这个 Socket 不分出去的情况下，在测试的处理器一般的移动设备上，统计到的延迟数据就被界面的更新阻塞干扰了，非常不准确。
分出去到一个 Worker 中创建 WS 以及解析和统计来回延迟之后，就算绘图部分更新频率跟不上，Worker 那边记录的延迟至少基本是正确的了，界面按照合适的间隔拉一下数据更新图像就可以。

复杂的用例因为没有做过，很多细节还是没有数的。所以总之还是建议实际测一下运行效率看看不同方案表现怎么样。浏览器开发者工具里面可以看到页面被阻塞的耗时，参考那个就可以。

[laters]

@MossFox 请问有没有类似的开源项目可以参考下风格，浏览器开发者工具看到页面被阻塞的耗时请问是哪个地方，可以说明确下吗，谢谢

[zbinlin]

如果你在主线程中接收数据，还是要传到 worker 里来处理，最后又需要传出来给 UI ，这不是比在 worker 接收并处理再传出来多一步传输的损耗了？

[laters]

@zbinlin 好像是有道理

[Trim21]

@laters 开发者工具的性能选项卡