江苏龙网

  1. 首页 > 生活 > >

为啥web worker可以在前端开多线程，解决单线程卡死页面的问题，但是没有得到广泛使用

原因有三：
其一是兼容问题，下图是Worker，兼容性还好。SharedWorker与ServiceWorker兼容性就麻烦了：
【为啥web worker可以在前端开多线程，解决单线程卡死页面的问题，但是没有得到广泛使用】 为啥web worker可以在前端开多线程，解决单线程卡死页面的问题，但是没有得到广泛使用

其二是出来得比较晚，开发者不熟悉，自然就少用。很多开发者连Array.prototype.some都懒得用，更不用说Worker了。
其三可能你不相信，大多数业务场景下用不上。
现代浏览器的性能已经非常的好了，即使是个单线程，只要你不往死里折腾，足够大多数业务场景使用了，而且渲染帧率还非常的高。
我到目前为止只有两个需求需要用到Worker，一是大文件解析与上传，二是网站运行情况监控（包括日志处理）。

■网友
一般的网页，单线程就够了，追求性能同时会带来维护通信成本的问题，所以这是个权衡

■网友
因为密集计算在前端使用率没那么高吧。
worker和node的child_process.folk类似，都是双向postMessage和onMessage互相通讯，只能传递序列化数据，不支持DOM访问。所以利用worker多线程加载js库是别想了。
兼容性webpack支持自动fallbck成inline倒不是太大问题。
而且本身worker的解析建立也是额外开销，worker内的js运行速度也有损失，如果不是需要并行，多次重复调用，对常规场景不会有性能提升。
能用到就是长时间避免密集计算卡死UI，比如上千长度的数组diff等，但是这种需求在前端应该不多。
此外，多线程带来的额外代码不少，全部函数都要改成异步，你要考虑worker崩溃时候的重启，你要考虑同时多次请求的隔绝问题得设计一个类似jsbridge的封装，还是挺烦人的


■网友
因为场景太少了，我能想到只有两个场景
可视化（需要大量计算）小程序（需要隔离web，屏蔽dom）

■网友
那要看页面卡死的原因是什么了。频繁操作dom导致的webworker也无能为力。如果是大量的计算导致页面等待，webworker是很划算的。但这种明显会导致页面卡顿的计算，在业务开发上，前端很少见，所以用的就很少了。

■网友
我做数据可视化的时候有用，
使用后整体耗时从5~6秒降低到了1秒，耗时降低了500％。
启动webworker本身是要耗时间的，经过长期测试大约为14ms。如果一段代码片段耗时没超过20ms就不要用了。
了解一下时间切片、worker中创建worker
另外做一些本地缓存、indexedDB等也可以极大提高速度。
说webworker鸡肋的，其实把计算消耗放到客户端来，尽可能压榨用户的设备性能，不仅能给自己带来好处，还能推动硬件产业进步，这不是好事嘛

■网友
这功能主要是用来做web挖矿的

■网友
火狐的 pdf.js 在渲染的时候就有用到 web worker。

■网友
前段就不适合大量计算，有计算的会抛给后端去做…
所以这东西是个鸡肋

■网友
自己亲手去写一个 demo 对比下就知道了。
以我以前的尝试，把一段计算 md5 值的逻辑挪到 worker 里，结果发现耗时并没有下降反而还略增了，这里头的原因应该是 worker 本身的创建也是有开销的，如果只是一次性的调用，性能上的收益相比开销未必划算，而且还会带来代码体积和逻辑写法的成本。
以上，如有不对请指正。


    推荐阅读


    上一篇：想从牙刷产品入手！有想法，但没团队，天时地利人和不具备。导师们指导下我

    下一篇： 「养花」家里养花就养它，养护简单不操心，天天都能赏花，家里养出小花园