PWA之Workbox緩存策略分析

時間 2019-12-10

標籤 pwa workbox 緩存策略分析简体版

原文原文鏈接

做者：陳達孚javascript

香港中文大學研究生,《移動Web前端高效開發實戰》做者之一，《前端開發者指南2017》譯者之一，在中國前端開發者大會,中生代技術大會等技術會議發表過主題演講, 專一於新技術的調研和使用.css

本文爲原創文章，轉載請註明做者及出處html

PWA之Workbox緩存策略分析

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

precache（預緩存）

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

globDirectory
staticFileGlobs
swDest

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

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

那麼說了那麼多，precache 到底幹了什麼，看一下生成的sw文件：正則表達式

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

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

那仍是須要看一下 precache 的代碼:json

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（運行時緩存）

在瞭解 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文件，可是配套文檔過度簡單和無本地化讓這些配置如同一個黑盒，使開發者很難肯定正確的配置方案。但願可以閱讀本文，解決讀者這方面的困惑。

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。