摘要：而一個文件名表明將只捕獲在下的請求。包含請求主體其被包含在對象中。該方法將首先緩存響應(yīng)但隨后在后臺網(wǎng)絡(luò)請求。被用來提供響應(yīng)針對請求。一旦這個異步操作完成后操作將終止。

翻譯：jsdt
原文標(biāo)題：Understanding Service Workers
原文鏈接：http://blog.88mph.io/2017/07/...
聲明：轉(zhuǎn)載請指明出處。

在網(wǎng)絡(luò)早期,很難想象在用戶離線的時候一個網(wǎng)頁可以訪問。你總需要一直在線。

鏈接網(wǎng)絡(luò)吧,伙伴們都在這,不要離開了。

但隨著移動互聯(lián)網(wǎng)的出現(xiàn),以及這個世界上越來越多的地區(qū)連接上網(wǎng)絡(luò),參差不齊的網(wǎng)絡(luò)連接速度在現(xiàn)代web用戶中越來越普遍。

因此,對于與網(wǎng)站來說,研究如何使用戶不受到網(wǎng)絡(luò)鏈接限制能力,使他們在離線的時候也能訪問變得越來越有價值。

AppCache最初被引入作為html5的標(biāo)準(zhǔn)一部分,目的是作為web離線應(yīng)用的解決方案之一。它包括HTML和javascript,由一個可以寫聲明性語語言的,緩存manifest配置文件進(jìn)行管理。

Service workers提供了一個不會過時的,程序命令式的,針對離線web問題的解決方案,取代了聲明式的AppCache。

Service workers以持久的方式執(zhí)行代碼,后臺進(jìn)程的方式運行在瀏覽器中(意思是說不會影響js線程的執(zhí)行),代碼是事件驅(qū)動的,意味著在Service workers中事件被觸發(fā)是因為外在的行為。

文章的剩余部分主要講述了Service workers當(dāng)中的事件,作為分析開始,你首先需要知道,在你的web app中需要注冊service worker。

下面的代碼介紹了在客戶端瀏覽器中怎樣注冊service worker。下面register的執(zhí)行方式放在你的web app中的某處即可。

if (navigator.serviceWorker) {  
  navigator.serviceWorker.register("/sw.js")
    .then(registration => {
      console.log("congrats. scope is: ", registration.scope);
    })
    .catch(error => {
      console.log("sorry", error);
    });
}

上面代碼作用是告訴瀏覽器哪里去找Service Worke的實現(xiàn)。瀏覽器找到sw.js文件,將其保存為一個 Service Worker放在可以訪問到的域中。在sw.js中包含了怎么處理Service Worker生命周期中的一些事件。

上面圖示當(dāng)中顯示一個已經(jīng)注冊的service worker 在Chrome DevTools上。

