使用 Web Worker 在浏览器的主线程之外运行 JavaScript

非主线程架构可以显著提高应用的可靠性和用户体验。

Surma

在过去 20 年中，Web 从仅包含少量样式和图片的静态文档，演变为复杂的动态应用。不过，有一件事基本没有变化：每个浏览器标签页只有一个线程（存在一些例外情况）来完成呈现网站和运行 JavaScript 的工作。

因此，主线程变得非常繁忙。随着 Web 应用变得越来越复杂，主线程会成为性能的重要瓶颈。更糟糕的是，在主线程上针对给定用户运行代码所需的时间几乎完全不可预测，因为设备功能对性能有很大影响。随着用户使用越来越多样化的设备（从功能极其受限的功能手机到高性能、高刷新率的旗舰设备）访问网络，这种不可预测性只会越来越大。

如果我们希望复杂的 Web 应用能够可靠地满足性能准则（例如基于人类感知和心理学的实证数据的核心 Web 指标），就需要找到在主线程之外 (OMT) 执行代码的方法。

注意 ：如需详细了解 OMT 架构的用例，请观看下面的 2019 年 CDS 演讲。

为什么要使用 Web Worker？

默认情况下，JavaScript 是一种单线程语言，可在主线程上运行任务。不过，Web Worker 允许开发者创建单独的线程来处理主线程之外的工作，从而提供了一种从主线程逃逸的方法。虽然 Web Worker 的范围有限，并且不提供对 DOM 的直接访问权限，但如果需要执行大量工作，而这些工作会使主线程过载，Web Worker 会非常有用。

从 Core Web Vitals 的角度来看，在主线程之外运行工作可能会有益。具体而言，将工作从主线程分流到 Web Worker 可以减少对主线程的争用，从而改进网页的 Interaction to Next Paint (INP) 响应能力指标。当主线程要处理的工作量较少时，它可以更快地响应用户互动。

减少主线程工作（尤其是在启动期间）还可以减少长任务，从而对 Largest Contentful Paint (LCP) 有潜在益处。渲染 LCP 元素需要主线程时间，无论是渲染文本还是图片（这两者都是常见的 LCP 元素），都需要主线程时间。通过总体减少主线程工作，您可以确保网页的 LCP 元素不太可能被 Web Worker 可以处理的高成本工作所阻塞。

使用 Web Worker 进行线程处理

其他平台通常支持并行工作，即允许您为线程提供一个函数，该函数会与程序的其余部分并行运行。您可以从两个线程访问相同的变量，并且可以使用互斥量和信号量同步对这些共享资源的访问，以防止出现竞争条件。

在 JavaScript 中，我们可以通过 Web Worker 获得大致类似的功能。Web Worker 自 2007 年起就已存在，自 2012 年起，所有主要浏览器都支持 Web Worker。Web Worker 与主线程并行运行，但与 OS 线程不同，它们无法共享变量。

注意： 请勿将 Web Worker 与服务工件或工作容器混淆。虽然名称相似，但功能和用途不同。

如需创建 Web 工作器，请将文件传递给 worker 构造函数，该构造函数会在单独的线程中开始运行该文件：

const worker = new Worker("./worker.js");

使用 postMessage API 发送消息，与 Web Worker 进行通信。在 postMessage 调用中将消息值作为参数传递，然后向 worker 添加消息事件监听器：

main.js

const worker = new Worker('./worker.js');
worker.postMessage([40, 2]);

worker.js

addEventListener('message', event => {
  const [a, b] = event.data;

  // Do stuff with the message
  // ...
});

如需将消息发送回主线程，请在 Web Worker 中使用相同的 postMessage API，并在主线程上设置事件监听器：

main.js

const worker = new Worker('./worker.js');

worker.postMessage([40, 2]);
worker.addEventListener('message', event => {
  console.log(event.data);
});

worker.js

addEventListener('message', event => {
  const [a, b] = event.data;

  // Do stuff with the message
  postMessage(a + b);
});

诚然，这种方法有些局限性。过去，Web Worker 主要用于将单个繁重工作从主线程移出。尝试使用单个 Web Worker 处理多个操作很快就会变得非常麻烦：您不仅要对参数进行编码，还要对消息中的操作进行编码，并且必须进行簿记以将响应与请求相匹配。这种复杂性可能是 Web Worker 未得到更广泛采用的原因。

不过，如果我们能够消除主线程和 Web Worker 之间通信的一些难点，这种模型就非常适合许多用例。幸运的是，有一个库正好可以做到这一点！

Comlink：让 Web Worker 的工作量减少

Comlink 是一个库，旨在让您无需考虑 postMessage 的细节即可使用 Web Worker。借助 Comlink，您可以在 Web Worker 和主线程之间共享变量，这与支持线程的其他编程语言非常相似。

您可以通过在 Web Worker 中导入 Comlink 并定义一组要公开给主线程的函数来设置 Comlink。然后，您可以在主线程上导入 Comlink，封装 worker，并获取对公开函数的访问权限：

worker.js

import {expose} from 'comlink';

const api = {
  someMethod() {
    // ...
  }
}

expose(api);

main.js

import {wrap} from 'comlink';

