service work的生命週期
author: 果果 data：2020.04.25 16:49
Service Worker 的使用過程很簡單，所處理的事情也相對單一，我們基本上需要做的就是利用這個 API 做好站點
的緩存策略。在頁面腳本中註冊 Service Worker 文件所在的 URL。Worker 就可以開始激活了，激活後的 Service
Worker 可以監聽當前域下的功能性事件，比如資源請求（fetch）、推送通知（push）、後臺同步（sync）。
在這一系列的流程中，從 Service Worker 的註冊到消失，經歷了生命週期中不同的狀態。
如何工作
1、首先我們需要在頁面的 JavaScript 主線程中使用 serviceWorkerContainer.register() 來註冊 Service
Worker ，在註冊的過程中，瀏覽器會在後臺啓動嘗試 Service Worker 的安裝步驟。
2、如果註冊成功，Service Worker 在 ServiceWorkerGlobalScope 環境中運行； 這是一個特殊的 worker
context，與主腳本的運行線程相獨立，同時也沒有訪問 DOM 的能力。
3、後臺開始安裝步驟， 通常在安裝的過程中需要緩存一些靜態資源。如果所有的資源成功緩存則安裝成功，如果有任
何靜態資源緩存失敗則安裝失敗，在這裏失敗的不要緊，會自動繼續安裝直到安裝成功，如果安裝不成功無法進行下一
步 — 激活 Service Worker。
4、開始激活 Service Worker，必須要在 Service Worker 安裝成功之後，才能開始激活步驟，當 Service Worker
安裝完成後，會接收到一個激活事件（activate event）。激活事件的處理函數中，主要操作是清理舊版本的 Service Worker 腳本中使用資源。
5、激活成功後 Service Worker 可以控制頁面了，但是隻針對在成功註冊了 Service Worker 後打開的頁面。也就
是說，頁面打開時有沒有 Service Worker，決定了接下來頁面的生命週期內受不受 Service Worker 控制。所以，
只有當頁面刷新後，之前不受 Service Worker 控制的頁面纔有可能被控制起來。
生命週期
我們已經知道了，Service Worker 的工作原理是基於註冊、安裝、激活等步驟在瀏覽器 js 主線程中獨立分擔緩存任
務的，那麼我們如何在這些 API 自身一系列的操作中進行一些我們自己想讓 worker 乾的事情呢？
這裏我們需要了解一下 Service Worker 的生命週期的概念，這有利於我們學會在各個生命週期的階段進行有目的性的
回調，讓我們自定義的工作在 Service Worker 中正確有效的開展下去。MDN 給出了詳細的 Service Worker 生命周
期圖：
來張圖
我們可以看到生命週期分爲這麼幾個狀態 安裝中, 安裝後, 激活中, 激活後, 廢棄
1、安裝( installing )：這個狀態發生在 Service Worker 註冊之後，表示開始安裝，觸發 install 事件回調指
定一些靜態資源進行離線緩存。
install 事件回調中有兩個方法：
（1）event.waitUntil()：傳入一個 Promise 爲參數，等到該 Promise 爲 resolve 狀態爲止。
（2）self.skipWaiting()：self 是當前 context 的 global 變量，執行該方法表示強制當前處在 waiting
狀態的 Service Worker 進入 activate 狀態。
2、安裝後( installed )：Service Worker 已經完成了安裝，並且等待其他的 Service Worker 線程被關閉。
3、激活( activating )：在這個狀態下沒有被其他的 Service Worker 控制的客戶端，允許當前的 worker 完成安
裝，並且清除了其他的 worker 以及關聯緩存的舊緩存資源，等待新的 Service Worker 線程被激活。
activate 回調中有兩個方法：
（1）event.waitUntil()：傳入一個 Promise 爲參數，等到該 Promise 爲 resolve 狀態爲止。
（2）self.clients.claim()：在 activate 事件回調中執行該方法表示取得頁面的控制權, 這樣之後打開頁面都會使用版本更新的緩存。舊的 Service Worker 腳本不再控制着頁面，之後會被停止。
4、激活後( activated )：在這個狀態會處理 activate 事件回調 (提供了更新緩存策略的機會)。並可以處理功能性
的事件 fetch (請求)、sync (後臺同步)、push (推送)。
5、廢棄狀態 ( redundant )：這個狀態表示一個 Service Worker 的生命週期結束。
這裏特別說明一下，進入廢棄 (redundant) 狀態的原因可能爲這幾種：
1、安裝 (install) 失敗
2、激活 (activating) 失敗
3、新版本的 Service Worker 替換了它併成爲激活狀態
支持的事件
1、install：Service Worker 安裝成功後被觸發的事件，在事件處理函數中可以添加需要緩存的文件（詳見 使用
Service Worker ）
2、activate：當 Service Worker 安裝完成後並進入激活狀態，會觸發 activate 事件。通過監聽 activate 事件
你可以做一些預處理，如對舊版本的更新、對無用緩存的清理等。（詳見 更新 Service Worker ）
3、message：Service Worker 運行於獨立 context 中，無法直接訪問當前頁面主線程的 DOM 等信息，但是通過
postMessage API，可以實現他們之間的消息傳遞，這樣主線程就可以接受 Service Worker 的指令操作 DOM。
4、Service Worker 有幾個重要的功能性的的事件，這些功能性的事件支撐和實現了 Service Worker 的特性。
5、fetch (請求)：當瀏覽器在當前指定的 scope 下發起請求時，會觸發 fetch 事件，並得到傳有 response 參數的回調函數，回調中就可以做各種代理緩存的事情了。
6、push (推送)：push 事件是爲推送準備的。不過首先需要了解一下 Notification API 和 PUSH API。通過 PUSH
API，當訂閱了推送服務後，可以使用推送方式喚醒 Service Worker 以響應來自系統消息傳遞服務的消息，即使用戶
已經關閉了頁面。
7、sync (後臺同步)：sync 事件由 background sync (後臺同步)發出。background sync 配合 Service Worker
推出的 API，用於爲 Service Worker 提供一個可以實現註冊和監聽同步處理的方法。但它還不在 W3C Web API 標
準中。在 Chrome 中這也只是一個實驗性功能，需要訪問 chrome://flags/#enable-experimental-web-
platform-features ，開啓該功能，然後重啓生效。PWA 採用的最新技術，當前瀏覽器還沒有達到完全支持的程度，
W3C 關於這些技術的標準也還在處於草稿狀態，沒有定稿。
更新
Service Worker 的特殊之處除了由瀏覽器觸發更新之外，還應用了特殊的緩存策略： 如果該文件已 24 小時沒有更新，當 Update 觸發時會強制更新。這意味着最壞情況下 Service Worker 會每天更新一次。
結語
技術交流，共同進步，歡迎fork和star！