它設(shè)置了你的ServiceWorker的作用范圍。文件名/sw.js意味著SW的范圍是項目的根路徑的URL(或http://localhost:3000/)。這意味著在根路徑下的任何請求將是可見的,對于SW被觸發(fā)的事件來說。
而一個文件名/js/sw.js表明將只捕獲在 http://localhost:3000/js下的請求。

作為一種選擇,你也可以通過傳遞參數(shù)的方式給register方法, 來顯式的設(shè)置SW的作用域范圍

navigator.serviceWorker.register("/sw.js", { scope: "/js" }).

既然你的Service Worker已經(jīng)注冊,是時候去實現(xiàn)事件處理在Service Worker的各個生命周期階段。

install事件在第一次成功注冊Service Worker時觸發(fā),或者在Service Worke文件(/sw.js)更新(瀏覽器會自動檢測到更新)的時候。

install事件是有用的邏輯,在你想執(zhí)行的Service Worker初始化期間,它是一次性的操作。一個常見的用例是在安裝步驟時加載緩存的文件。

這里是一個例子,一個安裝事件處理程序,它將數(shù)據(jù)添加到緩存中

const CACHE_NAME = "cache-v1";  
const urlsToCache = [  
  "/",
  "/js/main.js",
  "/css/style.css",
  "/img/bob-ross.jpg",
];

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

urlsToCache包含了一系列我們想添加到緩存中的url。

caches是一個全局的CacheStorage對象,通過這個對象可以管理你的緩存在瀏覽器中。
我們調(diào)用open方法以獲得確切的我們想使用的緩存對象。

cache.addAll接受URLs集合,然后遍歷發(fā)送一系列的request,然后存儲response在緩存中。它使用request body 作為每個緩存的key。addAll的參考文檔。

Cached data 在Chrome DevTools中

Fetch事件被觸發(fā)在每次web頁面發(fā)出請求的時候。當(dāng)它被觸發(fā)時,您的service worker有能力“攔截”請求,并決定如何返回——不管是緩存數(shù)據(jù),抑或是一個實際的網(wǎng)絡(luò)請求響應(yīng)。

下面的例子說明了cache-first策略:任何緩存的數(shù)據(jù),在相匹配的請求中將被首先發(fā)送,而沒有一個網(wǎng)絡(luò)請求。只有在沒有緩存數(shù)據(jù)時才會有網(wǎng)絡(luò)請求。

self.addEventListener("fetch", event => {  
  const { request } = event;
  const findResponsePromise = caches.open(CACHE_NAME)
    .then(cache => cache.match(request))
    .then(response => {
      if (response) {
        return response;
      }

      return fetch(request);
    });

  event.respondWith(findResponsePromise);
});

request包含請求主體,其被包含在FetchEvent對象中。它是用來在緩存中查找匹配響應(yīng)。

cache.match將試圖找到一個緩存來響應(yīng)相匹配的指定請求。如果匹配不到,promise將解析為undefined。我們檢查這種情況,調(diào)用執(zhí)行fetch方法在這種情況下,這會導(dǎo)致產(chǎn)生一個網(wǎng)絡(luò)請求并且返回一個promise。

FetchEvent對象上有一個特殊的方法event.respondWith,對于瀏覽器的請求我們可以使用這個方法返回一個相應(yīng)。這個函數(shù)接受一個promise參數(shù),返回一個response。

fetch事件非常重要,因為只有通過這個方法你才能定義緩存策略。也就是說,你可以決定何時使用緩存數(shù)據(jù),何時使用網(wǎng)絡(luò)數(shù)據(jù)。

Service Workers的美妙之處在于他是一個攔截requests的初級api,允許你返回自己定制的response。這給了我們是使用緩存還是網(wǎng)絡(luò)數(shù)據(jù)的自由。這里有幾個基本的緩存策略,你可以使用它們讓你的web app變得更好。

mdn是一個非常方便的文檔資源,他上面介紹了計重不同的緩存策略。這里也有一個Jake Archibald寫的 The Offline Cookbook,
,里面介紹了一些緩存策略,與mdn上相比有相同的,也有不同的。

在上面的示例中,我們演示了一個基本的cache-first策略。下面是一個我找到的適用于自己的項目的例子:緩存和更新策略。該方法將首先緩存響應(yīng),但隨后在后臺網(wǎng)絡(luò)請求。來自于這個后臺請求的response被用于更新緩存中的值,以便下次更新響應(yīng)提供訪問。

self.addEventListener("fetch", event => {  
  const { request } = event;

  event.respondWith(caches.open(CACHE_NAME)
    .then(cache => cache.match(request))
    .then(matching => matching || fetch(request)));

  event.waitUntil(caches.open(CACHE_NAME)
    .then(cache => fetch(request)
      .then(response => cache.put(request, response))));
});

event.respondWith 被用來提供響應(yīng)針對請求。通過它,我們開啟一個緩存,并從緩存中尋找匹配的response,如果緩存中匹配不到,就通過網(wǎng)絡(luò)來相應(yīng)。

隨后,我們調(diào)用event.waitUntil,解析Promise在Service Worker結(jié)束之前。在這里我們發(fā)送一個網(wǎng)絡(luò)請求,然后緩存響應(yīng)。一旦這個異步操作完成后,waitUntil操作將終止。

activate是一個記錄事件,在你更新service worker文件,執(zhí)行清理或者維護(hù)先前版本的service worker時,這個事件非常重要。
當(dāng)你更新你的service worker文件(/sw.js)時,瀏覽器能探測到這種改變并顯示在Chrome DevTools:

你的service worker 正等在被激活

當(dāng)web頁面關(guān)閉,再次重啟打開,瀏覽器將用新的service worker取代舊的service worker,并且依次觸發(fā)activate,install事件。如果你需要清理緩存或執(zhí)行維護(hù)service worker的舊版本,激活事件是實現(xiàn)需求的最佳時機(jī)。

sync事件可以讓你延遲網(wǎng)絡(luò)任務(wù),直到用戶連接。它實現(xiàn)的功能通常被稱為后臺同步。這是有用的,可以確保任何網(wǎng)絡(luò)任務(wù),在用戶開始在離線模式,然后又恢復(fù)網(wǎng)絡(luò)鏈接模式時順利執(zhí)行。

這里有一個例子演示后臺任務(wù),你只需要在你的js代碼中注冊一個同步事件,在其中做一些相應(yīng)的處理在你的service worker中:

// app.js
navigator.serviceWorker.ready  
  .then(registration => {
    document.getElementById("submit").addEventListener("click", () => {
      registration.sync.register("submit").then(() => {
        console.log("sync registered!");
      });
    });
  });

在這里我們聲明了一個按鈕上 的click事件通過調(diào)用sync.register在ServiceWorkerRegistration 對象上。

基本上,你想要確保在任何時候網(wǎng)絡(luò)連接上時實現(xiàn)一些操作,需要注冊一個類似上面的同步事件。

你想要實現(xiàn)的操作可能類似發(fā)送一個評論,獲取用戶數(shù)據(jù)等等都將被定義在Service Worker的事件處理器中。

// sw.js
self.addEventListener("sync", event => {  
  if (event.tag === "submit") {
    console.log("sync!");
  }
});

在這里我們監(jiān)聽一個sync事件,檢查SyncEvent對象上的tag,看是否匹配我們submit。

如果在sync已經(jīng)注冊的情況下,聲明sync多次,此時sync事件只會執(zhí)行一次。

對于這個例子,如果用戶離線,并點擊按鈕七次,當(dāng)恢復(fù)網(wǎng)絡(luò)鏈接,所有同步注冊執(zhí)行優(yōu)先級將會提高,并執(zhí)行一次。

在那種情況下,你可能想針對每種同步點擊事件做不同的標(biāo)識處理。

如果用戶在線,同步事件無論是什么任務(wù),都會立即執(zhí)行,沒有任何延遲。

如果用戶離線,同步事件會盡可能快的被觸發(fā)在恢復(fù)網(wǎng)絡(luò)連接的時候。

你可以試試,驗證一下上面的結(jié)論在你的chrome中,再試之前確保斷開網(wǎng)路連接,檢查Chrome DevTools中的network選項。

想要了解更多信息,參考這篇文檔,抑或是background syncs. 同步事件很多瀏覽器不支持(僅僅chrome中有提到),一定會發(fā)生變化,所以持續(xù)關(guān)注。

通知推送是service worker中一個能夠使用的特性,與此先關(guān)的是瀏覽器上的一個push api

當(dāng)談到網(wǎng)絡(luò)推送通知,在工作中涉及到兩種技術(shù):通知和推送消息。

通知在service worker中是一個非常簡單容易實現(xiàn)的特性

// app.js
// ask for permission
Notification.requestPermission(permission => {  
  console.log("permission:", permission);
});

// display notification
function displayNotification() {  
  if (Notification.permission == "granted") {
    navigator.serviceWorker.getRegistration()
      .then(registration => {
        registration.showNotification("this is a notification!");
      });
  }
}

// sw.js
self.addEventListener("notificationclick", event => {  
  // notification click event
});

self.addEventListener("notificationclose", event => {  
  // notification closed event
});

你首先需要向用戶請求獲取權(quán)限在web頁面中。從那以后,你可以切換通知,處理某些事件,比如當(dāng)用戶關(guān)閉一個通知。

消息推送牽涉到利用瀏覽器提供的push api,以及后端的實現(xiàn)。如何實現(xiàn)push api可以寫成一篇獨立的文章。但是基本的邏輯如下:

它是一個復(fù)雜和輕微難懂的流程,具體闡述不在本文范圍內(nèi),如果你想了解更多,推薦這篇文章 introduction to push notifications

后面還有一小節(jié)闡述Ember和service worker的結(jié)合應(yīng)用,這個我并不感興趣,就略過了,如果Ember換成vue或react就好啦。接下我打算寫一篇實戰(zhàn)例子。