const worker = new Worker('./worker.js');
const api = wrap(worker);

主线程上的 api 变量的行为与 Web Worker 中的变量相同，只不过每个函数返回的都是针对值（而非值本身）的 promise。

您应该将什么代码转移到 Web Worker？

Web 工作器无法访问 DOM 和许多 API（例如 WebUSB、WebRTC 或 Web Audio），因此您无法将依赖于此类访问权限的应用部分放入工作器中。不过，将每一段小代码移至工作器，都可以为主线程上必须执行的操作（例如更新界面）留出更多空间。

注意 ：在其他语言中，限制界面对主线程的访问实际上是常见的做法。事实上，iOS 和 Android 都将主线程称为界面线程。

Web 开发者面临的一个问题是，大多数 Web 应用都依赖于 Vue 或 React 等界面框架来协调应用中的所有内容；所有内容都是框架的组件，因此与 DOM 有内在关联。这似乎使得迁移到 OMT 架构变得困难。

不过，如果我们改用将界面问题与其他问题（例如状态管理）分离开的模型，即使在基于框架的应用中，Web Worker 也非常有用。PROXX 正是采用了这种方法。

PROXX：OMT 案例研究

Google Chrome 团队开发了 PROXX，这是一个符合渐进式 Web 应用要求（包括离线运行和提供富有吸引力的用户体验）的扫雷游戏克隆。遗憾的是，游戏的早期版本在功能机等受限设备上运行效果不佳，这让团队意识到主线程是瓶颈。

该团队决定使用 Web Worker 将游戏的视觉状态与其逻辑分离开来：

• 主线程处理动画和转场效果的渲染。
• Web Worker 负责处理纯计算的游戏逻辑。

注意 ：此方法类似于 Redux Flux 模式，因此许多 Flux 应用迁移到 OMT 架构所需的工作量可能低于预期。如需了解详情，请查看这篇有关将 OMT 应用于 Redux 应用的博文。

OMT 对 PROXX 的功能手机性能产生了有趣的影响。在非 OMT 版本中，界面会在用户与其互动后冻结 6 秒。没有任何反馈，用户必须等待完整的 6 秒钟才能执行其他操作。

PROXX 的非 OMT 版本中的界面响应时间。

不过，在 OMT 版本中，游戏需要 十二 秒才能完成界面更新。虽然这似乎会降低性能，但实际上会增加向用户提供的反馈。之所以会出现速度变慢的问题，是因为应用发送的帧数比非 OMT 版本多，后者根本不发送任何帧。因此，用户知道正在发生某些事情，并且可以在界面更新时继续玩游戏，从而获得更出色的游戏体验。

PROXX 的 OMT 版本中的界面响应时间。

这是有意为之的权衡：我们会为受限设备的用户提供感觉更好的体验，同时不会惩罚高端设备的用户。

OMT 架构的影响

如 PROXX 示例所示，OMT 可让您的应用在更多类型的设备上可靠运行，但不会加快应用的运行速度：

• 您只是从主线程移动工作，而不会减少工作。
• Web Worker 和主线程之间的额外通信开销有时可能会导致速度略微变慢。

权衡利弊

由于主线程可在 JavaScript 运行时自由处理用户互动（如滚动），因此丢帧会更少，尽管总等待时间可能会略长一些。让用户等待一会儿可比丢帧更可取，因为丢帧的误差范围较小：丢帧会在毫秒内发生，而用户有几百毫秒才会感知到等待时间。

由于跨设备性能具有不可预测性，OMT 架构的目标实际上是降低风险，使应用在面临高度变化的运行时条件时更加稳健，而不是并行化的性能优势。弹性的提升和用户体验的改进，对于速度方面的任何小小的权衡都值得一读。

注意 ：开发者有时会担心跨主线程和 Web Worker 复制复杂对象的成本。演讲中会详细介绍，但一般来说，如果对象的字符串化 JSON 表示形式小于 10 KB，则不应超出性能预算。如果您需要复制更大的对象，不妨考虑使用 ArrayBuffer 或 WebAssembly。如需详细了解此问题，请参阅这篇介绍 postMessage 性能的博文。

关于工具的说明

Web Worker 目前尚未成为主流，因此大多数模块工具（例如 webpack 和 Rollup）都不支持开箱即用。（不过 Parcel 可以！）幸运的是，有插件可让 Web Worker 与 webpack 和 Rollup 协同工作：

• 适用于 webpack 的 worker-plugin
• 用于 Rollup 的 rollup-plugin-off-main-thread

总结

为了确保我们的应用尽可能可靠且易于访问，尤其是在日益全球化的市场中，我们需要支持受限设备，因为全球大多数用户都是通过这些设备访问网络。OMT 提供了一种有望在这些设备上提升性能的方法，而不会对高端设备的用户产生不利影响。

此外，OMT 还有其他好处：

• 它会将 JavaScript 执行开销转移到单独的线程。
• 它会移除解析开销，这意味着界面可能会更快启动。这可能会缩短首次内容绘制或甚至互动所需时间，进而提高 Lighthouse 评分。

Web Worker 并不可怕。Comlink 等工具可代替人工执行工作，是各种 Web 应用的理想之选。