总体来说webworker解决了阻塞主线程问题，但是还没解决高性能计算的问题
WebWorker整体介绍
https://developer.mozilla.org/zh-CN/docs/Web/API/Web_Workers_API/Using_web_workers
这里的主要问题都很清晰了，个人认为主要的有以下几点：
1、大部分情况都在使用专用worker
2、worker脚本的源如果是一个全局性的唯一的标识符（例如，它的URL指定了数据模式或者blob），worker则会继承创建它的document或者worker的CSP（Content security policy内容安全策略）。
3、worker中数据的接收与发送（除了ArrayBuffer其他都是拷贝传递）
4、importScripts在实际项目中不实用，建议使用webpack结合webworkify-webpack
这篇文章我们重点看第三点与第四点
worker中数据的接收与发送
object的拷贝传递：
传递json字符串
传递的时间在2ms，但是如果算上stringify和parse的过程，总体时间反而更加长
传递Arraybuffer
传递一个32m的数据
根据实验发现传递时间很大
但如果换成转让控制权的方式话：
从子线程传递到父线程只要8ms，不过这个buffer的控制权已经交给子线程了，后续子线程无法再使用这个buffer
同时发现同样的数据无论是不传递控制权还是传递控制权，从主线程传递到子线程中消耗的时间都大幅度减少。转让控制权方式主线程传递到子线程只需要0.08ms
WebWorker实际使用方式
实际开发中我们不会吧所有的代码都放在一个文件中让子线程加载，肯定会选择模块化开发。官方提供的方式是使用importScripts，但是这个在实际开发中很不实用，importScripts的加载方式是阻塞式的，所以我们最好用打包工具将所有worker中需要的文件打包成一个文件。这里我推荐webworkify-webpack，这是webpack的一个插件。使用方式如下：
将worker中的任务以路由的方式来注册：
路由文件如下：
对于webworkify-webpack的原理其实并没有使用importScripts而是使用另一种方式来创建worker，将js代码stringify后创建Blob对象，然后又createObjectURL创建对象url来实例化worker。类似如下过程：
注：本文内容来自互联网，旨在为开发者提供分享、交流的平台。如有涉及文章版权等事宜，请你联系站长进行处理。