欢乐颂,古风小说君子以泽

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

WorkBox之底層邏輯ServiceWorker

1. 前置知識點

「前置知識點」，只是做一個概念的介紹，不會做深度解釋。因為，這些概念在下面文章中會有出現(xiàn)，為了讓行文更加的順暢，所以將本該在文內(nèi)的概念解釋放到前面來?！溉绻蠹覍@些概念熟悉，可以直接忽略」同時，由于閱讀我文章的群體有很多，所以有些知識點可能「我視之若珍寶，爾視只如草芥，棄之如敝履」。以下知識點，請「酌情使用」。

創(chuàng)新互聯(lián)是一家專注于成都網(wǎng)站建設(shè)、成都做網(wǎng)站與策劃設(shè)計,孝昌網(wǎng)站建設(shè)哪家好?創(chuàng)新互聯(lián)做網(wǎng)站,專注于網(wǎng)站建設(shè)十年,網(wǎng)設(shè)計領(lǐng)域的專業(yè)建站公司;建站業(yè)務(wù)涵蓋:孝昌等地區(qū)。孝昌做網(wǎng)站價格咨詢:18982081108

如何查看Service Worker

要查看正在運行的Service workers列表，我們可以在Chrome/Chromium中地址欄中輸入chrome://serviceworker-internals/。

圖片

chrome://xx 包含了很多內(nèi)置的功能，這塊也是有很大的說道的。后期，會單獨有一個專題來講。(已經(jīng)在籌劃準備中....)

Cache API

Cache API為緩存的 Request / Response 對象對提供存儲機制。例如，作為ServiceWorker 生命周期的一部分

Cache API像 workers 一樣，是暴露在 window 作用域下的。盡管它被定義在 service worker 的標(biāo)準中，但是它不必一定要配合 service worker 使用。

「一個域可以有多個命名 Cache 對象」。我們需要在腳本 (例如，在 ServiceWorker 中) 中處理緩存更新的方式。

除非明確地更新緩存，否則緩存將不會被更新；
除非刪除，否則緩存數(shù)據(jù)不會過期
使用 CacheStorage.open(cacheName) 打開一個 Cache 對象，再使用 Cache 對象的方法去處理緩存。
需要定期地清理緩存條目，因為每個瀏覽器都硬性限制了一個域下緩存數(shù)據(jù)的大小。

緩存配額使用估算值，可以使用 StorageEstimate API 獲得。

瀏覽器盡其所能去管理磁盤空間，但它有可能刪除一個域下的緩存數(shù)據(jù)。

瀏覽器要么自動刪除特定域的全部緩存，要么全部保留。

一些圍繞service worker緩存的重要 API 方法包括：

CacheStorage.open用于創(chuàng)建新的 Cache 實例。
Cache.add和Cache.put用于將「網(wǎng)絡(luò)響應(yīng)」存儲在service worker緩存中。
Cache.match用于查找 Cache 實例中的緩存響應(yīng)。
Cache.delete用于從 Cache 實例中刪除緩存響應(yīng)。
.....

Cache.put, Cache.add和Cache.addAll只能在GET請求下使用。

更多詳情可以參考MDN-Cache[1]

Cache API 與 HTTP 緩存的區(qū)別

如果我們以前沒有使用過Cache接口，可能會認為它與 HTTP 緩存相同，或者至少與 HTTP 緩存相關(guān)。但實際情況并非如此。

Cache接口是一個「完全獨立于」HTTP 緩存的緩存機制
用于影響HTTP緩存的任何Cache-Control配置對存儲在Cache接口中的資源沒有影響。

可以將瀏覽器緩存看作是「分層的」。

HTTP緩存是一個由「鍵-值對驅(qū)動」的「低級緩存」，其中的指令在HTTP Header中表示。
Cache接口是由「JavaScript API 驅(qū)動」的「高級緩存」。這比使用相對簡單的HTTP鍵-值對具有更大的靈活性。

2. Service Workers 能為我們帶來什么

Service workers是JavaScript層面的 API，「充當(dāng) Web 瀏覽器和 Web 服務(wù)器之間的代理」。它們的目標(biāo)是通過提供離線訪問以及提升頁面性能來提高可靠性。

