与 Service Worker 的双向通信

Andrew Guan

Demián Renzulli

在某些情况下，Web 应用可能需要在网页和服务工件之间建立双向通信通道。

例如：在播客 PWA 中，您可以构建一项功能，让用户下载分集以供离线观看，并允许服务工作器定期向页面告知进度，以便主线程可以更新界面。

在本指南中，我们将通过探索不同的 API、Workbox 库以及一些高级用例，探讨在 Window 和 service worker 上下文之间实现双向通信的不同方法。

注意 ：请参阅工作器概览，大致了解何时应使用 Web 工作器，何时应使用服务工件；如需了解其他常见用例，请参阅与工作器通信系列的其余文章。

使用 Workbox

workbox-window 是 Workbox 库的一组模块，旨在在窗口上下文中运行。Workbox 类提供了 messageSW() 方法，用于向实例的已注册的 ServiceWorker 发送消息并等待响应。

以下页面代码会创建一个新的 Workbox 实例，并向 Service Worker 发送消息以获取其版本：

const wb = new Workbox('/sw.js');
wb.register();

const swVersion = await wb.messageSW({type: 'GET_VERSION'});
console.log('Service Worker version:', swVersion);

服务工件在另一端实现消息监听器，并响应已注册的服务工件：

const SW_VERSION = '1.0.0';

self.addEventListener('message', (event) => {
  if (event.data.type === 'GET_VERSION') {
    event.ports[0].postMessage(SW_VERSION);
  }
});

该库在底层使用了我们将在下一部分中介绍的浏览器 API：消息通道，但抽象了许多实现细节，使其更易于使用，同时利用了此 API 的广泛的浏览器支持。

使用浏览器 API

如果 Workbox 库无法满足您的需求，您可以使用多个较低级别的 API 在网页和服务工件之间实现“双向”通信。它们之间存在一些相似之处和差异：

相似之处：

• 在所有情况下，通信都是从一端通过 postMessage() 接口发起，并通过实现 message 处理脚本在另一端接收。
• 实际上，我们可以使用所有可用的 API 实现相同的用例，但在某些情况下，其中一些 API 可能会简化开发。

差异：

• 它们有不同的方法来识别通信的另一端：有些使用对其他上下文的显式引用，而其他则可以通过在每端实例化的代理对象进行隐式通信。
• 浏览器支持情况因平台而异。

Broadcast Channel API

浏览器支持

• 54
• 79
• 38
• 15.4

来源

Broadcast Channel API 允许浏览上下文之间通过 BroadcastChannel 对象进行基本通信。

如需实现此功能，首先，每个上下文都必须实例化具有相同 ID 的 BroadcastChannel 对象，并通过该对象发送和接收消息：

const broadcast = new BroadcastChannel('channel-123');

BroadcastChannel 对象公开了 postMessage() 接口，用于向任何监听上下文发送消息：

//send message
broadcast.postMessage({ type: 'MSG_ID', });

任何浏览器上下文都可以通过 BroadcastChannel 对象的 onmessage 方法监听消息：

//listen to messages
broadcast.onmessage = (event) => {
  if (event.data && event.data.type === 'MSG_ID') {
    //process message...
  }
};

如您所见，没有对特定上下文的显式引用，因此无需先获取对服务工件或任何特定客户端的引用。

缺点是，截至撰写本文时，Chrome、Firefox 和 Edge 支持该 API，但 Safari 等其他浏览器尚不支持。

Client API

浏览器支持

• 40
• 17
• 44
• 11.1

来源

借助 Client API，您可以获取对所有 WindowClient 对象的引用，这些对象代表服务工作器正在控制的活跃标签页。

由于该页面由单个 Service Worker 控制，因此它会直接通过 serviceWorker 接口监听并向活跃的 Service Worker 发送消息：

//send message
navigator.serviceWorker.controller.postMessage({
  type: 'MSG_ID',
});

//listen to messages
navigator.serviceWorker.onmessage = (event) => {
  if (event.data && event.data.type === 'MSG_ID') {
    //process response
  }
};

同样，Service Worker 通过实现 onmessage 监听器来监听消息：

//listen to messages
self.addEventListener('message', (event) => {
  if (event.data && event.data.type === 'MSG_ID') {
    //Process message
  }
});

为了与其任何客户端进行通信，服务工件会通过执行 Clients.matchAll() 和 Clients.get() 等方法来获取 WindowClient 对象数组。然后，它可以postMessage()其中任何一个：

//Obtain an array of Window client objects
self.clients.matchAll(options).then(function (clients) {
  if (clients && clients.length) {
    //Respond to last focused tab
    clients[0].postMessage({type: 'MSG_ID'});
  }
});

Client API 是一种很好的选择，可让您通过服务工作线程以相对简单的方式轻松与所有活跃标签页进行通信。所有主要浏览器都支持此 API，但其部分方法可能不可用，因此请务必先检查浏览器支持情况，然后再在您的网站中实现该 API。

