a在线观看欧美,亚洲国产精品自在自线

新聞中心

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

WorkBox之底層邏輯ServiceWorker

1. 前置知識(shí)點(diǎn)

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

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

如何查看Service Worker

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

圖片

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

Cache API

Cache API為緩存的 Request / Response 對(duì)象對(duì)提供存儲(chǔ)機(jī)制。例如，作為ServiceWorker 生命周期的一部分

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

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

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

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

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

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

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

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

Cache.put, Cache.add和Cache.addAll只能在GET請(qǐng)求下使用。

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

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

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

Cache接口是一個(gè)「完全獨(dú)立于」HTTP 緩存的緩存機(jī)制
用于影響HTTP緩存的任何Cache-Control配置對(duì)存儲(chǔ)在Cache接口中的資源沒有影響。

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

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

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

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

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

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

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

發(fā)出下載APP的請(qǐng)求。
APP下載并安裝。
APP準(zhǔn)備好使用并可以啟動(dòng)。
APP進(jìn)行新版本的更新。

Service worker也采用類似的生命周期，但采用「漸進(jìn)增強(qiáng)」的方法。

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

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

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

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

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

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

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

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

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

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

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

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

預(yù)緩存和運(yùn)行時(shí)緩存

Service worker與Cache實(shí)例之間的交互涉及兩個(gè)不同的緩存概念：

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

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

運(yùn)行時(shí)緩存是指在運(yùn)行時(shí)從網(wǎng)絡(luò)請(qǐng)求資源時(shí)應(yīng)用緩存策略。這種類型的緩存非常有用，因?yàn)樗ＷC了用戶已經(jīng)訪問過的頁(yè)面和資源的離線訪問。

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

與主線程隔離

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

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

創(chuàng)建一個(gè)新的JavaScript文件，其中包含我們希望在工作線程中運(yùn)行的代碼。此文件不應(yīng)包含對(duì)DOM的任何引用，因?yàn)樗鼘o法訪問DOM。

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

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

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

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

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

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

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

圖片

3. Service worker 的生命周期

定義術(shù)語(yǔ)

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

控制和作用域

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

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

作用域

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

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

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

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

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

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

客戶端

當(dāng)說一個(gè)service worker正在控制一個(gè)頁(yè)面時(shí)，實(shí)際上「是在控制一個(gè)客戶端」。客戶端是指URL位于該service worker作用域內(nèi)的「任何打開的頁(yè)面」。具體來說，這些是WindowClient的實(shí)例。

圖片

3.1 Service worker 在初始化時(shí)的生命周期

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

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

1. 注冊(cè)(Registration)

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

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

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

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

Service worker僅在HTTPS或localhost上可用。
如果service worker的內(nèi)容包含「語(yǔ)法錯(cuò)誤」，注冊(cè)會(huì)失敗，并丟棄service worker。
service worker在一個(gè)作用域內(nèi)運(yùn)行。在這里，作用域是整個(gè)origin，因?yàn)樗菑母夸浖虞d的。
當(dāng)注冊(cè)開始時(shí)，service worker的狀態(tài)被設(shè)置為installing。

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

2. 安裝(Installation)

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

// /sw.js
self.addEventListener("install", (event) => {
  const cacheKey = "前端柒八九_(tái)v1";

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

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

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

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

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

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

3. 激活(Activation)

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

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

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

3.2 處理 service worker 的更新

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

更新發(fā)生的時(shí)機(jī)

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

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

更新的方式

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

瀏覽器以幾種方式檢測(cè)變化：

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

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

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

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

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

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

安裝(Installation)

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

self.addEventListener("install", (event) => {
  const cacheKey = "前端柒八九_(tái)v2";

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

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

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

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

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

激活(Activation)

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

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

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

舊的緩存不會(huì)自動(dòng)清理。我們需要自己來做，否則可能會(huì)超過存儲(chǔ)配額。

由于第一個(gè)service worker中的前端柒八九_(tái)v1已經(jīng)過時(shí)，緩存允許列表已更新為指定前端柒八九_(tái)v2，這將刪除具有不同名稱的緩存。

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

4. Service worker 緩存策略

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

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

普通的 Fetch 事件

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

// 建立緩存名稱
const cacheName = "前端柒八九_(tái)v1";

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

self.addEventListener("fetch", async (event) => {
  // 這是一個(gè)圖片請(qǐng)求
  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)以保存在緩存中，同時(shí)使用原始響應(yīng)作為請(qǐng)求的響應(yīng)。
              cache.put(event.request, fetchedResponse.clone());

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

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

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

fetch事件的事件對(duì)象包含一個(gè)request屬性，其中包含一些有用的信息，可幫助我們識(shí)別每個(gè)請(qǐng)求的類型：

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

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

緩存策略

1. 僅緩存(Cache only)

展示了從頁(yè)面到service worker到緩存的流程。

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

// 建立緩存名稱
const cacheName = "前端柒八九_(tái)v1";

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

self.addEventListener("install", (event) => {
  // 在安裝時(shí)預(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)在安裝時(shí)被預(yù)緩存。當(dāng)service worker處理fetch請(qǐng)求時(shí)，我們「檢查fetch事件處理的請(qǐng)求 URL 是否在預(yù)緩存資產(chǎn)的數(shù)組中」。

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

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

圖片

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

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

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

圖片

對(duì)于「匹配的請(qǐng)求」，流程如下：

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

// 建立緩存名稱
const cacheName = "前端柒八九_(tái)v1";

self.addEventListener("fetch", (event) => {
  // 檢查這是否是一個(gè)圖像請(qǐng)求
  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;
  }
});

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

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

它的含義就是：

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

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

// 建立緩存名稱
const cacheName = "前端柒八九_(tái)v1";

self.addEventListener("fetch", (event) => {
  // 檢查這是否是導(dǎo)航請(qǐng)求
  if (event.request.mode === "navigate") {
    // 打開緩存
    event.respondWith(
      caches.open(cacheName).then((cache) => {
        // 首先通過網(wǎng)絡(luò)請(qǐng)求
        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;
  }
});

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

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

5. 陳舊時(shí)重新驗(yàn)（Stale-while-revalidate)

圖片

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

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

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

// 建立緩存名稱
const cacheName = "前端柒八九_(tái)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在頁(yè)面「完成加載關(guān)鍵資產(chǎn)之前」就注冊(cè)了，那么可能會(huì)遇到問題。

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

一切都取決于時(shí)機(jī)

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