摘要：最后用把緩存的路徑憑證信息存在中。緩存策略現在來看看提供的緩存策略，主要有這幾種。自定義緩存配置回到在緩存策略里提到的，講講和緩存策略的參數。

作者：陳達孚
香港中文大學研究生,《移動Web前端高效開發實戰》作者之一，《前端開發者指南2017》譯者之一，在中國前端開發者大會,中生代技術大會等技術會議發表過主題演講, 專注于新技術的調研和使用.
本文為原創文章，轉載請注明作者及出處

本文主要分析通過workbox(基于1.x和2.x版本，未來3.x版本會有新的結構)生成Service-Worker的緩存策略，workbox是GoogleChrome團隊對原來sw-precache和sw-toolbox的封裝，并且提供了Webpack和Gulp插件方便開發者快速生成sw.js文件。

首先看一下 workbox 提供的 Webpack 插件 workboxPlugin 的三個最主要參數：

globDirectory

staticFileGlobs

swDest

其中 globDirectory 和 staticFileGlobs 會決定需要緩存的靜態文件，這兩個參數也存在默認值，插件會從compilation參數中獲取開發者在 Webpack 配置的 output.path 作為 globDirectory 的默認值，staticFileGlobs 的默認配置是 html，js，css 文件，如果需要緩存一些界面必須的圖片，這個地方需要自己配置。

之后 Webpack 插件會將配置作為參數傳遞給 workbox-build 模塊，workbox-build 模塊中會根據 globDirectory 和 staticFileGlobs 讀取文件生成一份配置信息，交給 precache 處理。需要注意的是，precache里不要存太多的文件，workbox-build 對文件會有一個過濾， 該模塊會讀取利用 node 的 fs 模塊讀取文件，如果文件大于2M則不會加入配置中（可以通過配置 maximumFileSize 修改），同時會根據文件的 buffer 生成一個 hash 值，也就是說就算開發者不改變文件名，只要文件內容修改了，也會生成一個新的配置內容，讓瀏覽器更新緩存。

那么說了那么多，precache 到底干了什么，看一下生成的sw文件：

const fileManifest = [
  {
    "url": "main.js",
    "revision": "0e438282dc400829497725a6931f66e3"
  },
  {
    "url": "main.css",
    "revision": "02ba19bb320adb687e08dded3e71408d"
  }
];

const workboxSW = new self.WorkboxSW();
workboxSW.precache(fileManifest);

那還是需要看一下 precache 的代碼:

precache(revisionedFiles) {
  this._revisionedCacheManager.addToCacheList({
    revisionedFiles,
  })
}

是的，workbox會提供一個對象 revisionedCacheManager 來管理所有的緩存，先不管里面具體怎么處理的，往下看有個 registerInstallActivateEvents。

