Web Worker 性能优化初体验

背景

近期在做用户回放系统需求，其中有一环是从 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.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 有两个需要注意的地方：

1. 目前，实现了 Transferable 接口的只有：ArrayBuffer、MessagePort、 ImageBitmap。也就是说，如果我们传输的是 JS 对象，需先将其转换为 ArrayBuffer，否则会报错。而如果对象本身很庞大，数据格式转换的时间也会随之增大，是否有必要为了减少 Worker 通信时间而增加数据格式转换时间还需要权衡。
2. 当我们使用 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 读取数据，处理后发送回主线程这个流程，他需要经历以下几个步骤：

1. 首先找到主线程的入口，主线程 postMessage 发送了 ReadEventTblStart 的信号；
2. 到 Worker 对应的代码中找到 onmessage 时对应的处理方法；
3. Worker 处理完后给主线程发了一个 ReadEventTblFinish 的信号；
4. 回到主线程对应的代码，找到 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 的局限性

1. DOM 操作限制 Worker 线程和主线程的 window 是不在一个全局上下文中运行的，因此我们无法在 Worker 中访问到 document、window、parent 这些对象，也不能访问 DOM 元素。但是，可以获取 navigator、location 对象。这跟 JavaScript 被设计成单线程也是有关系的，试想多个线程同时对同一个 DOM 操作，就会出现冲突。
2. 数据通信限制 Worker 和主线程的通信可以传递对象和数组，他们是通过拷贝的形式传递的，这意味着，我们不能传递不能被序列化的数据，比如说函数，否则会报错。
3. 无法访问 localStorage。
4. 同源限制 分配给 Worker 线程运行的脚本文件，需要和主线程的脚本文件同源。
5. 脚本限制 Worker 线程不能执行 alert、confirm，但是可以获取 setTimeout、XMLHttpRequest 等浏览器 API。
6. 文件限制 为了安全，Worker 线程无法读取本地文件，即不能打开本机的文件系统（ file:// ），它所加载的脚本必须来自网络，且需要与主线程的脚本同源。

本文由哈喽比特于3年以前收录，如有侵权请联系我们。
文章来源：https://mp.weixin.qq.com/s/IJHI9JB3nMQPi46b6yGVWw