漸進增強，類似應(yīng)用程序生命周期

Service workers是對現(xiàn)有網(wǎng)站的增強。這意味著如果使用Service workers的網(wǎng)站的用戶使用不支持Service workers的瀏覽器訪問網(wǎng)站，基本功能不會受到破壞。它是向下兼容的。

Service workers通過類似于桌面應(yīng)用程序的生命周期逐漸增強網(wǎng)站。想象一下當(dāng)從應(yīng)用商城安裝APP時會發(fā)生流程：

發(fā)出下載APP的請求。
APP下載并安裝。
APP準備好使用并可以啟動。
APP進行新版本的更新。

Service worker也采用類似的生命周期，但采用「漸進增強」的方法。

在首次訪問安裝了新Service worker的網(wǎng)頁時，初始訪問提供網(wǎng)站的基本功能，同時Service worker開始「下載」。
「安裝」和「激活」Service worker后，它將控制頁面以提供更高的可靠性和速度。

采用 JavaScript 驅(qū)動的 Cache API

Service worker技術(shù)中不可或缺的一部分是Cache API，這是一種「完全獨立于 HTTP 緩存的緩存機制」。Cache API可以在Service worker作用域內(nèi)和「主線程」作用域內(nèi)訪問。該特性為用戶操作與 Cache 實例的交互提供了許多可能性。

HTTP緩存是通過HTTP Header中指定的「緩存指令」來影響的
Cache API可以「通過 JavaScript 進行編程」

這意味著可以根據(jù)網(wǎng)站的特有的邏輯來緩存網(wǎng)絡(luò)請求的響應(yīng)。例如：

在「首次請求靜態(tài)資源時」將其存儲在緩存中，然后在「后續(xù)請求中從緩存中獲取」。
將頁面結(jié)構(gòu)存儲在緩存中，但在「離線情況下」從緩存中獲取。
對于一些「非緊急的資源」，先從緩存中獲取，然后在后臺中通過網(wǎng)絡(luò)再更新它。下次再獲取該資源時候，就認為是最新的
網(wǎng)絡(luò)采用「流式傳輸」處理部分內(nèi)容，并與緩存中的應(yīng)用程序攔截層組合以改善感知性能。

這些都是緩存策略的應(yīng)用方向。緩存策略使離線體驗成為可能，并「通過繞過 HTTP 緩存觸發(fā)的高延遲重新驗證檢查提供更好的性能」。

異步和事件驅(qū)動的 API

在「網(wǎng)絡(luò)上傳輸數(shù)據(jù)本質(zhì)上是異步的」。請求資產(chǎn)、服務(wù)器響應(yīng)請求以及下載響應(yīng)都需要時間。所涉及的時間是多樣且不確定的。Service workers通過「事件驅(qū)動」的 API 來適應(yīng)這種異步性，「使用回調(diào)處理事件」，例如：

當(dāng)Service worker正在「安裝」時。
當(dāng)Service worker正在「激活」時。
當(dāng)Service worker檢測到網(wǎng)絡(luò)請求時。

都可以使用addEventListener API 注冊事件。所有這些事件都可以與Cache API進行交互。特別是在網(wǎng)絡(luò)請求是離散的，運行回調(diào)的能力對于「提供所期望的可靠性和速度」至關(guān)重要。

在JavaScript中進行異步工作涉及使用Promises。因為Promises也支持async和await，這些JavaScript特性也可用于簡化Service worker代碼，從而提供更好的開發(fā)者體驗。

預(yù)緩存和運行時緩存

Service worker與Cache實例之間的交互涉及兩個不同的緩存概念：

「預(yù)緩存」(Precaching caching)
「運行時緩存」(Runtime caching)

預(yù)緩存是需要提前緩存資源的過程，通常在Service worker「安裝期間」進行。通過預(yù)緩存，「關(guān)鍵的靜態(tài)資產(chǎn)和離線訪問所需的材料可以被下載并存儲在 Cache 實例中」。這種類型的緩存還可以提高需要預(yù)緩存資源的后續(xù)頁面的頁面速度。

