service-worker - 刷新时激活更新的服务 worker

Question

当 Service Worker 更新时，它不会以正确的方式控制页面；它进入“等待”状态，等待被激活。

令人惊讶的是，更新后的 Service Worker 甚至在刷新页面后都无法控制选项卡。谷歌解释说:

https://developers.google.com/web/fundamentals/instant-and-offline/service-worker/lifecycle

Even if you only have one tab open to the demo, refreshing the page isn't enough to let the new version take over. This is due to how browser navigations work. When you navigate, the current page doesn't go away until the response headers have been received, and even then the current page may stay if the response has a Content-Disposition header. Because of this overlap, the current service worker is always controlling a client during a refresh.

To get the update, close or navigate away from all tabs using the current service worker. Then, when you navigate to the demo again, you should see the horse [updated content].

This pattern is similar to how Chrome updates. Updates to Chrome download in the background, but don't apply until Chrome restarts. In the mean time, you can continue to use the current version without disruption. However, this is a pain during development, but DevTools has ways to make it easier, which I'll cover later in this article.

这种行为在多个选项卡的情况下是有意义的。我的应用程序是一个需要自动更新的包；我们不能混合和匹配旧捆绑包的一部分和新捆绑包的一部分。 (在 native 应用程序中，原子性是自动且有保证的。)

但在单个选项卡的情况下，我将其称为应用程序的“最后打开的选项卡”，这种行为不是我想要的。我想刷新最后打开的选项卡以更新我的服务人员。

(很难想象有人真的希望旧的服务 worker 在刷新最后一个打开的选项卡时继续运行。谷歌的“导航重叠”论点在我看来像是一个不幸的错误的好借口。)

我的应用程序通常仅在单个选项卡中使用。在生产中，我希望我的用户能够通过刷新页面来使用最新的代码，但这不起作用:旧的服务 worker 将在刷新期间保持控制。

我不想告诉用户，“要接收更新，请务必关闭或离开我的应用程序。”我想告诉他们，“刷新一下。”

当用户刷新页面时，如何激活我更新的 service worker？

编辑:我知道有一个答案是快速、简单和错误的: skipWaiting在服务人员的安装事件中。 skipWaiting将在更新下载后立即使新的 service worker 生效，同时打开旧页面选项卡。这使得更新不安全地成为非原子的；这就像在应用程序运行时替换 native 应用程序包。这对我来说不行。我需要等到用户刷新最后一个打开的选项卡的页面。

Answer 1

从概念上讲，有两种更新，您的问题并不清楚我们正在谈论的是哪一种，所以我将两者都介绍。
更新内容
例如:

博文正文

事件日程

社交媒体时间线

这些可能会存储在缓存 API 或 IndexedDB 中。这些存储独立于服务 worker - 更新服务 worker 不应该删除它们，更新它们不应该需要更新服务 worker
更新 service worker 就相当于发送一个新的二进制文件，你不应该这样做来(例如)更新一篇文章。
当您更新这些缓存时，完全取决于您，如果您不更新它们，它们就不会更新。我在 offline cookbook 中介绍了许多模式。 , 但是 this is my favourite one :

使用 service worker 从缓存中提供页面 shell、css 和 js。

使用缓存中的内容填充页面。

尝试从网络获取内容。

如果内容比缓存中的内容更新，请更新缓存和页面。

就“更新页面”而言，您需要以一种不会干扰用户的方式来执行此操作。对于按时间顺序排列的列表，这很容易，因为您只需将新内容添加到底部/顶部。如果它正在更新一篇文章，那就有点棘手了，因为您不想从用户的眼睛下方切换文本。在这种情况下，通常更容易显示某种通知，例如“更新可用 - 显示更新 ”，单击它会刷新内容。
Trained to thrill (也许是有史以来第一个 service worker 示例)演示了如何更新数据的时间线。
更新“应用程序”
这是您确实想要更新服务 worker 的情况。当您处于以下情况时使用此模式:

更新您的页面外壳

更新 JS 和/或 CSS

如果您希望用户以非原子但相当安全的方式获得此更新，那么也有一些模式。

检测更新的服务 worker “等待”

向用户显示通知“更新可用 - 立即更新 ”

当用户单击此通知时，向 service worker 发送消息，要求它调用 skipWaiting .

检测新的 Service Worker 变得“活跃”

window.location.reload()

实现这个模式是我的 service worker Udacity course 的一部分。 , 和 here's the diff of the code before/after .
你也可以更进一步。例如，您可以使用某种 semver-esque 系统，这样您就知道用户当前拥有的 service worker 的版本。如果更新很小，您可以决定调用 skipWaiting()是完全安全的。