摘要：的本質(zhì)是一個，它獨立于主線程，因此它不能直接訪問，也不能直接訪問對象，但是，可以訪問對象，也可以通過消息傳遞的方式與主線程進行通信。的最佳用法其實就是配合做離線緩存。

Service Worker本質(zhì)上充當(dāng)Web應(yīng)用程序與瀏覽器之間的代理服務(wù)器，也可以在網(wǎng)絡(luò)可用時作為瀏覽器和網(wǎng)絡(luò)間的代理。它們旨在（除其他之外）使得能夠創(chuàng)建有效的離線體驗，攔截網(wǎng)絡(luò)請求并基于網(wǎng)絡(luò)是否可用以及更新的資源是否駐留在服務(wù)器上來采取適當(dāng)?shù)膭幼?。他們還允許訪問推送通知和后臺同步API。

Service Worker的本質(zhì)是一個Web Worker，它獨立于JavaScript主線程，因此它不能直接訪問DOM，也不能直接訪問window對象，但是，Service Worker可以訪問navigator對象，也可以通過消息傳遞的方式（postMessage）與JavaScript主線程進行通信。

Service Worker是一個網(wǎng)絡(luò)代理，它可以控制Web頁面的所有網(wǎng)絡(luò)請求。

Service Worker具有自身的生命周期，使用好Service Worker的關(guān)鍵是靈活控制其生命周期。

用于瀏覽器緩存

實現(xiàn)離線Web APP

消息推送

Service Worker是現(xiàn)代瀏覽器的一個高級特性，它依賴于fetch API、Cache Storage、Promise等，其中，Cache提供了Request / Response對象對的存儲機制，Cache Storage存儲多個Cache。

在了解Service Worker的原理之前，先來看一段Service Worker的示例：

self.importScripts("./serviceworker-cache-polyfill.js");

var urlsToCache = [
  "/",
  "/index.js",
  "/style.css",
  "/favicon.ico",
];

var CACHE_NAME = "counterxing";

self.addEventListener("install", function(event) {
  self.skipWaiting();
  event.waitUntil(
    caches.open(CACHE_NAME)
    .then(function(cache) {
      return cache.addAll(urlsToCache);
    })
  );
});

self.addEventListener("fetch", function(event) {
  event.respondWith(
    caches.match(event.request)
    .then(function(response) {
      if (response) {
        return response;
      }
      return fetch(event.request);
    })
  );
});


self.addEventListener("activate", function(event) {
  var cacheWhitelist = ["counterxing"];

  event.waitUntil(
    caches.keys().then(function(cacheNames) {
      return Promise.all(
        cacheNames.map(function(cacheName) {
          if (cacheWhitelist.indexOf(cacheName) === -1) {
            return caches.delete(cacheName);
          }
        })
      );
    })
  );
});

下面開始逐段逐段地分析，揭開Service Worker的神秘面紗：

首先看第一行：self.importScripts("./serviceworker-cache-polyfill.js");，這里引入了Cache API的一個polyfill，這個polyfill支持使得在較低版本的瀏覽器下也可以使用Cache Storage API。想要實現(xiàn)Service Worker的功能，一般都需要搭配Cache API代理網(wǎng)絡(luò)請求到緩存中。

在Service Worker線程中，使用importScripts引入polyfill腳本，目的是對低版本瀏覽器的兼容。

之后，使用一個urlsToCache列表來聲明需要緩存的靜態(tài)資源，再使用一個變量CACHE_NAME來確定當(dāng)前緩存的Cache Storage Name，這里可以理解成Cache Storage是一個DB，而CACHE_NAME則是DB名：

var urlsToCache = [
  "/",
  "/index.js",
  "/style.css",
  "/favicon.ico",
];

var CACHE_NAME = "counterxing";

Service Worker獨立于瀏覽器JavaScript主線程，有它自己獨立的生命周期。

如果需要在網(wǎng)站上安裝Service Worker，則需要在JavaScript主線程中使用以下代碼引入Service Worker。

