这是一个创建于 443 天前的主题，其中的信息可能已经有所发展或是发生改变。
websocket 高频率传递一些数据（有些数据很大）给 UI 页面， 是使用 web worker 将 socket 连接也放在 websocket 里接收数据并处理好发给 UI ，还是在 UI 中创建 websocket ，将接收的数据传给 worker ，worker 解析处理好 再返回给 UI
需要设计的操作 字符串解析， 编码解码，转码
 |
1
pannanxu 2023-09-07 17:42:48 +08:00
有没有意义取决于目前是否页面卡顿，让在 webworker 里是否能够解决。
|
 |
2
Dididadada 2023-09-07 18:14:23 +08:00
这个还是测试结果说了算，也许高频的跨 worker 通信效率更低呢，也可以试试在 wasm 中做数据处理
|
 |
3
zbinlin 2023-09-07 18:46:13 +08:00
既然用了 web worker ，这不是应该就放到 web worker 中做的吗
|
 |
4
hanguofu 2023-09-07 19:39:58 +08:00
伸手党求一份 WebSocket 的 web worker 代码，谢谢~~~
|
 |
5
laters OP @zbinlin 现在考虑的是 1. 将 websocket 的连接 接收 解析 处理数据 都放在 woker 中 2. websocket 的连接 接收数据放在 UI ， 解析 处理数据 放在 woker 中 ，不知道哪种性能更好
|
|
6
laters OP @pannanxu 现在考虑的是 1. 将 websocket 的连接 接收 解析 处理数据 都放在 woker 中 2. websocket 的连接 接收数据放在 UI ， 解析 处理数据 放在 woker 中 ，不知道哪种性能更好
|
 |
7
MossFox 2023-09-07 21:00:17 +08:00
高频传输数据的话，Socket 还是放在 Worker 里面吧，处理的那部分感觉放哪都可以，按照个人的习惯估计会 Worker 处理好然后发给 UI 。
以前整过一个走 WebSocket 的一秒 60 个包的延迟测试用的玩意，数据包非常小，解析耗时几乎可以不考虑，但有个界面层的折线图更新。 然后就发现这个 Socket 不分出去的情况下，在测试的处理器一般的移动设备上，统计到的延迟数据就被界面的更新阻塞干扰了，非常不准确。 分出去到一个 Worker 中创建 WS 以及解析和统计来回延迟之后，就算绘图部分更新频率跟不上，Worker 那边记录的延迟至少基本是正确的了，界面按照合适的间隔拉一下数据更新图像就可以。 复杂的用例因为没有做过，很多细节还是没有数的。所以总之还是建议实际测一下运行效率看看不同方案表现怎么样。浏览器开发者工具里面可以看到页面被阻塞的耗时，参考那个就可以。 |
|
8
laters OP @MossFox 请问有没有类似的开源项目可以参考下风格，浏览器开发者工具看到页面被阻塞的耗时请问是哪个地方，可以说明确下吗，谢谢
|
|
9
zbinlin 2023-09-07 22:13:23 +08:00
如果你在主线程中接收数据，还是要传到 worker 里来处理，最后又需要传出来给 UI ，这不是比在 worker 接收并处理再传出来多一步传输的损耗了？
|
Select Language