迁移到 Service Worker

使用 Service Worker 替换背景或事件页面

Service Worker 会替换扩展程序的后台或事件页面，以确保后台代码远离主线程。这样可以让扩展程序仅在需要时运行，从而节省资源。

自推出以来，后台网页一直是扩展程序的基本组成部分。简单来说，后台网页提供了一种独立于其他任何窗口或标签页的环境。这样，扩展程序就可以观察事件并响应事件。

本页面介绍了将后台页面转换为扩展程序 Service Worker 的任务。如需大致了解扩展程序 Service Worker，请参阅使用 Service Worker 处理事件教程和关于扩展程序 Service Worker 部分。

后台脚本与扩展 Service Worker 之间的区别

在某些情况下，您会看到称为“后台脚本”的扩展程序 Service Worker。尽管扩展 Service Worker 确实在后台运行，但通过暗示功能完全相同，调用后台脚本有一定的误导性。区别将在下面进行介绍。

与后台页面相比的变化

Service Worker 与后台页面存在很多差异。

• 它们在主线程以外运行，这意味着它们不会干扰扩展程序内容。
• 它们具有特殊功能，例如拦截扩展程序来源上的提取事件，例如拦截工具栏弹出式窗口中的提取事件。
• 它们可以通过客户端界面与其他上下文进行通信和交互。

需要进行的更改

您需要对代码进行一些调整，以考虑后台脚本和 Service Worker 运行方式之间的差异。首先，在清单文件中指定 Service Worker 的方式与指定后台脚本的方式不同。此外：

• 由于它们无法访问 DOM 或 window 接口，因此您需要将此类调用移至其他 API 或移至屏幕外文档中。
• 不应注册事件监听器来响应返回的 promise 或在事件回调内部。
• 由于它们不向后兼容 XMLHttpRequest()，因此您需要将对此接口的调用替换为对 fetch() 的调用。
• 由于它们在不使用时终止，因此您需要保留应用状态，而不是依赖于全局变量。终止 Service Worker 还可以在计时器完成之前结束计时器。您需要将其替换为闹钟。

本页面详细介绍了这些任务。

更新清单中的“background”字段

在 Manifest V3 中，后台页面被 Service Worker 所取代。下面列出了清单更改。

• 将 manifest.json 中的 "background.scripts" 替换为 "background.service_worker"。请注意，"service_worker" 字段接受字符串，而不是字符串数组。
• 从 manifest.json 中移除 "background.persistent"。

{
  ...
  "background": {
    "scripts": [
      "backgroundContextMenus.js",
      "backgroundOauth.js"
    ],
    "persistent": false
  },
  ...
}

{
  ...
  "background": {
    "service_worker": "service_worker.js",
    "type": "module"
  }
  ...
}

"service_worker" 字段接受单个字符串。仅当您使用 ES 模块（使用 import 关键字）时，才需要 "type" 字段。其值将始终为 "module"。如需了解详情，请参阅 Extension Service Worker 基础知识

将 DOM 和窗口调用移至屏幕外文档

某些扩展程序需要访问 DOM 和窗口对象，而无需在视觉上打开新的窗口或标签页。Offscreen API 支持这类使用情形，因为这类 API 可以打开和关闭与扩展程序打包在一起的未显示文档，而不会干扰用户体验。除了消息传递之外，屏幕外文档不会与其他扩展程序上下文共享 API，而是起到完整网页的作用，供扩展程序进行互动。

如需使用 Offscreen API，请通过 Service Worker 创建屏幕外文档。

chrome.offscreen.createDocument({
  url: chrome.runtime.getURL('offscreen.html'),
  reasons: ['CLIPBOARD'],
  justification: 'testing the offscreen API',
});

在屏幕外文档中，执行您之前在后台脚本中运行的任何操作。例如，您可以复制在托管网页上选择的文本。

let textEl = document.querySelector('#text');
textEl.value = data;
textEl.select();
document.execCommand('copy');