運行時緩存是指在運行時從網(wǎng)絡(luò)請求資源時應(yīng)用緩存策略。這種類型的緩存非常有用，因為它保證了用戶已經(jīng)訪問過的頁面和資源的離線訪問。

當(dāng)在Service worker中使用這些方法時，可以為用戶體驗提供巨大的好處，并為普通的網(wǎng)頁提供類似應(yīng)用程序的行為。

與主線程隔離

Service workers與Web workers類似，它們的「所有工作都在自己的線程上進行」。這意味著Service workers的任務(wù)不會與主線程上的其他任務(wù)競爭。

我們就以Web Worker為例子，做一個簡單的演示在JavaScript中創(chuàng)建Web Worker并不是一項復(fù)雜的任務(wù)。

創(chuàng)建一個新的JavaScript文件，其中包含我們希望在工作線程中運行的代碼。此文件不應(yīng)包含對DOM的任何引用，因為它將無法訪問DOM。

在我們的主JavaScript文件中，使用Worker構(gòu)造函數(shù)創(chuàng)建一個新的Worker對象。此構(gòu)造函數(shù)接受一個參數(shù)，即我們在第1步中創(chuàng)建的JavaScript文件的URL。

const worker = new Worker('worker.js');

為Worker對象添加事件偵聽器，以處理主線程和工作線程之間發(fā)送的消息。onmessage事件處理程序用于處理從工作線程發(fā)送的消息，而postMessage方法用于向工作線程發(fā)送消息。

worker.onmessage = function(event) {
  console.log('Worker said: ' + event.data);
};
worker.postMessage('Hello, worker!');

在我們的工作線程JavaScript文件中，添加一個事件偵聽器，以處理從主線程發(fā)送的消息，使用self對象的onmessage屬性。我們可以使用event.data屬性訪問消息中發(fā)送的數(shù)據(jù)。

self.onmessage = function(event) {
  console.log('Main thread said: ' + event.data);
  self.postMessage('Hello, main thread!');
};

現(xiàn)在讓我們運行Web應(yīng)用程序并測試Worker。我們應(yīng)該在控制臺中看到打印的消息，指示主線程和工作線程之間已發(fā)送和接收消息。

圖片

3. Service worker 的生命周期

定義術(shù)語

在深入了解service worker的生命周期之前，我們先來了解一下與生命周期運作相關(guān)的「術(shù)語」（黑話）

控制和作用域

了解service worker運作方式的關(guān)鍵在于理解「控制」（control）。

由service worker控制的頁面允許service worker代表該頁面進行攔截網(wǎng)絡(luò)請求。
在給定的「作用域」（scope）內(nèi)，service worker能夠為頁面執(zhí)行處理資源的相關(guān)工作。

作用域

一個service worker的作用域由其「在 Web 服務(wù)器上的位置確定」。如果一個service worker在位于/A/index.html的頁面上運行，并且位于/A/sw.js上，那么該service worker的作用域就是/A/。

打開https://service-worker-scope-viewer.glitch.me/subdir/index.html。將顯示一條消息，說明沒有service worker正在「控制」該頁面。但是，該頁面從https://service-worker-scope-viewer.glitch.me/subdir/sw.js注冊了一個service worker。
「重新加載頁面」。因為service worker「已經(jīng)注冊并處于活動狀態(tài)」，它正在「控制」頁面。將顯示一個包含service worker作用域、當(dāng)前狀態(tài)和其 URL 的表單。
現(xiàn)在打開https://service-worker-scope-viewer.glitch.me/index.html。盡管在此origin上注冊了一個service worker，但仍然會顯示一條消息，說明沒有當(dāng)前的service worker。這是因為此頁面不在已注冊service worker的作用域內(nèi)。

作用域限制了service worker控制的頁面。在上面的例子中，這意味著從/subdir/sw.js加載的service worker只能「控制位于/subdir/或其子頁面中」。

控制頁面的service worker仍然可以「攔截任何網(wǎng)絡(luò)請求」，包括跨域資源的請求。作用域限制了由service worker控制的頁面。

