service-worker - clientsClaim 和 skipWaiting 之间的区别

Question

我试图了解 skipWaiting 之间的区别和 clientsClaim .据我了解:调用 skipWaiting将导致新的 Service Worker 跳过等待阶段，并立即变为事件状态。 clientsClaim然后也可以“声明”任何其他打开的标签。

我从在线文档中收集到的信息:

skipWaiting跳过等待阶段，并立即激活 source

clientsClaim立即开始控制页面 source

在我在网上找到的每个帖子中，我通常总是看到 clientsClaim和 skipWaiting一起使用。

不过最近发现一个service worker只用了 clientsClaim ，而且我很难弄清楚 clientsClaim 之间的实际区别是什么和 skipWaiting ，以及在什么场景下使用 clientsClaim但不是 skipWaiting ?

我对此的想法，这可能是我错的地方，但这是我的理解:
是那个电话 clientsClaim ，但不是 skipWaiting是多余的吗？考虑:

当所有打开的页面都关闭时，新的 Service Worker 将变为事件状态(因为我们没有使用 skipWaiting)

当我们的新 service worker 被激活时，我们调用 clientsClaim ，即使我们刚刚关闭了所有打开的页面，甚至激活了新的 Service Worker。应该没有其他页面需要控制，因为我们刚刚关闭了它们。

有人可以帮我理解吗？

阅读有关 skipWaiting 的文档

阅读有关 clientsClaim 的文档

阅读 service worker lifecycle作者:Jake Archibald，和 this demo 一起玩

阅读一堆 stackoverflow 帖子、离线食谱、不同的博客帖子等。

Answer 1

self.skipWaiting()完全符合您的描述:

forces the waiting service worker to become the active service

从这个意义上说，“事件”并不意味着任何当前加载的客户端现在正在与该服务交谈。相反，它意味着服务现在是每当新客户端请求它时要使用的服务。

这是哪里 Clients.claim()进来:

When a service worker is initially registered, pages won't use it until they next load.

无需调用 claim ，任何现有客户端仍将继续与较旧的 Service Worker 对话，直到整个页面加载完毕。

虽然大多数时候使用 skipWaiting 是有意义的和 Clients.claim同时，情况并非总是如此。如果由于 Service Worker 不向后兼容而导致用户体验不佳， Clients.claim不应该被调用。相反，下次刷新或加载客户端时，它现在将拥有新的 Service Worker，而不必担心发生重大变化。