使用消息传递功能在屏幕外文档和扩展 Service Worker 之间通信。

将 localStorage 转换为其他类型

Web 平台的 Storage 接口（可从 window.localStorage 访问）无法在 Service Worker 中使用。要解决这一问题，请执行以下操作之一。首先，您可以将其替换为对其他存储机制的调用。chrome.storage.local 命名空间适用于大多数用例，但也可以使用其他选项。

也可以将其通话移至屏幕外文档。例如，如需将之前存储在 localStorage 中的数据迁移到其他机制，请使用以下代码：

1. 使用转化例程和 runtime.onMessage 处理程序创建屏幕外文档。
2. 向屏幕外文档添加转换例程。
3. 在扩展 Service Worker 中，检查 chrome.storage 中的数据。
4. 如果未找到您的数据，请创建屏幕外文档并调用 runtime.sendMessage() 以启动转换例程。
5. 在您添加到屏幕外文档的 runtime.onMessage 处理程序中，调用转换例程。

Web Storage API 在扩展程序中的工作原理也存在一些细微差别。如需了解详情，请参阅存储和 Cookie。

同步注册监听器

异步注册监听器（例如在 promise 或 callback 中）注册并不一定能在 Manifest V3 中有效。请参考以下代码。

chrome.storage.local.get(["badgeText"], ({ badgeText }) => {
  chrome.browserAction.setBadgeText({ text: badgeText });
  chrome.browserAction.onClicked.addListener(handleActionClick);
});

这适用于永久后台网页，因为网页不断运行且永远不会重新初始化。在 Manifest V3 中，系统会在分派事件时重新初始化 Service Worker。这意味着当事件触发时，系统不会注册监听器（因为它们是异步添加的），系统还会错过事件。

请改为将事件监听器注册移至脚本的顶层。这样可以确保 Chrome 能够立即找到并调用您的操作的点击处理程序，即使扩展程序尚未执行其启动逻辑也是如此。

chrome.action.onClicked.addListener(handleActionClick);

chrome.storage.local.get(["badgeText"], ({ badgeText }) => {
  chrome.action.setBadgeText({ text: badgeText });
});

将 XMLHttpRequest() 替换为全局 fetch()

无法从 Service Worker、扩展程序或其他方法调用 XMLHttpRequest()。将后台脚本对 XMLHttpRequest() 的调用替换为对全局 fetch() 的调用。

const xhr = new XMLHttpRequest();
console.log('UNSENT', xhr.readyState);

xhr.open('GET', '/api', true);
console.log('OPENED', xhr.readyState);

xhr.onload = () => {
    console.log('DONE', xhr.readyState);
};
xhr.send(null);