上述是默認情況下作用域工作的方式，但可以通過設(shè)置Service-Worker-Allowed響應(yīng)頭，以及通過向register方法傳遞作用域選項來進行覆蓋。

除非有很好的理由將service worker的作用域限制為origin的子集，否則應(yīng)「從 Web 服務(wù)器的根目錄加載service worker，以便其作用域盡可能廣泛」，不必擔(dān)心Service-Worker-Allowed頭部。

客戶端

當(dāng)說一個service worker正在控制一個頁面時，實際上「是在控制一個客戶端」?？蛻舳耸侵窾RL位于該service worker作用域內(nèi)的「任何打開的頁面」。具體來說，這些是WindowClient的實例。

圖片

3.1 Service worker 在初始化時的生命周期

為了使service worker能夠控制頁面，首先必須將其部署。

讓我們看看一個沒有service worker的網(wǎng)站到部署全新service worker時，中間發(fā)生了啥？

1. 注冊(Registration)

注冊是service worker生命周期的「初始步驟」：

此代碼在「主線程」上運行，并執(zhí)行以下操作：

因為用戶「首次訪問網(wǎng)站時」沒有注冊service worker，所以等待「頁面完全加載后」再注冊一個。這樣可以避免在service worker預(yù)緩存任何內(nèi)容時出現(xiàn)「帶寬爭用」。
盡管service worker得到了廣泛支持，但進行「特性檢查」可以避免在不支持它的瀏覽器中出現(xiàn)錯誤。
當(dāng)頁面完全加載后，如果支持service worker，則注冊/sw.js。

還有一些關(guān)鍵要點：

Service worker僅在HTTPS或localhost上可用。
如果service worker的內(nèi)容包含「語法錯誤」，注冊會失敗，并丟棄service worker。
service worker在一個作用域內(nèi)運行。在這里，作用域是整個origin，因為它是從根目錄加載的。
當(dāng)注冊開始時，service worker的狀態(tài)被設(shè)置為installing。

一旦注冊完成，「安裝」就開始了。

2. 安裝(Installation)

service worker在注冊后觸發(fā)其install事件。install「只會在每個service worker中調(diào)用一次，直到它被更新才會再次觸發(fā)」?？梢允褂胊ddEventListener在worker的作用域內(nèi)注冊install事件的回調(diào)：

// /sw.js
self.addEventListener("install", (event) => {
  const cacheKey = "前端柒八九_v1";

  event.waitUntil(
    caches.open(cacheKey).then((cache) => {
      // 將數(shù)組中的所有資產(chǎn)添加到'前端柒八九_v1'的`Cache`實例中以供以后使用。
      return cache.addAll([
        "/css/global.bc7b80b7.css",
        "/css/home.fe5d0b23.css",
        "/js/home.d3cc4ba4.js",
        "/js/A.43ca4933.js",
      ]);
    })
  );
});

這會創(chuàng)建一個新的Cache實例并對資產(chǎn)進行「預(yù)緩存」。其中有一個event.waitUntil。event.waitUntil接受一個Promise，并等待該Promise被解決。

在這個示例中，這個Promise執(zhí)行兩個異步操作：

創(chuàng)建一個名為前端柒八九_v1的新Cache實例。
在創(chuàng)建緩存之后，使用其異步的addAll方法「預(yù)緩存」一個資源URL數(shù)組。

如果傳遞給event.waitUntil的Promise被「拒絕，安裝將失敗」。如果發(fā)生這種情況，service worker將被「丟棄」。

如果Promise被解決，安裝成功，service worker的狀態(tài)將更改為installed，然后進入「激活」階段。

3. 激活(Activation)

如果注冊和安裝成功，service worker將被「激活」，其狀態(tài)將變?yōu)閍ctivating。在service worker的activate事件中可以進行激活期間的工作。在此事件中的一個典型任務(wù)是「清理舊緩存」，但對于「全新 service worker」，目前還不相關(guān)。

對于新的service worker，「安裝成功后，激活會立即觸發(fā)」。一旦激活完成，service worker的狀態(tài)將變?yōu)閍ctivated。

默認情況下，新的service worker直到「下一次導(dǎo)航或頁面刷新之前才會開始控制頁面」。

