背景
近期在做用户回放系统需求，其中有一环是从 indexedDB 中读取日志并做上报。然而，由于日志的数据量太大，计算处理 indexedDB 的数据比较耗时，容易造成阻塞，导致用户浏览器卡顿。为了解决这个问题，我们想了几种优化手段：
使用 Web Worker 读取数据并处理。
分片读取、定时轮询、异常重试。
对数据使用 gzip 压缩。
其中，由于没有实践的经验，使用 Web Worker 的时候也踩了一些坑。在这里对 Web Worker 的使用做一个小结。
基本介绍
我们都知道，JavaScript 是单线程的，也就是一次只能做一件事。所以，当一些低优先级但是耗时的任务 (日志处理) 正在执行时，一些高优先级的任务 (业务相关) 就只能等着，可能导致 UI 交互不流畅，浏览器出现卡顿的情况，对于 CPU 来说，JS 单线程的带来的不便就更加明显了。
而 Web Worker 的出现，为 JavaScript 创造了多线程的环境。(ps：这里并不是说 JS 本身支持了多线程的能力，只是浏览器作为宿主环境提供了 JS 一个多线程运行的环境)
W3C 定义：A web worker is a JavaScript that runs in the background, independently of other scripts, without affecting the performance of the page. You can continue to do whatever you want: clicking, selecting things, etc., while the web worker runs in the background.
在项目中，我们可以将一些复杂的计算任务分配给 Worker 运行，让主线程专注于 UI 交互相关的任务，Worker 线程和主线程互不干扰，这样用户使用起来就会比较流畅，不会有卡顿之感。
使用方法
由于主线程和 Worker 线程不在同一个上下文中，他们使用数据通信的方式交互，通过 postMessage 发送消息、监听 message 事件接收消息（可以通过 addEventListener 或 onmessage 这两个 API）。
主线程
// 创建一个 Worker 线程，用于上报数据，传入这个 Worker 对应的脚本文件
const worker = new Worker('reportWorker.ts');
// 主线程向 Worker 线程发送消息，让 Worker 线程从 indexedDB 读取 count 条数据
worker.postMessage({ type: WorkerReportType.ReadEventTblStart, data: count });
// 主线程监听来自 Worker 的消息
worker.onmessage = (event: MessageEvent) => {
const { type, data } = event.data;
// 对不同类型的消息做不同处理
switch (type) {
case WorkerReportType.ReadEventTblFinish:
console.log('从worker中接收的数据', data);
// ...
break;
case ...
}
}
Worker 线程
// Worker 监听来自主线程的消息
self.onmessage = (event: MessageEvent) => {
const { type, data } = event.data;
// 对不同类型的消息做不同处理
switch (type) {
case WorkerReportType.ReadEventTblStart:
// 读取、处理日志数据
readIndexedDB();
break;
case ...:
}
}
// Worker 向主线程发送消息
self.postMessage({ type: WorkerReportType.ReadEventTblFinish, data: result });
除了发送和接收消息这两种最常用的 API，还可以监听 Worker 线程的错误：
worker.onerror((event: MessageEvent) => {
console.log('worker error');
})
在 Worker 使用完毕时，应及时关闭：
// 主线程
worker.terminate();
// worker线程
self.close();
数据通信
虽然在 Worker 线程进行一些复杂的运算不会对主线程有影响，但如果主线程和 Worker 之间通信时，传输的数据量太大（比如 5-10MB，甚至更大），会不会对主线程的性能有影响呢？
拷贝传输
首先，我们了解一下主线程和 Worker 之间的默认数据传输方式，当像刚刚提到的基本用法那样使用 postMessage 时，数据的通信是一种拷贝的关系，浏览器内部会先将内容序列化，发送给接收方，接收方再将其还原。因此，当我们传输一个 100MB 的数据时，会由于拷贝而增加一份内存消耗，复制的时间也会随数据量增加而增加。通过这样一段代码，我们模拟线性增大传输数据量：
// Worker 中发送数据
for (let i = 0; i <= 50; i += 5) {
const mockData = new Uint8Array(1024 * 1024 * i);
const start = Date.now();
tasks.postMessage({ type: ReadEventTblFinish, data: { mockData, size: i, start } });
}
// 主线程接收数据
...
const now = Date.now();
const { size, start } = data;
const time = now - start;
console.log(`post message end, 大小：${size}MB, 耗时 ${time}ms`);
Chrome 浏览器输出的结果如下：
可以看到，传输二进制数据时，传输时间基本是随着传输数据大小线性增加的。
使用 Transferable 对象传输
为了解决拷贝传输的问题，postMessage 这个还有第二个参数：transferableList，即一个可转移对象的列表。JavaScript 与 Worker 通信的时候，直接将对象转移给接收方，一旦转移，发送方就再也无法使用这些二进制数据。
我们只需要在 postMessage 的时候指定一下可转移对象：
tasks.postMessage({ type: ReadEventTblFinish, data: { mockData, size: i, start } }, [mockData.buffer]);
Chrome 浏览器输出的结果如下：
可以看到通过这种方法，数据传输的耗时大大减少了。再打印一下 postMessage 之后的 mockData：
数据为空，说明控制权确实被转移了，Worker 里再也无法使用这份数据了。
然而，使用 transferableList 有两个需要注意的地方：
目前，实现了 Transferable 接口的只有：ArrayBuffer、MessagePort、 ImageBitmap。也就是说，如果我们传输的是 JS 对象，需先将其转换为 ArrayBuffer，否则会报错。而如果对象本身很庞大，数据格式转换的时间也会随之增大，是否有必要为了减少 Worker 通信时间而增加数据格式转换时间还需要权衡。
当我们使用 TransferableList 传输对象时，浏览器会帮我们完成 Transferable 对象到对应的数据成员（postMessage 的第一个参数中）之间的映射。因此，如果我们的数据集中于少数变量中，那么可以放心地使用 Transferable 来传输。但如果 transferable 数据分散于成百上千个元素中，这个解析映射的时间就会比较久，使用 Transferable 对象传输反而会有比较明显的性能问题。
Shared Array Buffers
默认情况下，Worker 之间、主线程与 Worker 都不会共享内存，但使用 SharedArrayBuffer，两个线程都可以在同一块内存中读写数据。共享内存，也就意味着没有传输延迟和开销。
然而，这也会带来冲突和竞争的问题，而且当前浏览器对这个特性的支持情况也比较差，因此建议不要使用这种方式。
使用 Promise 封装 Worker 通信
目前，使用 postMessage 和 onmessage 这两个 API，我们确实能实现通信的目的。但看看代码结构：
主线程向 Worker 发送消息：
主线程接收 Worker 的消息：
这样的代码存在几个痛点：
消息一旦发送，我们没有办法追踪，只能通过监听 Worker 对应的 message。
主线程和 Worker 每发送一种消息，就要新增一个 type 类型，且两者没有对应关系。
事件处理的入口和结果是分离的，不利于代码的阅读。比如说：A 同学要理解从 indexedDB 读取数据，处理后发送回主线程这个流程，他需要经历以下几个步骤：
首先找到主线程的入口，主线程 postMessage 发送了 ReadEventTblStart 的信号；
到 Worker 对应的代码中找到 onmessage 时对应的处理方法；
Worker 处理完后给主线程发了一个 ReadEventTblFinish 的信号；
回到主线程对应的代码，找到 onmessage 时对应事件的处理；
结果就是在不同的文件之间反复横跳。为了使 Worker 更加易用，结合异步响应的特点，我们可以基于 Promise 封装一下 Worker.
首先，用真正的 Worker 初始化一个 PromiseWorker 类：
class PromiseWorker {
private worker: Worker;
constructor(worker: Worker) {
this.worker = worker;
}
}
由于我们只能通过 postMessage 和 onmessage 发送和接收信息，所以我们需要一个 map 将发送消息和收到消息后回调映射起来：
// 这里我用number类型的type变量作为key值，实际上这个key值只要唯一即可
private handlerMap: Map<number, Function> = newMap();
封装 postMessage，每次发送消息时，在 map 中添加一条映射，以供返回时转换 Promise 的状态：
postMessage(message: WorkerMessage) {
const { type } = message;
returnnewPromise((resolve) => {
this.worker.postMessage(message);
this.handlerMap.set(type, resolve);
});
}
接收消息时，根据和发送消息对应的 type 值，取出 resolve 函数：
this.worker.onmessage = (event: MessageEvent) => {
const { type, data } = event.data;
const resolve = this.handlerMap.get(type);
if (!resolve) {
return;
}
resolve(data);
this.handlerMap.delete(type);
};
一个完整的 PromiseWorker 类：
exportdefaultclass PromiseWorker {
private handlerMap: Map<number, Function> = newMap();
private worker: Worker;
constructor(worker: Worker) {
this.worker = worker;
this.worker.onmessage = (event: MessageEvent) => {
const { type, data } = event.data;
const resolve = this.handlerMap.get(type);
if (!resolve) {
return;
}
resolve(data);
this.handlerMap.delete(type);
};
}
postMessage(message: WorkerMessage) {
const { type } = message;
returnnewPromise((resolve) => {
this.worker.postMessage(message);
this.handlerMap.set(type, resolve);
});
}
}
使用方式：
/** 主线程 */
// 实例化一个PromiseWorker
const reportWorker = new PromiseWorker(new ReportWorker());
// 调用封装好的postMessage
reportWorker.postMessage({ type: WorkerReportType.ReadEventTbl, data: count }).then((data) => {
console.log('read event table finish', data);
});
/** worker线程 */
// 收到消息，计算处理完毕后，发送同一个type即可
self.onmessage = async (event: MessageEvent) => {
const { type, data } = event.data;
// 对不同类型的消息做不同处理
switch (type) {
case WorkerReportType.ReadEventTbl:
// 读取、处理日志数据
const result = await ...
// 回复（发送同样的type）
self.postMessage({ type, data: result });
break;
case ...
}
}
这样简单的实现一个 Promise 化的 Worker，在主线程上，我们就能专注于业务实现，而不必关心发送消息和接收消息的对应关系。
Web Worker 的局限性
DOM 操作限制 Worker 线程和主线程的 window 是不在一个全局上下文中运行的，因此我们无法在 Worker 中访问到 document、window、parent 这些对象，也不能访问 DOM 元素。但是，可以获取 navigator、location 对象。这跟 JavaScript 被设计成单线程也是有关系的，试想多个线程同时对同一个 DOM 操作，就会出现冲突。
数据通信限制 Worker 和主线程的通信可以传递对象和数组，他们是通过拷贝的形式传递的，这意味着，我们不能传递不能被序列化的数据，比如说函数，否则会报错。
无法访问 localStorage。
同源限制 分配给 Worker 线程运行的脚本文件，需要和主线程的脚本文件同源。
脚本限制 Worker 线程不能执行 alert、confirm，但是可以获取 setTimeout、XMLHttpRequest 等浏览器 API。
文件限制 为了安全，Worker 线程无法读取本地文件，即不能打开本机的文件系统（ file:// ），它所加载的脚本必须来自网络，且需要与主线程的脚本同源。
