如何保持 Chrome 擴充功能的 Service Worker 持久存在？

Chrome 擴充功能中的持久化 Service Worker：指南

在 Chrome 中，Service Worker (SW) 持久性本身並不支援。根據設計，SW 會在不活動五分鐘後卸載，這使得維持持續運作的服務具有挑戰性。在本文中，我們將探索各種解決方法，以保持您的軟體運作並回應事件。

已知問題和限制

• 非活動和卸載計時器： SW 有30 秒不活動計時器和5 分鐘卸載計時器
• 事件執行問題： Chrome可能無法一致地為所有 webRequest 事件喚醒 SW，尤其是在舊版本中。
• 頻繁事件處理： 處理webRequest 和webNavigation 等頻繁事件可能會導致軟體過度重啟，進而影響效能
• 連續API 呼叫：連續呼叫某些Chrome API 可以幫助延長軟體的生命週期，但這種方法被認為是一種錯誤利用。

解決方法：

錯誤利用(Chrome 110 ):

• 將封裝的.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中文網其他相關文章！