3.2 處理 service worker 的更新

一旦部署了第一個service worker，它很可能需要在以后進行更新。例如，如果請求處理或預(yù)緩存邏輯發(fā)生了變化，就可能需要進行更新。

更新發(fā)生的時機

瀏覽器會在以下情況下檢查service worker的更新：

用戶導(dǎo)航到service worker作用域內(nèi)的頁面。
調(diào)用navigator.serviceWorker.register()并「傳入與當(dāng)前安裝的 service worker 不同的 URL」
調(diào)用navigator.serviceWorker.register()并「傳入與已安裝的 service worker 相同的 URL」，但具有「不同的作用域」。

更新的方式

了解瀏覽器何時更新service worker很重要，但“如何”也很重要。假設(shè)service worker的URL或作用域未更改，「只有在其內(nèi)容發(fā)生變化時，當(dāng)前安裝的service worker才會更新到新版本」。

瀏覽器以幾種方式檢測變化：

importScripts請求的腳本的「字節(jié)級更改」。
service worker的「頂級代碼的任何更改」，這會影響瀏覽器生成的指紋。

為確保瀏覽器能夠可靠地檢測service worker內(nèi)容的變化，「不要使用 HTTP 緩存保留它，也不要更改其文件名」。當(dāng)導(dǎo)航到service worker作用域內(nèi)的新頁面時，瀏覽器會自動執(zhí)行更新檢查。

手動觸發(fā)更新檢查

關(guān)于更新，注冊邏輯通常不應(yīng)更改。然而，一個例外情況可能是「網(wǎng)站上的會話持續(xù)時間很長」。這可能在「單頁應(yīng)用程序」中發(fā)生，因為導(dǎo)航請求通常很少，應(yīng)用程序通常在應(yīng)用程序生命周期的開始遇到一個導(dǎo)航請求。在這種情況下，可以在「主線程上手動觸發(fā)更新」：

navigator.serviceWorker.ready.then((registration) => {
  registration.update();
});

對于傳統(tǒng)的網(wǎng)站，或者在用戶會話不持續(xù)很長時間的任何情況下，手動更新可能不是必要的。

安裝(Installation)

當(dāng)使用打包工具生成「靜態(tài)資源」時，這些資源的「名稱中會包含哈希值」，例如framework.3defa9d2.js。假設(shè)其中一些資源被預(yù)緩存以供以后離線訪問，這將需要對service worker進行更新以預(yù)緩存新的資源：

self.addEventListener("install", (event) => {
  const cacheKey = "前端柒八九_v2";

  event.waitUntil(
    caches.open(cacheKey).then((cache) => {
      // 將數(shù)組中的所有資產(chǎn)添加到'前端柒八九_v2'的`Cache`實例中以供以后使用。
      return cache.addAll([
        "/css/global.ced4aef2.css",
        "/css/home.cbe409ad.css",
        "/js/home.109defa4.js",
        "/js/A.38caf32d.js",
      ]);
    })
  );
});

與之前的install事件示例有兩個方面不同：

創(chuàng)建了一個具有 key 為前端柒八九_v2的「新 Cache 實例」。
預(yù)緩存資源的名稱已更改。(/css/global.bc7b80b7.css變?yōu)?css/global.ced4aef2.css)

更新后的service worker會與先前的service worker并存。這意味著舊的service worker仍然控制著任何打開的頁面。剛才安裝的新的service worker進入等待狀態(tài)，直到被激活。

默認情況下，新的service worker將在「沒有任何客戶端由舊的service worker控制時激活」。這發(fā)生在相關(guān)網(wǎng)站的所有打開標(biāo)簽都關(guān)閉時。

激活(Activation)

當(dāng)安裝了新的service worker并結(jié)束了等待階段時，它會被激活，并丟棄舊的service worker。在更新后的service worker的activate事件中執(zhí)行的常見任務(wù)是「清理舊緩存」。通過使用caches.keys獲取所有打開的 Cache 實例的key，并使用caches.delete刪除不在允許列表中的所有舊緩存：