注意 ：在本指南中，我们主要介绍了可靠性用例。此 API 的另一个有趣用途是通过服务工件在文档之间同步数据。如需了解详情，请参阅 《HTTP 203》这集。

消息渠道

浏览器支持

• 2
• 12
• 41
• 5

来源

消息通道需要定义并从一个上下文传递到另一个上下文的端口，以建立双向通信通道。

为了初始化该通道，该网页会实例化 MessageChannel 对象，并使用该对象向已注册的 Service Worker 发送端口。该网页还会在其上实现 onmessage 监听器，以接收来自其他上下文的消息：

const messageChannel = new MessageChannel();

//Init port
navigator.serviceWorker.controller.postMessage({type: 'PORT_INITIALIZATION'}, [
  messageChannel.port2,
]);

//Listen to messages
messageChannel.port1.onmessage = (event) => {
  // Process message
};

Service Worker 会接收端口，保存对它的引用，并使用它向另一端发送消息：

let communicationPort;

//Save reference to port
self.addEventListener('message', (event) => {
  if (event.data && event.data.type === 'PORT_INITIALIZATION') {
    communicationPort = event.ports[0];
  }
});

//Send messages
communicationPort.postMessage({type: 'MSG_ID'});

目前，所有主流浏览器都支持 MessageChannel。

高级 API：后台同步和后台提取

在本指南中，我们探索了实现双向通信技术的方法，适用于相对简单的情况，例如从一个上下文传递描述要执行的操作的字符串消息，或要缓存的网址列表。在本部分中，我们将探索两个 API，用于处理特定场景：网络连接不佳和下载时间过长。

后台同步

浏览器支持

• 49
• 79
• x
• x

来源

聊天应用可能希望确保消息不会因网络连接不佳而丢失。借助 Background Sync API，您可以将操作推迟到用户有稳定网络连接时重试。这有助于确保用户想要发送的内容都能实际发送。

该页面注册的不是 postMessage() 接口，而是 sync：

navigator.serviceWorker.ready.then(function (swRegistration) {
  return swRegistration.sync.register('myFirstSync');
});

然后，服务工作器会监听 sync 事件以处理消息：

self.addEventListener('sync', function (event) {
  if (event.tag == 'myFirstSync') {
    event.waitUntil(doSomeStuff());
  }
});

函数 doSomeStuff() 应返回一个 promise，指示其尝试执行的任何操作的成功/失败情况。如果它执行完毕，则表示同步已完成。如果同步失败，系统会安排再次尝试同步。重试同步也会等待连接，并采用指数退避算法。

执行操作后，服务工件可以使用之前介绍的任何通信 API 与页面进行通信，以更新界面。

Google 搜索会使用后台同步来保留因网络连接不佳而失败的查询，并在用户上线后重试这些查询。执行操作后，它们会通过 Web 推送通知将结果告知用户：

注意： 如需了解如何使用 Workbox 后台同步实现此功能，请参阅弹性搜索体验 。

后台提取

浏览器支持

• 74
• 79
• x
• x

来源

对于发送消息或要缓存的网址列表等相对较短的工作，到目前为止探索的选项非常适合。如果任务耗时过长，浏览器会终止服务 worker，否则可能会对用户的隐私和电池电量造成风险。

借助 Background Fetch API，您可以将长时间运行的任务分流到服务工件，例如下载电影、播客或游戏关卡。

如需从网页与服务工件通信，请使用 backgroundFetch.fetch，而不是 postMessage()：

navigator.serviceWorker.ready.then(async (swReg) => {
  const bgFetch = await swReg.backgroundFetch.fetch(
    'my-fetch',
    ['/ep-5.mp3', 'ep-5-artwork.jpg'],
    {
      title: 'Episode 5: Interesting things.',
      icons: [
        {
          sizes: '300x300',
          src: '/ep-5-icon.png',
          type: 'image/png',
        },
      ],
      downloadTotal: 60 * 1024 * 1024,
    },
  );
});

借助 BackgroundFetchRegistration 对象，网页可以监听 progress 事件，以跟踪下载进度：

bgFetch.addEventListener('progress', () => {
  // If we didn't provide a total, we can't provide a %.
  if (!bgFetch.downloadTotal) return;

  const percent = Math.round(
    (bgFetch.downloaded / bgFetch.downloadTotal) * 100,
  );
  console.log(`Download progress: ${percent}%`);
});

界面会更新以指示下载进度（左）。得益于服务工作器，操作可以在所有标签页关闭后继续运行（右）。

注意： 请参阅后台提取指南，其中包含播客应用示例及其故障代码。

后续步骤

在本指南中，我们探讨了页面和服务工件之间最常见的通信情况（双向通信）。

很多时候，一个上下文可能只需要与另一个上下文通信，而无需接收响应。请参阅以下指南，了解如何在页面中实现从服务工作器到页面和从页面到服务工作器的单向传输技术，以及相关用例和生产环境示例：

• 命令式缓存指南：从网页调用 Service Worker 以提前缓存资源（例如在预加载场景中）。
• 广播更新：从 Service Worker 调用页面，以便告知重要更新（例如有新版 Web 应用可用）。