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

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

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

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

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

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

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

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

Service workers以持久的方式執(zhí)行代碼,后臺(tái)進(jìn)程的方式運(yùn)行在瀏覽器中(意思是說不會(huì)影響js線程的執(zhí)行),代碼是事件驅(qū)動(dòng)的,意味著在Service workers中事件被觸發(fā)是因?yàn)橥庠诘男袨椤?/p>

文章的剩余部分主要講述了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的實(shí)現(xiàn)。瀏覽器找到sw.js文件,將其保存為一個(gè) Service Worker放在可以訪問到的域中。在sw.js中包含了怎么處理Service Worker生命周期中的一些事件。

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

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

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

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

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

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

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

這里是一個(gè)例子,一個(gè)安裝事件處理程序,它將數(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是一個(gè)全局的CacheStorage對象,通過這個(gè)對象可以管理你的緩存在瀏覽器中。
我們調(diào)用open方法以獲得確切的我們想使用的緩存對象。

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

Cached data 在Chrome DevTools中

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

下面的例子說明了cache-first策略:任何緩存的數(shù)據(jù),在相匹配的請求中將被首先發(fā)送,而沒有一個(gè)網(wǎng)絡(luò)請求。只有在沒有緩存數(shù)據(jù)時(shí)才會(huì)有網(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將試圖找到一個(gè)緩存來響應(yīng)相匹配的指定請求。如果匹配不到,promise將解析為undefined。我們檢查這種情況,調(diào)用執(zhí)行fetch方法在這種情況下,這會(huì)導(dǎo)致產(chǎn)生一個(gè)網(wǎng)絡(luò)請求并且返回一個(gè)promise。

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

fetch事件非常重要,因?yàn)橹挥型ㄟ^這個(gè)方法你才能定義緩存策略。也就是說,你可以決定何時(shí)使用緩存數(shù)據(jù),何時(shí)使用網(wǎng)絡(luò)數(shù)據(jù)。

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

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

在上面的示例中,我們演示了一個(gè)基本的cache-first策略。下面是一個(gè)我找到的適用于自己的項(xiàng)目的例子:緩存和更新策略。該方法將首先緩存響應(yīng),但隨后在后臺(tái)網(wǎng)絡(luò)請求。來自于這個(gè)后臺(tái)請求的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)針對請求。通過它,我們開啟一個(gè)緩存,并從緩存中尋找匹配的response,如果緩存中匹配不到,就通過網(wǎng)絡(luò)來相應(yīng)。

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

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

你的service worker 正等在被激活

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

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

這里有一個(gè)例子演示后臺(tái)任務(wù),你只需要在你的js代碼中注冊一個(gè)同步事件,在其中做一些相應(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!");
      });
    });
  });

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

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

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

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

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

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

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

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

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

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

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

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

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

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

通知在service worker中是一個(gè)非常簡單容易實(shí)現(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)閉一個(gè)通知。

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

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

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