27

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

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

4

2 に答える 2

45

表示されているのは予想される動作であり、変更される可能性はほとんどありません。

サービス ワーカーの寿命は、意図的に非常に短くなっています。installそれらは、特定のイベント ( 、activatemessagefetch、など)に応答して「生まれ」、pushタスクを実行し、その後すぐに「死ぬ」。寿命は通常、ワーカが死ぬ前に複数のイベントを処理できる (つまり、installan のactivate後に が続き、 aが続く) のに十分な長さですが、最終的には死ぬでしょう。fetchこれが、スクリプト内のグローバル状態に依存せず、Service Worker の起動時に IndexedDB または Cache Storage API を介して必要な状態情報をブートストラップすることが非常に重要である理由です。

サービス ワーカーは、特定の Web ページにアクセスするたびにインストールされる事実上のバックグラウンド プロセスです。これらのバックグラウンド プロセスが無期限に実行されると、バッテリーやデバイス/コンピューターのパフォーマンスに悪影響を及ぼすリスクが高まります。このリスクを軽減するために、ブラウザーは、必要であることがわかっている場合 (イベントに応答する場合など) にのみ、これらのプロセスを実行します。

の使用例WebSocketsは、クライアントにサーバーからのデータをリッスンさせることです。そのようなユースケースの場合、 Service Worker にとって使いやすい代替手段WebSocketsは、Push Messaging APIpushを使用して Service Worker にイベントに応答させることです。push現在の Chrome 実装では、イベントを処理するときにユーザーに表示される通知を表示する必要があることに注意してください。「サイレント」pushユースケースは現在サポートされていません。

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

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

于 2015-04-20T14:39:28.353 に答える