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

作者：陳達(dá)孚
香港中文大學(xué)研究生,《移動Web前端高效開發(fā)實戰(zhàn)》作者之一，《前端開發(fā)者指南2017》譯者之一，在中國前端開發(fā)者大會,中生代技術(shù)大會等技術(shù)會議發(fā)表過主題演講, 專注于新技術(shù)的調(diào)研和使用.
本文為原創(chuàng)文章，轉(zhuǎn)載請注明作者及出處

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

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

globDirectory

staticFileGlobs

swDest

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

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

那么說了那么多，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 會根據(jù)內(nèi)部promise的結(jié)果來確定安裝是否完成。如果安裝失敗，則會舍棄這個ServiceWorker。

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

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

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

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

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

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，為什么還要查是否緩存過，這是因為當(dāng)你sw文件更新后，原來的緩存還是存在的，它們或許持有相同的url，如果它們的revision也相同，就不用獲取了。

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

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

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

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

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

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

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

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

在了解 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 實例化的過程主要有生成緩存對應(yīng)空間名，緩存空間，掛載緩存策略，掛載路由方法（用于處理對應(yīng)路徑的緩存策略），注冊安裝激活方法，注冊默認(rèn)路由。

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

看到最后一步的 _registerDefaultRoutes ，看一下其中的代碼，可以發(fā)現(xiàn) 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 中可以找到，或者在去除了部分查詢參數(shù)后符合，或者去處部分查詢參數(shù)添加后綴后符合，就會直接返回緩存，至于請求過來怎么處理的，稍后再看。

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

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

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

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

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

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

在前面看到，實例化的時候會給 workbox 掛載一個 Strategies 的實例。提供上面一系列的緩存策略，但在實際調(diào)用中，使用的是 _getCachingMechanism，然后把整個策略類放到一參中，二參則提供了配置項，在每個策略類中都有 handle 方法的實現(xiàn)，最終也會調(diào)用 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策略會在有緩存的時候返回緩存，沒有緩存才會去請求并且把請求結(jié)果緩存，這也是我們對于precache的策略。

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

network-first 是一個比較復(fù)雜的策略，它接受 networkTimeoutSeconds 參數(shù)，如果沒有傳這個參數(shù)，請求將會發(fā)出，成功的話就返回結(jié)果添加到緩存中，如果失敗則返回立即緩存。這種網(wǎng)絡(luò)回退到緩存的方式雖然利于那些頻繁更新的資源，但是在網(wǎng)絡(luò)情況比較差的情況（無網(wǎng)會直接返回緩存）下，等待會比較久，這時候 networkTimeoutSeconds 就提供了作用，如果設(shè)置了，會生成一個setTimeout后被resolve的緩存調(diào)用，再把它和請求放倒一個 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;
  

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

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

回到在緩存策略里提到的，講講 _getCachingMechanism和緩存策略的參數(shù)。默認(rèn)支持5個參數(shù)："cacheExpiration", "broadcastCacheUpdate", "cacheableResponse", "cacheName", "plugins"，(當(dāng)然你會發(fā)現(xiàn)還有幾個參數(shù)不在這里處理，比如你可以傳一個自定義的 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
  ]
});

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

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

options.requestWrapper = new RequestWrapper(wrapperOptions);

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

看下 RequestWrapper 的構(gòu)造函數(shù)，取其中涉及到 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，默認(rèn)支持以下幾種Key：cacheDidUpdate, cacheWillUpdate, fetchDidFail, requestWillFetch, cachedResponseWillBeUsed?？梢岳斫鉃?requestWrapper 提供了一些hooks或者生命周期，而插件就是在 hook 上進(jìn)行一些處理。

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

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

這里可以看出，每個plugin其實就是對hook或者生命周期調(diào)用的具體實現(xiàn)，在把response扔到cache里之后，調(diào)用了插件的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});
}

那么關(guān)鍵就是更新時間戳和失效條數(shù)，如果設(shè)置了更新時間戳?xí)趺礃幽?，在請求的時候，runtimecache也會添加到IndexedDB，值存入的是一個對象，包含了一個url和時間戳。

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

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

  return null;
}

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

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

離線指南已經(jīng)提供了一些緩存方式，在 workbox 中，可以大致認(rèn)為，有一些資源會直接影響整個應(yīng)用的框架能否顯示的（開發(fā)應(yīng)用的 JS，CSS 和部分圖片）可以做 precache，這些資源一般不存在“異步”的加載，它們?nèi)绻伙@示整個頁面無法正常加載。

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

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

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

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

如果沒有json，就需要關(guān)聯(lián)所有可能影響生成頁面的數(shù)據(jù)了，那么這些文件的變化都會改變最后生成的sw文件。

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

永遠(yuǎn)記住你的目標(biāo)，讓用戶能夠更快的看到頁面，但不要給用戶一個錯誤的頁面。

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