使用 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
中的数据迁移到其他机制,请使用以下代码:
- 使用转化例程和
runtime.onMessage
处理程序创建屏幕外文档。 - 向屏幕外文档添加转换例程。
- 在扩展 Service Worker 中,检查
chrome.storage
中的数据。 - 如果未找到您的数据,请创建屏幕外文档并调用
runtime.sendMessage()
以启动转换例程。 - 在您添加到屏幕外文档的
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'];
}