Chrome 拡張機能の Service Worker を永続的に維持するにはどうすればよいですか?

Chrome 拡張機能の Persistent Service Worker: ガイド

Chrome では、Service Worker (SW) の永続化は本質的にサポートされていません。設計上、SW は非アクティブ状態が 5 分間続くとアンロードされるように設計されているため、サービスを継続的に実行し続けることが困難になります。この記事では、SW を実行し、イベントに応答し続けるためのさまざまな回避策を検討します。

既知の問題と制限事項

• 非アクティブおよびアンロード タイマー: SW には 30 秒の非アクティブ タイマーと 5 分間のアンロードがあります。 timer.
• イベント実行の問題: Chrome は、特に古いバージョンでは、すべての webRequest イベントに対して SW を一貫してウェイクアップしない場合があります。
• 頻繁なイベント処理: webRequest や webNavigation などの頻繁なイベントを処理すると、過剰な SW の再起動が発生し、パフォーマンスに影響を与える可能性があります。
• 連続 API 呼び出し: 特定の Chrome API を連続して呼び出すと、SW の寿命を延ばすことができますが、このアプローチはバグエクスプロイトとみなされます。

回避策:

バグの悪用(Chrome 110 ):

• ラップされた chrome.runtime.getPlatformInfo() 呼び出しを変数に代入し、繰り返し呼び出すと、SW の実行時間が長くなります。

オフスクリーン API (Chrome 109) ):

• 30 秒ごとに SW にメッセージを送信するオフスクリーン ドキュメントを作成します。このメソッドは現在、無制限の有効期間を提供していますが、将来的に改訂される可能性があります。

NativeMessaging API (Chrome 105 ):

• SW の接続ネイティブメッセージングホストは、ホストがクラッシュしたり、

WebSocket API (Chrome 116 ):

• WebSocket 接続を確立し、非アクティブ状態を防ぐために 25 秒ごとにメッセージを交換します。

Chrome メッセージングAPI:

• 30 秒ごとに専用タブから SW にメッセージを送信します。これには広範なホスト権限が必要ですが、ネイティブ アプリや API は必要ありません。

専用タブ:

• 拡張機能ページでブラウザ タブを開きます。 SWと通信します。このアプローチは永続的なバックグラウンド ページを模倣しますが、より多くのメモリを消費し、ユーザーの注意をそらします。

注意:

• 過剰なリソース消費: 必要な場合にのみキープアライブ メカニズムを使用し、タスクが完了したら無効にします。
• 状態管理: 戦略を実装する予期せぬ事態が発生した場合に SW 状態を保存および復元するため
• 永続的な前提: 状態管理を簡素化することだけを目的として SW を永続化することは避けてください。これは主に、状態の再構築にコストがかかる場合、または頻繁なイベントに対応してパフォーマンスを向上させるために使用します。

以上がChrome 拡張機能の Service Worker を永続的に維持するにはどうすればよいですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。