self.addEventListener("activate", (event) => {
  // 指定允許的緩存密鑰
  const cacheAllowList = ["前端柒八九_v2"];

  // 獲取當(dāng)前活動的所有`Cache`實例。
  event.waitUntil(
    caches.keys().then((keys) => {
      // 刪除不在允許列表中的所有緩存：
      return Promise.all(
        keys.map((key) => {
          if (!cacheAllowList.includes(key)) {
            return caches.delete(key);
          }
        })
      );
    })
  );
});

舊的緩存不會自動清理。我們需要自己來做，否則可能會超過存儲配額。

由于第一個service worker中的前端柒八九_v1已經(jīng)過時，緩存允許列表已更新為指定前端柒八九_v2，這將刪除具有不同名稱的緩存。

「激活事件在舊緩存被刪除后完成」。此時，新的service worker將控制頁面，最終替代舊的service worker！

4. Service worker 緩存策略

要有效使用service worker，有必要采用一個或多個緩存策略，這需要對Cache API有一定的了解。

緩存策略是service worker的fetch事件與Cache API之間的交互。如何編寫緩存策略取決于不同情況。

普通的 Fetch 事件

緩存策略的另一個重要的用途就是與service worker的fetch事件配合使用。我們已經(jīng)聽說過一些關(guān)于「攔截網(wǎng)絡(luò)請求」的內(nèi)容，而service worker內(nèi)部的fetch事件就是處理這種情況的：

// 建立緩存名稱
const cacheName = "前端柒八九_v1";

self.addEventListener("install", (event) => {
  event.waitUntil(caches.open(cacheName));
});

self.addEventListener("fetch", async (event) => {
  // 這是一個圖片請求
  if (event.request.destination === "image") {
    // 打開緩存
    event.respondWith(
      caches.open(cacheName).then((cache) => {
        // 從緩存中響應(yīng)圖片，如果緩存中沒有，就從網(wǎng)絡(luò)獲取圖片
        return cache.match(event.request).then((cachedResponse) => {
          return (
            cachedResponse ||
            fetch(event.request.url).then((fetchedResponse) => {
              // 將網(wǎng)絡(luò)響應(yīng)添加到緩存以供將來訪問。
              // 注意：我們需要復(fù)制響應(yīng)以保存在緩存中，同時使用原始響應(yīng)作為請求的響應(yīng)。
              cache.put(event.request, fetchedResponse.clone());

              // 返回網(wǎng)絡(luò)響應(yīng)
              return fetchedResponse;
            })
          );
        });
      })
    );
  } else {
    return;
  }
});

上面的代碼執(zhí)行以下操作：

檢查請求的destination屬性，以查看是否是圖像請求。
如果圖像在service worker緩存中，則從緩存中提供它。如果沒有，從網(wǎng)絡(luò)獲取圖像，將響應(yīng)存儲在緩存中，并返回網(wǎng)絡(luò)響應(yīng)。
所有其他請求都會通過service worker，不與緩存互動。

fetch事件的事件對象包含一個request屬性，其中包含一些有用的信息，可幫助我們識別每個請求的類型：

url，表示當(dāng)前由 fetch 事件處理的網(wǎng)絡(luò)請求的 URL。
method，表示請求方法（例如GET或POST）。
mode，描述請求的模式。通常使用值navigate來區(qū)分對 HTML 文檔的請求與其他請求。
destination，以一種避免使用所請求資產(chǎn)的文件擴展名的方式描述所請求內(nèi)容的類型。

「異步操作是關(guān)鍵」。我們還記得install事件提供了一個event.waitUntil方法，它接受一個promise，并在激活之前等待其解析。fetch事件提供了類似的event.respondWith方法，我們可以使用它來返回異步fetch請求的結(jié)果或Cache接口的match方法返回的響應(yīng)。

緩存策略

1. 僅緩存(Cache only)

展示了從頁面到service worker到緩存的流程。

「僅緩存」運作方式：當(dāng)service worker控制頁面時，「匹配的請求只會進入緩存」。這意味著為了使該模式有效，「任何緩存的資源都需要在安裝時進行預(yù)緩存」，而「這些資源在service worker更新之前將不會在緩存中進行更新」。

