如何保持 Chrome 扩展程序的 Service Worker 持久存在？

Chrome 扩展中的持久化 Service Worker：指南

在 Chrome 中，Service Worker (SW) 持久性本身并不支持。根据设计，SW 会在不活动五分钟后卸载，这使得维持持续运行的服务具有挑战性。在本文中，我们将探索各种解决方法，以保持您的软件运行并响应事件。

已知问题和限制

• 非活动和卸载计时器： SW 有 30 秒不活动计时器和 5 分钟卸载计时器
• 事件执行问题： Chrome 可能无法始终如一地为所有 webRequest 事件唤醒 SW，尤其是在旧版本中。
• 频繁事件处理： 处理 webRequest 和 webNavigation 等频繁事件可能会导致软件过度重启，从而影响性能
• 连续 API 调用：连续调用某些 Chrome API 可以帮助延长软件的生命周期，但这种方法被认为是一种错误利用。

解决方法：

错误利用(Chrome 110 ):

• 将封装的 chrome.runtime.getPlatformInfo() 调用分配给变量并重复调用它可以使软件运行更长时间。

离屏API（Chrome 109 ):

• 创建一个离屏文档，每 30 秒向 SW 发送一条消息。此方法目前提供无限生命周期，但将来可能会进行修改。

NativeMessaging API (Chrome 105 ):

• 将 SW 连接到nativeMessaging 主机保持其运行，即使主机崩溃或关闭。

WebSocket API (Chrome 116 ):

• 建立 WebSocket 连接并每 25 秒交换消息以防止不活动。

Chrome 消息传递API：

• 每 30 秒从专用选项卡向 SW 发送一条消息。这需要广泛的主机权限，但不需要本机应用程序或 API。

专用选项卡：

• 打开带有扩展页面的浏览器选项卡与SW通信。这种方法模仿持久的后台页面，但会消耗更多内存并分散用户的注意力。

注意事项：

• 资源消耗过多：仅在必要时使用保持活动机制，并在任务完成后禁用它们。
• 状态管理：实施策略在意外崩溃的情况下保存和恢复软件状态。
• 持久假设： 避免仅出于简化状态管理的目的而持久化 SW。使用它主要是为了在重建状态成本昂贵或响应频繁事件的情况下提高性能。

以上是如何保持 Chrome 扩展程序的 Service Worker 持久存在？的详细内容。更多信息请关注PHP中文网其他相关文章！