web-dev-qa-db-ja.com

ServiceWorkerが自動的に停止しないようにする

Service Workerは、ある時点で自動的に停止するようです。この動作により、アクティブ化時に確立されたWebSocket接続が意図せずに閉じられます。

いつ、なぜ停止するのですか?この予期しないアクションをプログラムで無効にして、Service Workerを実行し続けるにはどうすればよいですか?

17
Lewis

あなたが見ているのは予想される振る舞いであり、それは変わらないでしょう。

サービスワーカーの寿命は意図的に非常に短くなっています。それらは特定のイベント(installactivatemessagefetchPushなど)に応答して「生まれる」。 、タスクを実行し、その後すぐに「死ぬ」。ライフスパンは通常、ワーカーが死ぬ前に複数のイベントが処理される可能性があるほど十分に長いです(つまり、installの後にactivateの後にfetchが続く場合があります)が、最終的に死ぬ。これが、スクリプト内のグローバル状態に依存せず、ServiceWorkerの起動時にIndexedDBまたはCacheStorageAPIを介して必要な状態情報をbootstrapすることが非常に重要である理由です。

Service Workerは、特定のWebページにアクセスするたびにインストールされるバックグラウンドプロセスです。これらのバックグラウンドプロセスの実行が無期限に許可された場合、バッテリーとデバイス/コンピューターのパフォーマンスに悪影響を与えるリスクが高まります。このリスクを軽減するために、ブラウザは、必要であることがわかっている場合、つまりイベントへの応答時にのみ、これらのプロセスを実行します。

WebSocketsの使用例は、クライアントにサーバーからのデータをリッスンさせることです。そのユースケースでは、WebSocketsを使用する代わりにサービスワーカーが使いやすい方法は、 プッシュメッセージングAPI を使用し、サービスワーカーにPushイベントに応答させることです。現在のChrome実装では、Pushイベントを処理するときにユーザーに表示される通知を表示する必要があることに注意してください。「サイレント」Pushユースケースはそうではありません現在サポートされています。

サーバーからデータをリッスンする代わりに、クライアントからサーバーにデータを送信する方法としてWebSocketsを使用していた場合、残念ながら、サービスワーカーに優しい優れた方法はありません。将来のある時点で、定期的/時間ベースのイベントを介してウェイクアップするサービスワーカーを登録する方法があるかもしれません。その時点で、fetch()を使用してサーバーにデータを送信できますが、現在、どのブラウザでもサポートされていません。

PS:Chrome(通常)DevToolsインターフェイスを開いている間はService Workerを強制終了しませんが、これはデバッグを容易にするためだけであり、動作ではありません実際のアプリケーションを信頼する必要があります。

27
Jeff Posnick