丁鹿学堂：前端进阶分享之webworker知识总结

web Worker

我们知道js是单线程的。所有任务只会在一个线程上完成，一次只能做一件事件。前面的任务没有完成，后面的任务只能够等待。
但是，随着计算机计算能力的增强，尤其是多核心的CPU的普及，单线程的弊端，就是没有办法充分发挥计算机的能力。
webworker 的出现，就是给js创建多线程的环境。这样，一些高延时的任务，就可以交给webworker去执行，主线程负责UI交互，这样主线程就不会被阻塞。

worker的兼容性

worker在2009年就提出了草案。同时。在2009年的时候，火狐浏览器第一个支持了webworker，在2012年的ie10也实现了webworker，2012年，所有的主流浏览器都已经支持了webworker。

worker的应用场景

worker可以减少页面卡顿。通常情况下，js执行播放动画的时间如果大于16ms，用户操作响应大于100ms，页面打开到呈现大于1000ms的话，用户就会感到卡顿。这是chrome团队提出的。
我们可以把js同步任务拆分为小于16ms的子任务，进行异步化执行。
webworker将可能阻塞页面渲染的任务，都迁移到worker线程中去。这样就可以减少主线程的负担。这样worker线程可以跟主线程并行去执行，从而缩短页面渲染时间，减少卡顿。

worker的API

worker.js里面是我们让worker线程去执行的一些操作。
postMessage方法是worker提供的，可以向wokker去推送一些消息。
在workder线程里，就可以通过onmessage去监听这个消息。
同时，worker线程也可以向主线程去推送一些消息。
同样，主线程上也可以通过onmessage去监听worker线程上的一些消息。

const worker = new Worker('./worker.js')
worker.postMessage('111')
worker.onmessage = (e) =>{
  console.log(e.data)
}

my.onmessage = (e)=>{
  console.log(e.data)
  postMessage('222')
}
1
2
3
4
5
6
7
8
9
10

worker的执行环境和主线程的对比

相同点

worker线程在创建的时候，也会独立产生一个js的运行环境。我们需要注意的几点，一个是worker的js环境也支持xmlHttpRequest，可以独立发送网络请求。也支持setTimeout和setInterval，可以实现定时器。也支持网络的I/O，也支持文件I/O

不同点

worker线程没有DOMAPI，无法操作DOM
worker无法访问页面上的全局变量和函数
worker也不能使用BOM相关的api，比如alert
worker可以自行销毁，也受到主线程的控制，可以被主线程销毁。