if ("serviceWorker" in navigator) {
  navigator.serviceWorker.register("/sw.js").then(function(registration) {
    console.log("成功安裝", registration.scope);
  }).catch(function(err) {
    console.log(err);
  });
}

此處，一定要注意sw.js文件的路徑，在我的示例中，處于當(dāng)前域根目錄下，這意味著，Service Worker和網(wǎng)站是同源的，可以為當(dāng)前網(wǎng)站的所有請求做代理，如果Service Worker被注冊到/imaging/sw.js下，那只能代理/imaging下的網(wǎng)絡(luò)請求。

可以使用Chrome控制臺，查看當(dāng)前頁面的Service Worker情況：

安裝完成后，Service Worker會經(jīng)歷以下生命周期：

下載（download）

安裝（install）

激活（activate）

用戶首次訪問Service Worker控制的網(wǎng)站或頁面時，Service Worker會立刻被下載。之后至少每24小時它會被下載一次。它可能被更頻繁地下載，不過每24小時一定會被下載一次，以避免不良腳本長時間生效。

在下載完成后，開始安裝Service Worker，在安裝階段，通常需要緩存一些我們預(yù)先聲明的靜態(tài)資源，在我們的示例中，通過urlsToCache預(yù)先聲明。

在安裝完成后，會開始進行激活，瀏覽器會嘗試下載Service Worker腳本文件，下載成功后，會與前一次已緩存的Service Worker腳本文件做對比，如果與前一次的Service Worker腳本文件不同，證明Service Worker已經(jīng)更新，會觸發(fā)activate事件。完成激活。

如圖所示，為Service Worker大致的生命周期：

在安裝完成后，嘗試緩存一些靜態(tài)資源：

self.addEventListener("install", function(event) {
  self.skipWaiting();
  event.waitUntil(
    caches.open(CACHE_NAME)
    .then(function(cache) {
      return cache.addAll(urlsToCache);
    })
  );
});

首先，self.skipWaiting()執(zhí)行，告知瀏覽器直接跳過等待階段，淘汰過期的sw.js的Service Worker腳本，直接開始嘗試激活新的Service Worker。

然后使用caches.open打開一個Cache，打開后，通過cache.addAll嘗試緩存我們預(yù)先聲明的靜態(tài)文件。

頁面的所有網(wǎng)絡(luò)請求，都會通過Service Worker的fetch事件觸發(fā)，Service Worker通過caches.match嘗試從Cache中查找緩存，緩存如果命中，則直接返回緩存中的response，否則，創(chuàng)建一個真實的網(wǎng)絡(luò)請求。

self.addEventListener("fetch", function(event) {
  event.respondWith(
    caches.match(event.request)
    .then(function(response) {
      if (response) {
        return response;
      }
      return fetch(event.request);
    })
  );
});

如果我們需要在請求過程中，再向Cache Storage中添加新的緩存，可以通過cache.put方法添加，看以下例子：

self.addEventListener("fetch", function(event) {
  event.respondWith(
    caches.match(event.request)
    .then(function(response) {
      // 緩存命中
      if (response) {
        return response;
      }

      // 注意，這里必須使用clone方法克隆這個請求
      // 原因是response是一個Stream，為了讓瀏覽器跟緩存都使用這個response
      // 必須克隆這個response，一份到瀏覽器，一份到緩存中緩存。
      // 只能被消費一次，想要再次消費，必須clone一次
      var fetchRequest = event.request.clone();

      return fetch(fetchRequest).then(
        function(response) {
          // 必須是有效請求，必須是同源響應(yīng)，第三方的請求，因為不可控，最好不要緩存
          if (!response || response.status !== 200 || response.type !== "basic") {
            return response;
          }

          // 消費過一次，又需要再克隆一次
          var responseToCache = response.clone();
          caches.open(CACHE_NAME)
            .then(function(cache) {
              cache.put(event.request, responseToCache);
            });
          return response;
        }
      );
    })
  );
});

在項目中，一定要注意控制緩存，接口請求一般是不推薦緩存的。所以在我自己的項目中，并沒有在這里做動態(tài)的緩存方案。

