防止服务工作者自动停止 [英] Prevent Service Worker from automatically stopping

查看:88
本文介绍了防止服务工作者自动停止的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

服务工作者似乎在某个时候自动停止。此行为无意中关闭了在激活时建立的WebSocket连接。

Service Worker seems to automatically stop at some point. This behaviour unintentionally closes the WebSocket connection established on activate.

何时以及为何停止?如何以编程方式禁用此意外操作以使Service Worker保持运行?

When and Why does it stop? How can I programmatically disable this unexpected action to keep Service Worker stay running?

推荐答案

您所看到的是预期的行为,并且它不太可能改变。

What you're seeing is the expected behavior, and it's not likely to change.

服务工作者故意拥有非常短的寿命。它们是天生的以响应特定事件(安装激活消息 fetch push 等),执行他们的任务,然后死不久之后。生命周期通常足够长,可以处理多个事件(即安装后面可能跟着激活,然后是在工人去世之前,获取),但最终会死亡。这就是为什么不依赖脚本中的任何全局状态,以及在服务工作者启动时通过IndexedDB或Cache Storage API引导您需要的任何状态信息非常重要的原因。

Service workers intentionally have very short lifespans. They are "born" in response to a specific event (install, activate, message, fetch, push, etc.), perform their task, and then "die" shortly thereafter. The lifespan is normally long enough that multiple events might be handled (i.e. an install might be followed by an activate followed by a fetch) before the worker dies, but it will die eventually. This is why it's very important not to rely on any global state in your scripts, and to bootstrap any state information you need via IndexedDB or the Cache Storage API when your service worker starts up.

服务工作者实际上是在您访问某些网页时安装的后台进程。如果允许这些后台进程无限期运行,则会增加对设备/计算机的电池和性能产生负面影响的风险。为了降低这种风险,您的浏览器只会在知道必要时运行这些流程,即响应事件。

Service workers are effectively background processes that get installed whenever you visit certain web pages. If those background processes were allowed to run indefinitely, there's an increased risk of negative impact on battery and performance of your device/computer. To mitigate this risk, your browser will only run those processes when it knows it's necessary, i.e. in response to an event.

的用例WebSockets 让您的客户端从服务器侦听一些数据。对于该用例,使用 WebSockets 的服务工作者友好的替代方法是使用推送消息传递API 并让您的服务工作者响应推送事件。请注意,在当前的Chrome实施中,您必须在处理推送事件时显示用户可见的通知。目前不支持无声推送用例。

A use case for WebSockets is having your client listen for some data from the server. For that use case, the service worker-friendly alternative to using WebSockets is to use the Push Messaging API and have your service worker respond to push events. Note that in the current Chrome implementation, you must show a user-visible notification when handling a push event. The "silent" push use case is not supported right now.

如果不是从服务器监听数据,你使用 WebSockets 作为从客户端向服务器发送数据的一种方式,遗憾的是没有很好的服务工作者友好的方式。在将来的某个时候,可能有一种方法可以通过定期/基于时间的事件来注册您的服务工作者,此时您可以使用 fetch()将数据发送到服务器,但目前在任何浏览器中都不支持。

If instead of listening to data from the server, you were using WebSockets as a way of sending data from your client to your server, there's unfortunately no great service worker-friendly way of doing that. At some point in the future, there may be a way of registering your service worker to be woken up via a periodic/time-based event at which point your could use fetch() to send data to the server, but that's currently not supported in any browsers.

PS:Chrome(通常)不会杀死服务人员将DevTools界面打开,但这只是为了简化调试,而不是你应该依赖的实际应用程序。

这篇关于防止服务工作者自动停止的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