const response = await fetch('https://www.example.com/greeting.json'')
console.log(response.statusText);

保留状态

Service Worker 是临时的，这意味着它们可能会在用户的浏览器会话期间反复启动、运行和终止。这也意味着，自之前的上下文销毁后，数据并非立即在全局变量中可用。如需解决此问题，请使用存储 API 作为可靠来源。以下示例展示了如何执行此操作。

以下示例使用全局变量来存储名称。在 Service Worker 中，此变量可能会在用户的浏览器会话过程中多次重置。

let savedName = undefined;

chrome.runtime.onMessage.addListener(({ type, name }) => {
  if (type === "set-name") {
    savedName = name;
  }
});

chrome.browserAction.onClicked.addListener((tab) => {
  chrome.tabs.sendMessage(tab.id, { name: savedName });
});

对于 Manifest V3，请将全局变量替换为对 Storage API 的调用。

chrome.runtime.onMessage.addListener(({ type, name }) => {
  if (type === "set-name") {
    chrome.storage.local.set({ name });
  }
});

chrome.action.onClicked.addListener(async (tab) => {
  const { name } = await chrome.storage.local.get(["name"]);
  chrome.tabs.sendMessage(tab.id, { name });
});

将计时器转换为闹钟

通过 setTimeout() 或 setInterval() 方法使用延迟或定期操作是一种常见做法。不过，这些 API 在 Service Worker 中可能会失败，因为每当 Service Worker 终止时，计时器就会取消。

// 3 minutes in milliseconds
const TIMEOUT = 3 * 60 * 1000;
setTimeout(() => {
  chrome.action.setIcon({
    path: getRandomIconPath(),
  });
}, TIMEOUT);

而是改用 Alarms API。与其他监听器一样，警报监听器应在脚本的顶层注册。

async function startAlarm(name, duration) {
  await chrome.alarms.create(name, { delayInMinutes: 3 });
}

chrome.alarms.onAlarm.addListener(() => {
  chrome.action.setIcon({
    path: getRandomIconPath(),
  });
});

使 Service Worker 保持活跃状态

根据定义，Service Worker 由事件驱动，在闲置时终止。这样，Chrome 就可以优化扩展程序的性能和内存消耗。如需了解详情，请参阅我们的 Service Worker 生命周期文档。特殊情况可能需要采取额外的措施来确保 Service Worker 延长的活跃时间。

在长时间运行的操作完成之前使 Service Worker 保持活跃状态

在长时间运行的 Service Worker 操作（不调用扩展 API）期间，Service Worker 可能会在操作过程中关闭。例如：

• fetch() 请求的用时可能会超过 5 分钟（例如，网络连接状况不佳的情况下下载大量内容）。
• 复杂的异步计算需要超过 30 秒。

在这些情况下，要延长 Service Worker 的生命周期，您可以定期调用一个普通的扩展 API 来重置超时计数器。请注意，这仅适用于特殊情况，在大多数情况下，通常有一种更好的平台惯用方式可以实现相同的结果。

以下示例展示了一个 waitUntil() 辅助函数，该函数会在给定 promise 解析之前使 Service Worker 保持活跃状态：

async function waitUntil(promise) = {
  const keepAlive = setInterval(chrome.runtime.getPlatformInfo, 25 * 1000);
  try {
    await promise;
  } finally {
    clearInterval(keepAlive);
  }
}

waitUntil(someExpensiveCalculation());

使 Service Worker 连续保持活跃状态

在极少数情况下，您需要无限期延长生命周期。我们已将企业和教育机构视为最大的用例，并明确允许此类用例，但总体上不支持此功能。在这些特殊情况下，可以通过定期调用普通扩展 API 来使 Service Worker 保持活跃状态。请务必注意，此建议仅适用于在企业或教育用例的受管理设备上运行的扩展程序。在其他情况下则不允许。Chrome 扩展程序团队保留对此类扩展程序采取措施的权利。

使用以下代码段使 Service Worker 保持活跃状态：

/**
 * Tracks when a service worker was last alive and extends the service worker
 * lifetime by writing the current time to extension storage every 20 seconds.
 * You should still prepare for unexpected termination - for example, if the
 * extension process crashes or your extension is manually stopped at
 * chrome://serviceworker-internals. 
 */
let heartbeatInterval;

async function runHeartbeat() {
  await chrome.storage.local.set({ 'last-heartbeat': new Date().getTime() });
}

/**
 * Starts the heartbeat interval which keeps the service worker alive. Call
 * this sparingly when you are doing work which requires persistence, and call
 * stopHeartbeat once that work is complete.
 */
async function startHeartbeat() {
  // Run the heartbeat once at service worker startup.
  runHeartbeat().then(() => {
    // Then again every 20 seconds.
    heartbeatInterval = setInterval(runHeartbeat, 20 * 1000);
  });
}

async function stopHeartbeat() {
  clearInterval(heartbeatInterval);
}

/**
 * Returns the last heartbeat stored in extension storage, or undefined if
 * the heartbeat has never run before.
 */
async function getLastHeartbeat() {
  return (await chrome.storage.local.get('last-heartbeat'))['last-heartbeat'];
}