Service Worker總有需要更新的一天，隨著版本迭代，某一天，我們需要把新版本的功能發(fā)布上線，此時需要淘汰掉舊的緩存，舊的Service Worker和Cache Storage如何淘汰呢？

self.addEventListener("activate", function(event) {
  var cacheWhitelist = ["counterxing"];

  event.waitUntil(
    caches.keys().then(function(cacheNames) {
      return Promise.all(
        cacheNames.map(function(cacheName) {
          if (cacheWhitelist.indexOf(cacheName) === -1) {
            return caches.delete(cacheName);
          }
        })
      );
    })
  );
});

首先有一個白名單，白名單中的Cache是不被淘汰的。

之后通過caches.keys()拿到所有的Cache Storage，把不在白名單中的Cache淘汰。

淘汰使用caches.delete()方法。它接收cacheName作為參數(shù)，刪除該cacheName所有緩存。

sw-precache-webpack-plugin是一個webpack plugin，可以通過配置的方式在webpack打包時生成我們想要的sw.js的Service Worker腳本。

一個最簡單的配置如下：

var path = require("path");
var SWPrecacheWebpackPlugin = require("sw-precache-webpack-plugin");

const PUBLIC_PATH = "https://www.my-project-name.com/";  // webpack needs the trailing slash for output.publicPath

module.exports = {

  entry: {
    main: path.resolve(__dirname, "src/index"),
  },

  output: {
    path: path.resolve(__dirname, "src/bundles/"),
    filename: "[name]-[hash].js",
    publicPath: PUBLIC_PATH,
  },

  plugins: [
    new SWPrecacheWebpackPlugin(
      {
        cacheId: "my-project-name",
        dontCacheBustUrlsMatching: /.w{8}./,
        filename: "service-worker.js",
        minify: true,
        navigateFallback: PUBLIC_PATH + "index.html",
        staticFileGlobsIgnorePatterns: [/.map$/, /asset-manifest.json$/],
      }
    ),
  ],
}

在執(zhí)行webpack打包后，會生成一個名為service-worker.js文件，用于緩存webpack打包后的靜態(tài)文件。

一個最簡單的示例。

對比起Http Header緩存，Service Worker配合Cache Storage也有自己的優(yōu)勢：

緩存與更新并存：每次更新版本，借助Service Worker可以立馬使用緩存返回，但與此同時可以發(fā)起請求，校驗是否有新版本更新。

無侵入式：hash值實在是太難看了。

不易被沖掉：Http緩存容易被沖掉，也容易過期，而Cache Storage則不容易被沖掉。也沒有過期時間的說法。

離線：借助Service Worker可以實現(xiàn)離線訪問應(yīng)用。

但是缺點是，由于Service Worker依賴于fetch API、依賴于Promise、Cache Storage等，兼容性不太好。

本文只是簡單總結(jié)了Service Worker的基本使用和使用Service Worker做客戶端緩存的簡單方式，然而，Service Worker的作用遠不止于此，例如：借助Service Worker做離線應(yīng)用、用于做網(wǎng)絡(luò)應(yīng)用的推送（可參考push-notifications）等。

甚至可以借助Service Worker，對接口進行緩存，在我所在的項目中，其實并不會做的這么復(fù)雜。不過做接口緩存的好處是支持離線訪問，對離線狀態(tài)下也能正常訪問我們的Web應(yīng)用。

Cache Storage和Service Worker總是分不開的。Service Worker的最佳用法其實就是配合Cache Storage做離線緩存。借助于Service Worker，可以輕松實現(xiàn)對網(wǎng)絡(luò)請求的控制，對于不同的網(wǎng)絡(luò)請求，采取不同的策略。例如對于Cache的策略，其實也是存在多種情況。例如可以優(yōu)先使用網(wǎng)絡(luò)請求，在網(wǎng)絡(luò)請求失敗時再使用緩存、亦可以同時使用緩存和網(wǎng)絡(luò)請求，一方面檢查請求，一方面有檢查緩存，然后看兩個誰快，就用誰。