首先看一張圖了解一下service-worker的生命周期機制.
without skipWaiting
當我們第一次注冊service-worker的時候,installed后會立即變?yōu)閍ctivating狀態(tài),
頁面將會被第一個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后立即變?yōu)榧せ顮顟B(tài),這就會導致舊的service-worker被排擠,就會出現(xiàn)一部分頁面被舊serivice-worker所接管過,一部分被新service-worker接管,如果你的頁面出現(xiàn)問題,就不要用skipWaiting,(官方說出現(xiàn)問題就不要用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/
