大家都知道 HTML 5 新增了很多 API,其中就包括 Web Worker,在普通的 js 文件上使用 ES5 编写相关代码应该是完全没有问题了,只需要在支持 H5 的浏览器上就能跑起来。
那如果我们需要在 ES6+Webpack 的组合环境下使用 Web Worker呢?其实也很方便,只需要注意一下个别点,接下来记录一下我踩过的坑。
至于 Web Worker 的基础知识和基本 api 我就放到最后面当给还不了解或者没有系统使用过的读者们去简单阅读一下。
1. 快速创建工程环境
假设你已经有一份 ES6+Webpack 的代码工程环境,而且是可以顺利跑起来的;如果没有,可以 clone 我的 github 仓库: github.com/irm-github/…
2. 安装及使用 worker-loader
2.1 安装依赖:
$ npm install -D worker-loader
# 或
$ yarn add worker-loader --dev
2.2 代码中直接使用 worker-loader
// main.js
var MyWorker = require("worker-loader!./file.js");
// var MyWorker = require("worker-loader?inline=true&fallback=false!./file.js");
var worker = new MyWorker();
worker.postMessage({a: 1});
worker.onmessage = function(event) { /* 操作 */ };
worker.addEventListener("message", function(event) { /* 操作 */ });
优点:写 worker 逻辑的脚本文件可以任意命名,只要传进
worker-loader
中处理即可;
缺点:每引入一次 worker 逻辑的脚本文件,就需要写一次如上所示的代码,需要多写 N(N>=1) 次的 "worker-loader!"
2.3 在 webpack 的配置文件中引入
worker-loader
{
module: {
rules: [
{
// 匹配 *.worker.js
test: /\.worker\.js$/,
use: {
loader: 'worker-loader',
options: {
name: '[name]:[hash:8].js',
// inline: true,
// fallback: false
// publicPath: '/scripts/workers/'
}
}
}
]
}
}
其中配置,可以设置
inline
属性为
true
将 worker 作为 blob 进行内联;
要注意,内联模式将额外为浏览器创建
chunk
,即使对于不支持内联 worker 的浏览器也是如此;若这种浏览器想要禁用这种行为,只需要将
fallback
参数设置为
false
即可。
3. 同源策略
Web Worker 严格遵守同源策略,如果 webpack 的静态资源与应用代码不是同源的,那么很有可能就被浏览器给墙掉了,而且这种场景也经常发生。对于 Web Worker 遇到这种情况,有两种解决方案。
3.1 第一种
通过设置
worker-loader
的选项参数
inline
把 worker 内联成 blob 数据格式,而不再是通过下载脚本文件的方式来使用 worker:
App.js
import Worker from './file.worker.js';
webpack.config.js
{
loader: 'worker-loader'
options: { inline: true }
}
3.2 第二种
通过设置
worker-loader
的选项参数
publicPath
来重写掉 worker 脚本的下载 url,当然脚本也要存放到同样的位置:
App.js
// This will cause the worker to be downloaded from `/workers/file.worker.js`
import Worker from './file.worker.js';
webpack.config.js
{
loader: 'worker-loader'
options: { publicPath: '/workers/' }
}
4. devServer 模式下报错 "window is not defined"
若使用了
webpack-dev-server
启动了本地调试服务器,则有可能会在控制台报错: "Uncaught ReferenceError: window is not defined"
反正我是遇到了,找了很久未果,当时还是洗了把脸冷静下来排查问题,尝试着先后在
worker-loader
、
webpack-dev-server
和
webpack
的 github 仓库的 issues 里面去找,最后果然在
webpack
的 github 仓库里找到了码友的提问,官方给出了答案:
只需要在 webpack 的配置文件下的 output 下,加一个属性对:
globalObject: 'this'
output: {
path: DIST_PATH,
publicPath: '/dist/',
filename: '[name].bundle.[hash:8].js',
chunkFilename: "[name].chunk.[chunkhash:8].js",
globalObject: 'this',
},
5. Web Worker 出现的背景
JavaScript 引擎是单线程运行的,JavaScript 中耗时的 I/O 操作都被处理为异步操作,它们包括键盘、鼠标 I/O 输入输出事件、窗口大小的
resize
事件、定时器(
setTimeout
、
setInterval
)事件、Ajax 请求网络 I/O 回调等。当这些异步任务发生的时候,它们将会被放入浏览器的事件任务队列中去,等到 JavaScript 运行时执行线程空闲时候才会按照队列先进先出的原则被一一执行,但终究还是单线程。
平时看似够用的异步编程(
promise
、
async/await
),在遇到很复杂的运算,比如说图像的识别优化或转换、H5游戏引擎的实现,加解密算法操作等等,它们的不足就将逐渐体现出来。长时间运行的 js 进程会导致浏览器冻结用户界面,降低用户体验。那有没有什么办法可以将复杂的计算从业务逻辑代码抽离出来,让计算运行的同时不阻塞用户操作界面获得反馈呢?
HTML5 标准通过了 Web Worker 的规范,该规范定义了一套 api,它允许一段 js 程序运行在主线程之外的另一个线程中。工作线程允许开发人员编写能够长时间运行而不被用户所中断的后台程序, 去执行事务或者逻辑,并同时保证页面对用户的及时响应,可以将一些大量计算的代码交给web worker运行而不冻结用户界面。
5. Web Worker 的类型
之前一直认为不就那一种类型吗,哪里还会有多类型的 Worker。答案是有的,其可分为两种类型:
- 专用 Worker, Dedicated Web Worker
- 共享 Worker, Shared Web Worker
「专用 Worker」只能被创建它的页面访问,而「共享 Worker」可以在浏览器的多个标签中打开的同一个页面间共享。
在 js 代码中,
Woker
类代表
Dedicated Worker
;
Shared Worker
类代表
Shared Web Worker
。
下面的一些示例代码我就直接用 ES5 去写了,上面教了大家怎么使用在 ES6+Webpack 的环境下,迁移这种工作大家就当练习,多动动手。
6. 如何创建 Worker
很简单
// 应用文件 app.js
var worker = new Worker('./my.worker.js'); // 传入 worker 脚本文件的路径即可
7. 如何与 worker 通信
就通过两个方法即可完成:
应用文件 app.js
// 创建 worker 实例
var worker = new Worker('./my.worker.js'); // 传入 worker 脚本文件的路径即可
// 监听消息
worker.onmessage = function(evt){
// 主线程收到工作线程的消息
};
// 主线程向工作线程发送消息
worker.postMessage({
value: '主线程向工作线程发送消息'
});
worker 文件 my.worker.js
// 监听消息
this.onmessage = function(evt){
// 工作线程收到主线程的消息
};
this.postMessage({
value: '工作线程向主线程发送消息'
});
8. Worker 的全局作用域
使用 Web Worker 最重要的一点是要知道,它所执行的 js 代码完全在另一作用域中,与当前主线程的代码不共享作用域。在 Web Worker 中,同样有一个全局对象和其他对象以及方法,但其代码无法访问 DOM,也不能影响页面的外观。
Web Worker 中的全局对象是 worker 对象本身,也即
this
和
self
引用的都是 worker 对象,说白了,就像上一段在
my.worker.js
的代码,
this
完全可以换成
self
,甚至可以省略。