// 建立緩存名稱
const cacheName = "前端柒八九_v1";

// 要預(yù)緩存的資產(chǎn)
const preCachedAssets = ["/A.jpg", "/B.jpg", "/C.jpg", "/D.jpg"];

self.addEventListener("install", (event) => {
  // 在安裝時預(yù)緩存資產(chǎn)
  event.waitUntil(
    caches.open(cacheName).then((cache) => {
      return cache.addAll(preCachedAssets);
    })
  );
});

self.addEventListener("fetch", (event) => {
  const url = new URL(event.request.url);
  const isPrecachedRequest = preCachedAssets.includes(url.pathname);

  if (isPrecachedRequest) {
    // 從緩存中獲取預(yù)緩存的資產(chǎn)
    event.respondWith(
      caches.open(cacheName).then((cache) => {
        return cache.match(event.request.url);
      })
    );
  } else {
    // 轉(zhuǎn)到網(wǎng)絡(luò)
    return;
  }
});

在上面的示例中，數(shù)組中的資產(chǎn)在安裝時被預(yù)緩存。當(dāng)service worker處理fetch請求時，我們「檢查fetch事件處理的請求 URL 是否在預(yù)緩存資產(chǎn)的數(shù)組中」。

如果是，我們從緩存中獲取資源，并跳過網(wǎng)絡(luò)。
其他請求將通過網(wǎng)絡(luò)傳遞，只經(jīng)過網(wǎng)絡(luò)。

2. 僅網(wǎng)絡(luò)(Network only)

圖片

「僅網(wǎng)絡(luò)」的策略與「僅緩存」相反，它將請求通過service worker傳遞到網(wǎng)絡(luò)，而「不與 service worker 緩存進行任何交互」。這是一種「確保內(nèi)容新鮮度」的好策略，但其權(quán)衡是「當(dāng)用戶離線時將無法正常工作」。

要確保請求直接通過到網(wǎng)絡(luò)，只需「不對匹配的請求調(diào)用 event.respondWith」。如果我們想更明確，可以在要傳遞到網(wǎng)絡(luò)的請求的fetch事件回調(diào)中加入一個空的return;。這就是「僅緩存」策略演示中對于未經(jīng)預(yù)緩存的請求所發(fā)生的情況。

3. 緩存優(yōu)先，備用網(wǎng)絡(luò)(Cache first, falling back to network)

圖片

對于「匹配的請求」，流程如下：

請求到達緩存。如果資產(chǎn)在緩存中，就從緩存中提供。
如果請求不在緩存中，去訪問網(wǎng)絡(luò)。
一旦網(wǎng)絡(luò)請求完成，將其添加到緩存，然后返回網(wǎng)絡(luò)響應(yīng)。

// 建立緩存名稱
const cacheName = "前端柒八九_v1";

self.addEventListener("fetch", (event) => {
  // 檢查這是否是一個圖像請求
  if (event.request.destination === "image") {
    event.respondWith(
      caches.open(cacheName).then((cache) => {
        // 首先從緩存中獲取
        return cache.match(event.request.url).then((cachedResponse) => {
          // 如果我們有緩存的響應(yīng)，則返回緩存的響應(yīng)
          if (cachedResponse) {
            return cachedResponse;
          }

          // 否則，訪問網(wǎng)絡(luò)
          return fetch(event.request).then((fetchedResponse) => {
            // 將網(wǎng)絡(luò)響應(yīng)添加到緩存以供以后訪問
            cache.put(event.request, fetchedResponse.clone());

            // 返回網(wǎng)絡(luò)響應(yīng)
            return fetchedResponse;
          });
        });
      })
    );
  } else {
    return;
  }
});

盡管這個示例只涵蓋了圖像，但這是一個很好的范例，「適用于所有靜態(tài)資產(chǎn)」（如CSS、JavaScript、圖像和字體），「尤其是哈希版本的資產(chǎn)」。它「通過跳過 HTTP 緩存可能啟動的任何與服務(wù)器的內(nèi)容新鮮度檢查，為不可變資產(chǎn)提供了速度提升」。更重要的是，「任何緩存的資產(chǎn)都將在離線時可用」。

