总体来说webworker解决了阻塞主线程问题，但是还没解决高性能计算的问题

WebWorker整体介绍

这里的主要问题都很清晰了，个人认为主要的有以下几点：

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。类似如下过程：