首先看一张图了解一下service-worker的生命周期机制.
without skipWaiting
当我们第一次注册service-worker的时候,installed后会立即变为activating状态,
页面将会被第一个service-worker接管.
如果我们更新了service-worker,这个时候,页面刷新是更新不了新的service-worker 的,因为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.
https://developers.google.com/web/fundamentals/primers/service-workers/lifecycle
只能关闭被该service-worker控制的页面.skipWaiting能让新的service-worker installed后立即变为激活状态,这就会导致旧的service-worker被排挤,就会出现一部分页面被旧serivice-worker所接管过,一部分被新service-worker接管,如果你的页面出现问题,就不要用skipWaiting,(官方说出现问题就不要用skipWaiting,真的醉了).
这里还有一篇文章不是很懂作者所说的一段特定时间的意思.官方也没说过类似的,参考一下吧.
Endless waiting
If the page already has an activated service worker and a new file is pushed, the new file will still be parsed and installed. Once installed, it will wait for an opportunity to become activated.
Without self.skipWaiting(), a waiting service worker will only become active itself once the currently active service worker is released and becomes redundant. This can only happen in two scenarios:
- If the user has navigated away from the page, thereby releasing the previous active worker
- If a specified period of time has passed, thereby releasing the previous active worker.
So, unlike we are used to when pushing new versions of assets to our website, a new version of a service worker can be waiting for what seems like forever. Even if a user refreshes their page, they may not receive the updated version for a very long time.
https://bitsofco.de/what-self-skipwaiting-does-to-the-service-worker-lifecycle/