4. 網(wǎng)絡(luò)優(yōu)先，備用緩存(Network first, falling back to cache)

它的含義就是：

首先通過網(wǎng)絡(luò)請求資源，然后將響應(yīng)放入緩存。
如果以后「離線了，就回退到緩存中的最新版本的響應(yīng)」。

這種策略對于HTML或 API 請求非常有用，當(dāng)在線時，我們希望獲取資源的最新版本，但希望在離線時能夠訪問最新可用的版本。

// 建立緩存名稱
const cacheName = "前端柒八九_v1";

self.addEventListener("fetch", (event) => {
  // 檢查這是否是導(dǎo)航請求
  if (event.request.mode === "navigate") {
    // 打開緩存
    event.respondWith(
      caches.open(cacheName).then((cache) => {
        // 首先通過網(wǎng)絡(luò)請求
        return fetch(event.request.url)
          .then((fetchedResponse) => {
            cache.put(event.request, fetchedResponse.clone());

            return fetchedResponse;
          })
          .catch(() => {
            // 如果網(wǎng)絡(luò)不可用，從緩存中獲取
            return cache.match(event.request.url);
          });
      })
    );
  } else {
    return;
  }
});

首先，訪問頁面?？赡苄枰趯?nbsp;HTML 響應(yīng)放入緩存之前重新加載。
然后在開發(fā)者工具中，模擬離線連接，然后重新加載。
最后一個可用版本將立即從緩存中提供。

在需要重視離線功能，但又需要平衡該功能與獲取一些標(biāo)記或 API 數(shù)據(jù)的最新版本的情況下，「網(wǎng)絡(luò)優(yōu)先，備用緩存」是一種實現(xiàn)這一目標(biāo)的可靠策略。

5. 陳舊時重新驗（Stale-while-revalidate)

圖片

「陳舊時重新驗證」策略是其中最復(fù)雜的。該策略的過程「優(yōu)先考慮了資源的訪問速度」，同時在后臺保持其更新。該策略的工作流程如下：

對于首次請求的資源，從網(wǎng)絡(luò)獲取，將其放入緩存，并返回網(wǎng)絡(luò)響應(yīng)。
對于后續(xù)請求，首先從緩存中提供資源，然后在后臺重新從網(wǎng)絡(luò)請求并更新資源的緩存條目。
對于以后的請求，我們將收到從網(wǎng)絡(luò)獲取并在前一步放入緩存的最新版本。

這是一個適用于「需要保持更新但不是絕對必要的資源」的策略，比如網(wǎng)站的頭像。它們會在用戶愿意更新時進行更新，但不一定需要在每次請求時獲取最新版本。

// 建立緩存名稱
const cacheName = "前端柒八九_v1";

self.addEventListener("fetch", (event) => {
  if (event.request.destination === "image") {
    event.respondWith(
      caches.open(cacheName).then((cache) => {
        return cache.match(event.request).then((cachedResponse) => {
          const fetchedResponse = fetch(event.request).then(
            (networkResponse) => {
              cache.put(event.request, networkResponse.clone());

              return networkResponse;
            }
          );

          return cachedResponse || fetchedResponse;
        });
      })
    );
  } else {
    return;
  }
});

5. Service Worker 預(yù)緩存的陷阱

如果將預(yù)緩存「應(yīng)用于太多的資產(chǎn)」，或者如果Service Worker在頁面「完成加載關(guān)鍵資產(chǎn)之前」就注冊了，那么可能會遇到問題。

當(dāng)Service Worker在「安裝期間預(yù)緩存資產(chǎn)時，將同時發(fā)起一個或多個網(wǎng)絡(luò)請求」。如果時機不合適，這可能會對用戶體驗產(chǎn)生問題。即使時機剛剛好，如果未對預(yù)緩存資產(chǎn)的「數(shù)量進行限制」，仍可能會浪費數(shù)據(jù)。

一切都取決于時機

如果Service Worker預(yù)緩存任何內(nèi)容，那么它的注冊時機很重要。Service Worker通常使用內(nèi)聯(lián)的