_registerInstallActivateEvents(skipWating, clientsClaim) {
  self.addEventListener("install", (event) => {
    const cachedUrls = this._revisionedCacheManager.getCachedUrls();
    event.waitUntil(
      this._revisionedCacheManager.install().then(() => {
        if (skipWaiting) {
          return self.skipWaiting();
        }
      })
    )
}

這里可以看出，所有的 precache 都會在 service worker 的 install 事件中完成。event.waitUntil 會根據內部promise的結果來確定安裝是否完成。如果安裝失敗，則會舍棄這個ServiceWorker。

現在看一下 _revisionedCacheManager.install 里干了什么，首先 revisionedFiles 會被放在一個 Map 中，當然這個 revisionedFiles 是已經被處理過了， 在經過 addToCacheList -> _addEntries -> _parseEntry 的過程后，會返回：

{
  entryID,
  revision,
  request: new Request(url),
  cacheBust
}

entryID 不主動傳入可以視為用戶傳入的url，將用來作為IndexDB中的key存儲revision，而request則用來提供給之后的fetch請求，cacheBust默認為true，功能等會再分析。

Map 的set 過程在 _addEntries 的 _addEntryToInstallList 函數中，這里只需注意因為 fileManifest 中不能存放具有相同 url （或者說entryID）的值，不然會被警告。

現在回來看install，install是一個async函數，返回一個包含一系列Promise請求的Promise.all，符合waitUntil的要求。每一個需要緩存的文件會到 cacheEntry 函數中處理：

async _cacheEntry(precacheEntry) {
  const isCached = await this._isAlreadyCached(precacheEntry);
  const precacheDetails = {
    url: precacheEntry.request.url,
    revision: precacheEntry.revision,
    wasUpdated: !isCached,
  };
  if (isCached) {
    return precacheDetails;
  }

  try {
    await this._requestWrapper.fetchAndCache({
      request: precacheEntry.getNetworkRequest(),
      waitOnCache: true,
      cacheKey: precacheEntry.request,
      cleanRedirects: true,
    });

    await this._onEntryCached(precacheEntry);
    return precacheDetails;
  } catch (err) {
    throw new WorkboxError("request-not-cached", {
      url: precacheEntry.request.url,
      error: err,
    });
  }
}

對于每一個請求會去通過 _isAlreadyCached 方法訪問indexDB 得知是否被緩存過。這里可能有讀者會疑惑，我們不是不能在 fileManifest 中不允許存儲同樣的url，為什么還要查是否緩存過，這是因為當你sw文件更新后，原來的緩存還是存在的，它們或許持有相同的url，如果它們的revision也相同，就不用獲取了。

在 _cacheEntry 內部，還有兩個異步操作，一個是通過包裝后的 requestWrapper 的 fetchAndCache 請求并緩存數據，一個是通過 _onEntryCached 方法更新indexDB，可以看到雖然catch了錯誤，但依舊會throw出來，意味著任何一個precache的文件請求失敗，都會終止此次install。

這里另一個需要注意的地方是 _requestWrapper.fetchAndCache，所有請求最后都會在 requestWrapper中處理，這里調用的實例方法是 fetchAndCache ，說明這次請求會涉及到網絡請求和緩存處理兩部分。在發出請求后，首先會判斷請求結果是否需要加入緩存中：

const effectiveCacheableResponsePlugin =
  this._userSpecifiedCachableResponsePlugin ||
  cacheResponsePlugin ||
  this.getDefaultCacheableResponsePlugin();

如果沒有插件配置，會使用 getDefaultCacheableResponsePlugin() 來取得默認配置，即緩存返回狀態為200的請求。

在上面的代碼中可以看到在 precache 環境下，會有兩個參數為 true, 一個是 waitOnCache，另一個是cleanRedirects。waitOnCache保證在需要緩存的情況下返回網絡結果時必須完成緩存的處理，cleanRedirects則會重新包裝一下請求重定向的結果。

最后用_onEntryCached把緩存的路徑憑證信息存在indexDB中。

在activate階段，會對precache在cache里的內容進行clean，因為前面只做了更新，如果是新的precache沒有的資源地址，在這里會刪除。

所以 precache 就是在 service-worker 的 install 事件下完成一次對配置資源的網絡請求，并在請求結果返回時完成對結果的緩存。

在了解 runtimecache 前，先看下 workbox-sw 的實例化過程中比較重要的部分：

this._runtimeCacheName = getDefaultCacheName({cacheId});
this._revisionedCacheManager = new RevisionedCacheManager({
  cacheId,
  plugins,
});
this._strategies = new Strategies({
  cacheId,
});

this._router = new Router(
  this._revisionedCacheManager.getCacheName(),
  handleFetch
);
this._registerInstallActivateEvents(skipWaiting, clientsClaim);
this._registerDefaultRoutes(ignoreUrlParametersMatching, directoryIndex);

所以看出 workbox-sw 實例化的過程主要有生成緩存對應空間名，緩存空間，掛載緩存策略，掛載路由方法（用于處理對應路徑的緩存策略），注冊安裝激活方法，注冊默認路由。

precache 對應的就是 runtimecache，runtimecache 顧名思義就是處理所有運行時的緩存，runtimecache 往往應對著各種類型的資源，對于不同類型的資源往往也有不同的緩存策略，所以在 workbox 中使用 runtimecache 需要調用方法，workbox.router.registerRoute 也是說明 runtimecache 需要路由層面的細致劃分。

看到最后一步的 _registerDefaultRoutes ，看一下其中的代碼，可以發現 workbox 有一個最基本的cache，這個 cache 其實處理的就是前面的 precache，這個 cache 遵從著 cacheFirst 原則：

const cacheFirstHandler = this.strategies.cacheFirst({
  cacheName: this._revisionedCacheManager.getCacheName(),
  plugins,
  excludeCacheId: true,
});

const capture = ({url}) => {
  url.hash = "";

  const cachedUrls = this._revisionedCacheManager.getCachedUrls();
  if (cachedUrls.indexOf(url.href) !== -1) {
    return true;
  }

  let strippedUrl =
    this._removeIgnoreUrlParams(url.href, ignoreUrlParametersMatching);
  if (cachedUrls.indexOf(strippedUrl.href) !== -1) {
    return true;
  }

  if (directoryIndex && strippedUrl.pathname.endsWith("/")) {
    strippedUrl.pathname += directoryIndex;
    return cachedUrls.indexOf(strippedUrl.href) !== -1;
  }

    return false;
  };

  this._precacheRouter.registerRoute(capture, cacheFirstHandler);

簡單的說，如果你一個路徑能直接在 precache 中可以找到，或者在去除了部分查詢參數后符合，或者去處部分查詢參數添加后綴后符合，就會直接返回緩存，至于請求過來怎么處理的，稍后再看。

我們可以這么認為 precache 就是添加了 cache，至于真實請求時如何處理還是和 runtimecache 在一個地方處理，現在看來，在 workbox 初始化的時候就有了第一個 router.registerRoute()，之后的就需要手動注冊了。

在寫自己注冊的策略之前，考慮下，注冊了 route 后，又怎么處理呢？在實例化 Router 的時候，我們就會添加一個 self.addEventListener("fetch", (event) => {...})，除非你手動傳入一個handleFetch參數為false。

在注冊路由的時候，registerRoute(capture, handler, method)在類中接受一個捕獲條件和一個句柄函數，這個捕獲條件可以是字符串，正則表達式或者是直接的Route對象，當然最終都會變成 Route 對象（分別通過 ExpressRoute 和 RegExpRoute），Route對象包含匹配，處理方法，和方法（默認為 GET）。然后在注冊時會使用一個 Map，以每個使用到的方法為 Key，值為包含所有Route對象的數組，在遍歷時也只會遍歷相應方法的值。所以你也可以給不同的方法定義同樣的捕獲路徑。

這里使用了 unshift 操作，所以每個新的配置會被壓入堆棧的頂部，在遍歷時則會被優先遍歷到。因為 workbox 實例化是在 registerRoute 之前，所以默認配置優先級最低，配置后面的注冊會優先于前面的。

所以最終在頁面上，你的每次請求都會被監聽，到相應的請求方法數組里找有沒有匹配的，如果沒有匹配的話，也可以使用 setDefaultHandler，setDefaultHandler不是前面的 _registerDefaultRoutes，它需要開發者自己定義，并決定策略，如果定義了，所有沒被匹配的請求就會被這個策略處理。請求還支持設置在，在請求被匹配卻沒有正確被方法處理情況下的錯誤處理，最終 event 會用處理方法（策略）處理這個請求，否則就正常請求。這些請求就是 workbox下的 runtimecache。

現在來看看 Workbox 提供的緩存策略，主要有這幾種：cache-first,cache-only,network-first,network-only,stale-while-revalidate。

在前面看到，實例化的時候會給 workbox 掛載一個 Strategies 的實例。提供上面一系列的緩存策略，但在實際調用中，使用的是 _getCachingMechanism，然后把整個策略類放到一參中，二參則提供了配置項，在每個策略類中都有 handle 方法的實現，最終也會調用 handle方法。那既然如此還搞個 _getCachingMechanism干嘛，直接返回策略類就得了，這個等下看。

先看下各個策略，這里就簡單說下，可以參考離線指南，雖然會有一點不一樣。

第一個 Cache-First, 它的 handle 方法：

const cachedResponse = await this.requestWrapper.match({
  request: event.request,
});

return cachedResponse || await this.requestWrapper.fetchAndCache({
  request: event.request,
  waitOnCache: this.waitOnCache,
});

Cache-First策略會在有緩存的時候返回緩存，沒有緩存才會去請求并且把請求結果緩存，這也是我們對于precache的策略。

然后是 Cache-only，它只會去緩存里拿數據，沒有就失敗了。

network-first 是一個比較復雜的策略，它接受 networkTimeoutSeconds 參數，如果沒有傳這個參數，請求將會發出，成功的話就返回結果添加到緩存中，如果失敗則返回立即緩存。這種網絡回退到緩存的方式雖然利于那些頻繁更新的資源，但是在網絡情況比較差的情況（無網會直接返回緩存）下，等待會比較久，這時候 networkTimeoutSeconds 就提供了作用，如果設置了，會生成一個setTimeout后被resolve的緩存調用，再把它和請求放倒一個 Promise.race 中，那么請求超時后就會返回緩存。

network-only，也比較簡單，只請求，不讀寫緩存。

最后提供的策略是 StaleWhileRevalidate，這種策略比較接近 cache-first，代碼如下：

const fetchAndCacheResponse = this.requestWrapper.fetchAndCache({
  request: event.request,
  waitOnCache: this.waitOnCache,
  cacheResponsePlugin: this._cacheablePlugin,
}).catch(() => Response.error());

const cachedResponse = await this.requestWrapper.match({
  request: event.request,
});

return cachedResponse || await fetchAndCacheResponse;
  

他們的區別在于就算有緩存，它仍然會發出請求，請求的結果會用來更新緩存，也就是說你的下一次訪問的如果時間足夠請求返回的話，你就能拿到最新的數據了。

可以看到離線指南中還提供了緩存然后訪問網絡再更新頁面的方法，但這種需要配合主進程代碼的修改，WorkBox 沒有提供這種模式。

回到在緩存策略里提到的，講講 _getCachingMechanism和緩存策略的參數。默認支持5個參數："cacheExpiration", "broadcastCacheUpdate", "cacheableResponse", "cacheName", "plugins"，(當然你會發現還有幾個參數不在這里處理，比如你可以傳一個自定義的 requestWrapper, 前面提到的 waitOnCache 和 NetworkFirst 支持的 networkTimeoutSeconds)，先看一個完整的示例：

const workboxSW = new WorkboxSW();
const cacheFirstStrategy = workboxSW.strategies.cacheFirst({
  cacheName: "example-cache",
  cacheExpiration: {
    maxEntries: 10,
    maxAgeSeconds: 7 * 24 * 60 * 60
  },
  broadcastCacheUpdate: {
    channelName: "example-channel-name"
  },
  cacheableResponse: {
    stses: [0, 200, 404],
    headers: {
      "Example-Header-1": "Header-Value-1",
      "Example-Header-2": "Header-Value-2"
    }
  }
  plugins: [
    // Additional Plugins
  ]
});

大致可以認定的是 cacheExpiration 會用來處理緩存失效，cacheName 決定了 cache 的索引名，cacheableResponse 則決定了什么請求返回可以被緩存。

那么插件到底是怎么被處理，現在可以看_getCachingMechanism函數了，_getCachingMechanism函數處理了什么，它其實就是把 cacheExpiration，broadcastCacheUpdate,cacheabelResponse里的參數找到對應方法，傳入參數實例化，然后掛在在封裝后的wrapperOptions的plugins參數里，但是只是實例化了有什么用呢？這里有關鍵的一步：

options.requestWrapper = new RequestWrapper(wrapperOptions);

所以最終這些插件還是會在 RequestWrapper 里處理，這里的一些操作是我們之前沒有提到的，來看下 RequestWrapper 里怎么處理的。

看下 RequestWrapper 的構造函數，取其中涉及到 plugins 的部分：

constructor({cacheName, cacheId, plugins, fetchOptions, matchOptions} = {}) {

  this.plugins = new Map();

  if (plugins) {
    isArrayOfType({plugins}, "object");

    plugins.forEach((plugin) => {
      for (let callbackName of pluginCallbacks) {
        if (typeof plugin[callbackName] === "function") {
          if (!this.plugins.has(callbackName)) {
            this.plugins.set(callbackName, []);
          } else if (callbackName === "cacheWillUpdate") {
            throw ErrorFactory.createError(
              "multiple-cache-will-update-plugins");
          } else if (callbackName === "cachedResponseWillBeUsed") {
            throw ErrorFactory.createError(
              "multiple-cached-response-will-be-used-plugins");
          }
          this.plugins.get(callbackName).push(plugin);
          }
        }
    });
  }
}

plugins是一個Map，默認支持以下幾種Key：cacheDidUpdate, cacheWillUpdate, fetchDidFail, requestWillFetch, cachedResponseWillBeUsed。可以理解為 requestWrapper 提供了一些hooks或者生命周期，而插件就是在 hook 上進行一些處理。

這里舉個緩存失效的例子看看怎么處理：

首先我們需要實例化CacheExpirationPlugin，CacheExpirationPlugin沒有構造函數，實例化的是CacheExpiration，然后在this上添加maxEntries，maxAgeSeconds。所有的 hook 方法實現都放在了 CacheExpirationPlugin，提供了兩個 hook: cachedResponseWillBeUsed 和 cacheDidUpdate，cachedResponseWillBeUsed 會在 RequestWrapper的match中執行，cacheDidUpdate 在 fetchAndCache中 執行。

這里可以看出，每個plugin其實就是對hook或者生命周期調用的具體實現，在把response扔到cache里之后，調用了插件的cacheDidUpdate方法，看下CacheExpirationPlugin中的cacheDidUpdate：

async cacheDidUpdate({cacheName, newResponse, url, now} = {}) {
  isType({cacheName}, "string");
  isInstance({newResponse}, Response);

  if (typeof now === "undefined") {
    now = Date.now();
  }

  await this.updateTimestamp({cacheName, url, now});
  await this.expireEntries({cacheName, now});
}

那么關鍵就是更新時間戳和失效條數，如果設置了更新時間戳會怎么樣呢，在請求的時候，runtimecache也會添加到IndexedDB，值存入的是一個對象，包含了一個url和時間戳。

這個時間戳怎么生效，CacheExpirationPlugin提供了另外一個方法，cachedResponseWillBeUsed:

cachedResponseWillBeUsed({cachedResponse, cachedResponse, now} = {}) {
  if (this.isResponseFresh({cachedResponse, now})) {
    return cachedResponse;
  }

  return null;
}

RequestWrapper中的match方法會默認從cache里取，取到的是當時的完整 response, 在cache的 response 里的 headers 里取到 date，然后把當時的date加上 maxAgeSecond 和 現在的時間比， 如果小于了就返回 false，那么自然會去發起請求了。

CacheableResponsePlugin用來控制 fetchAndCache 里的 cacheable，它設置了一個 cacheWillUpdate，可以設置哪些 http status 或者 headers 的 response 要緩存，做到更精細的緩存操作。

離線指南已經提供了一些緩存方式，在 workbox 中，可以大致認為，有一些資源會直接影響整個應用的框架能否顯示的（開發應用的 JS，CSS 和部分圖片）可以做 precache，這些資源一般不存在“異步”的加載，它們如果不顯示整個頁面無法正常加載。

那他們的更新策略也很簡單，一般這些資源的更新需要發版，而在這里用更新sw文件更新。

對于大部分無狀態（注意無狀態）數據請求，推薦StaleWhileRevalidate方式或者緩存回退，在某些后端數據變化比較快的情況下，添加失效時間也是可以的，對于其它（業務圖片）需求，cache-first比較適用。

最后需要討論的是頁面和有狀態的請求，頁面是一個比較復雜的情況，頁面如果是純靜態的，那么可以放入precache。但要注意，如果我們的頁面不是打包工具生成的，頁面文件很可能不在dist目錄下，那么怎么追蹤變化呢，這里推薦一種方式，我們的頁面往往有一個模版，和一個json串配置hash變量，那么你可以添加這種模式：

templatedUrls: {
  path: [
    ".../xxx.html",
    ".../xxx.json"
  ]
}

如果沒有json，就需要關聯所有可能影響生成頁面的數據了，那么這些文件的變化都會改變最后生成的sw文件。

如果你在頁面上有一些動態信息（比如用戶信息等等），那就比較麻煩了，推薦使用 network-first 配合一個合適的失敗時間，畢竟大家都不希望用戶登錄了另一個賬號，顯示的還是上一個賬號，這同樣適用于那些使用cookie（有狀態）的請求，這些請求也推薦你添加失效策略，和失敗狀態。

永遠記住你的目標，讓用戶能夠更快的看到頁面，但不要給用戶一個錯誤的頁面。

在目前的網絡環境下，service worker 的推送服務并不能得到很好的利用，所以使用 service worker 很大程度就是利用其強大的緩存能力給用戶在弱網和無網環境的優化，甚至可以通過判斷網絡環境進行一些預下載，豐富頁面的交互。但是一個錯誤的緩存策略可能會使用戶得不到最新的內容，每一個致力于使用 service worker 或者 PWA 的開發者都需要了解其緩存的處理。Google 提供了一系列的工具能夠快速生成優質的sw文件，但是配套文檔過分簡單和無本地化讓這些配置如同一個黑盒，使開發者很難確定正確的配置方案。希望能夠閱讀本文，解決讀者這方面的困惑。