1. 程式人生 > >漸進式web應用開發--擁抱離線優先(三)

漸進式web應用開發--擁抱離線優先(三)

閱讀目錄

  • 一:什麼是離線優先?
  • 二:常用的快取模式
  • 三:混合與匹配,創造新模式
  • 四:規劃快取策略
  • 五:實現快取策略
回到頂部

一:什麼是離線優先?

傳統的web應用完全依賴於伺服器端,比如像很早以前jsp,php,asp時代,所有的資料,內容和應用邏輯都在伺服器端,客戶端僅僅做一些html內容渲染到頁面上去。但是隨著技術在不斷的改變,現在很多業務邏輯也放在前端,前後端分離,前端是做模板渲染工作,後端只做業務邏輯開發,只提供資料介面。但是我們的web前端開發在資料層這方面來講還是依賴於伺服器端。如果網路中斷或伺服器介面掛掉了,都會影響資料頁面展示。因此我們需要使用離線優先這個技術來更優雅的處理這個問題。

擁抱離線優先的真正含義是:儘管應用程式的某些功能在使用者離線時可能不能正常使用,但是更多的功能應該保持可用狀態。

離線優先它可以優雅的處理這些異常情況下問題,當用戶離線時,使用者正在檢視資料可能是之前的資料,但是仍然可以訪問之前的頁面,之前的資料不會丟失,這就意味著使用者可以放心使用某些功能。那麼要做到離線時候還可以訪問,就需要我們快取哦。

回到頂部

二:常用的快取模式

在為我們的網站使用快取之前,我們需要先熟悉一些常見的快取設計模式。如果我們要做一個股票K線圖的話,因為股票資料是實時更新的,因此我們需要實時的去請求網路最新的資料(當然實時肯定使用websocket技術,而不是http請求,我這邊是假如)。只有當網路請求失敗的時候,我們再從快取裡面去讀取資料。但是對於股票K線圖中的一些圖示展示這樣的,因為這些圖示是一般不會變的,所以我們更傾向於使用快取裡面的資料。只有在快取裡面找不到的情況下,再從網路上請求資料。

所以有如下幾種快取模式:

1. 僅快取
2. 快取優先,網路作為回退方案。
3. 僅網路。
4. 網路優先,快取作為回退方案。
5. 網路優先,快取作為回退方案, 通用回退。

1. 僅快取

什麼是僅快取呢?僅快取是指 從快取中響應所有的資源請求,如果快取中找不到的話,那麼請求就會失敗。那麼僅快取對於靜態資源是實用的。因為靜態資源一般是不會發生變化,比如圖示,或css樣式等這些,當然如果css樣式發生改變的話,在後綴可以加上時間戳這樣的。比如 base.css?t=20191011 這樣的,如果時間戳沒有發生改變的話,那麼我們直接從快取裡面讀取。
因此我們的 sw.js 程式碼可以寫成如下(注意:該篇文章是在上篇文章基礎之上的,如果想看上篇文章,請點選這裡:

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

如上程式碼,直接監聽 fetch事件,該事件能監聽到頁面上所有的請求,當有請求過來的時候,它使用快取裡面的資料依次去匹配當前的請求,如果匹配到了,就拿快取裡面的資料,如果沒有匹配到,則請求失敗。

2. 快取優先,網路作為回退方案

該模式是:先從快取裡面讀取資料,當快取裡面沒有匹配到資料的時候,service worker才會去請求網路並返回。

程式碼變成如下:

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

如上程式碼,使用fetch去監聽所有請求,然後先使用快取依次去匹配請求,不管是匹配成功還是匹配失敗都會進入then回撥函式,當匹配失敗的時候,我們的response值就為 undefined,如果為undefined的話,那麼就網路請求,否則的話,從拿快取裡面的資料。

3. 僅網路

傳統的web模式,就是這種模式,從網路裡面去請求,如果網路不通,則請求失敗。因此程式碼變成如下:

self.addEventListener("fetch", function(event) {
  event.respondWith(
    fetch(event.request)
  )
});

4. 網路優先,快取作為回退方案。

先從網路發起請求,如果網路請求失敗的話,再從快取裡面去匹配資料,如果快取裡面也沒有找到的話,那麼請求就會失敗。

因此程式碼如下:

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

5. 網路優先,快取作為回退方案, 通用回退

該模式是先請求網路,如果網路失敗的話,則從快取裡面讀取,如果快取裡面讀取失敗的話,我們提供一個預設的顯示給頁面展示。

比如顯示一張圖片。如下程式碼:

self.addEventListener("fetch", function(event) {
  event.respondWith(
    fetch(event.request).catch(function() {
      return caches.match(event.request).then(function(response) {
        return response || caches.match("/xxxx.png");
      })
    });
  )
});
回到頂部

三:混合與匹配,創造新模式

上面是我們五種快取模式。下面我們需要將這些模式要組合起來使用。

1. 快取優先,網路作為回退方案, 並更新快取。

對於不經常改變的資源,我們可以先快取優先,網路作為回退方案,第一次請求完成後,我們把請求的資料快取起來,下次再次執行的時候,我們先從快取裡面讀取。

因此程式碼如下:

self.addEventListener("fetch", function(event) {
  event.respondWith(
    caches.open("cache-name").then(function(cache) {
      return cache.match(event.request).then(function(cachedResponse){
        return cachedResponse || fetch(event.request).then(function(networkResponse){
          cache.put(event.request, networkResponse.clone());
          return networkResponse;
        });
      })
    })
  )
});

如上程式碼,我們首先開啟快取,然後使用請求匹配快取,不管匹配成功了還是匹配失敗了,都會進入then回撥函式,如果匹配到了,說明快取裡面有對應的資料,那麼直接從快取裡面返回,如果快取裡面 cachedResponse 值為undefined,沒有的話,那麼就重新使用fetch請求網路,然後把請求的資料 networkResponse 重新返回回來,並且克隆一份 networkResponse 放入快取裡面去。

2. 網路優先,快取作為回退方案,並頻繁更新快取

如果一些經常要實時更新的資料的話,比如百度上的一些實時新聞,那麼都需要對網路優先,快取作為回退方案來做,那麼該模式下首先會從網路中獲取最新版本,當網路請求失敗的時候才回退到快取版本,當網路請求成功的時候,它會將當前返回最新的內容重新賦值給快取裡面去。這樣就保證快取永遠是上一次請求成功的資料。即使網路斷開了,還是會使用之前最新的資料的。

因此程式碼可以變成如下:

self.addEventListener("fetch", function(event) {
  event.respondWith(
    caches.open("cache-name").then(function(cache) {
      return fetch(event.request).then(function(networkResponse) {
        cache.put(event.request, networkResponse.clone());
        return networkResponse;
      }).catch(function() {
        return caches.match(event.request);
      });
    })
  )
});

如上程式碼,我們使用fetch事件監聽所有的請求,然後開啟快取後,我們先請網路請求,請求成功後,返回最新的內容,此時此刻同時把該返回的內容克隆一份放入快取裡面去。但是當網路異常的情況下,我們就匹配快取裡面最新的資料。但是在這種情況下,如果我們第一次網路請求失敗後,由於第一次我們沒有做快取,因此快取也會失敗,最後就會顯示失敗的頁面了。

3. 快取優先,網路作為回退方案,並頻繁更新快取

對於一些經常改變的資原始檔,我們可以先快取優先,然後再網路作為回退方案,也就是說先快取裡面找到,也總會從網路上請求資源,這種模式可以先使用快取快速響應頁面,同時會重新請求來獲取最新的內容來更新快取,在我們使用者下次請求該資源的時候,那麼它就會拿到快取裡面最新的資料了,這種模式是將快速響應和最新的響應模式相結合。

因此我們的程式碼改成如下:

self.addEventListener('fetch', function(event) {
  event.respondWith(
    caches.open("cache-name").then(function(cache) {
      return cache.match(event.request).then(function(cachedResponse) {
        var fetchPromise = fetch(event.request).then(function(networkResponse) {
          cache.put(event.request, networkResponse.clone());
          return networkResponse;
        });
        return cachedResponse || fetchPromise;
      });
    })
  )
});

如上程式碼,我們首先開啟一個快取,然後我們試圖匹配請求,不管是否匹配成功,我們都會進入then函式,在該回調函式內部,會先重新請求一下,請求成功後,把最新的內容返回回來,並且以此同時把該請求數的資料克隆一份出來放入快取裡面去。最後把請求的資原始檔返回儲存到 fetchPromise 該變數裡面,最後我們先返回快取裡面的資料,如果快取裡面沒有資料,我們再返回網路fetchPromise 返回的資料。

如上就是我們3種常見的模式。下面我們就需要來規劃我們的快取策略了。

回到頂部

四:規劃快取策略

在我們之前講解的demo中(https://www.cnblogs.com/tugenhua0707/p/11148968.html), 都是基於網路優先,快取作為回退方案模式的。我們之前使用這個模式給使用者體驗還是挺不錯的,首先先請求網路,當網路斷開的時候,我們從快取裡面拿到資料。
這樣就不會使頁面異常或空白。但是上面我們已經瞭解到了快取了,我們可以再進一步優化了。

我們現在可以使用離線優先的方式來構建我們的應用程式了,對應我們專案經常會改變的資源我們優先使用網路請求,如果網路不可以用的話,我們使用快取裡面的資料。

首先還是看下我們專案的整個目錄結構如下:

|----- 專案
|  |--- public
|  | |--- js               # 存放所有的js
|  | | |--- main.js        # js入口檔案
|  | |--- style            # 存放所有的css
|  | | |--- main.styl      # css 入口檔案
|  | |--- index.html       # index.html 頁面
|  | |--- images
|  |--- package.json
|  |--- webpack.config.js
|  |--- node_modules
|  |--- sw.js

我們的首頁 index.html 程式碼如下:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>service worker 實列</title>
  <link rel="stylesheet" href="/main.css" />
</head>
<body>
  <div id="app">22222</div>
  <img src="/public/images/xxx.jpg" />
  <script type="text/javascript" src="/main.js"></script>
</body>
</html>

首頁是由靜態的index.html 組成的,它一般很少會隨著版本的改變而改變的,它頁面中會請求多個圖片,請求多個css樣式,和請求多個js檔案。在index.html中所有的靜態資原始檔(圖片、css、js)等在我們的service worker安裝過程中會快取下來的,那麼這些資原始檔適合的是 "快取優先,網路作為回退方案" 模式來做。這樣的話,頁面載入會更快。

但是index.html呢?這個頁面一般情況下很少改變,我們一般會想到 "快取優先,網路作為回退方案" 來考慮,但是如果該頁面也改動了程式碼呢?我們如果一直使用快取的話,那麼我們就得不到最新的程式碼了,如果我們想我們的index.html拿到最新的資料,我們不得不重新更新我們的service worker,來獲取最新的快取檔案。但是我們從之前的知識點我們知道,在我們舊的service worker 釋放頁面的同時,新的service worker被啟用之前,頁面也不是最新的版本的。必須要等第二次重新重新整理頁面的時候才會看到最新的頁面。那麼我們的index.html頁面要如何做呢?

1) 如果我們使用 "快取優先,網路作為回退方案" 模式來提供服務的話,那麼這樣做的話,當我們改變頁面的時候,它就有可能不會使用最新版本的頁面。

2)如果我們使用 "網路優先,快取作為回退方案 " 模式來做的話,這樣確實可以通過請求來顯示最新的頁面,但是這樣做也有缺點,比如我們的index.html頁面沒有改過任何東西的話,也要從網路上請求,而不是從快取裡面讀取,導致載入的時間會慢一點。

3) 使用 快取優先,網路作為 回退方案,並頻繁更新快取模式。該模式總是從快取裡面讀取 index.html頁面,那麼它的響應時間相對來說是非常快的,並且從快取裡面讀取頁面後,我們同時會請求下,然後返回最新的資料,我們把最新的資料來更新快取,因此我們下一次進來頁面的時候,會使用最新的資料。

因此對於我們的index.html頁面,我們適合使用第三種方案來做。

因此對於我們這個簡單的專案來講,我們可以總結如下:

1. 使用 "快取優先,網路作為回退方案,並頻繁更新快取" 模式來返回index.html檔案。
2. 使用 "快取優先,網路作為回退方案" 來返回首頁需要的所有靜態檔案。

因此我們可以使用上面兩點,來實現我們的快取策略。

回到頂部

五:實現快取策略

現在我們來更新下我們的 sw.js 檔案,該檔案來快取我們index.html,及在index.html使用到的所有靜態資原始檔。

index.html 程式碼改成如下:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>service worker 實列</title>
</head>
<body>
  <div id="app">22222</div>
  <img src="/public/images/xxx.jpg" />
</body>
</html>

js/main.js 程式碼變為如下:

// 載入css樣式
require('../styles/main.styl');

if ("serviceWorker" in navigator) {
  navigator.serviceWorker.register('/sw.js', {scope: '/'}).then(function(registration) {
    console.log("Service Worker registered with scope: ", registration.scope);
  }).catch(function(err) {
    console.log("Service Worker registered failed:", err);
  });
}

sw.js 程式碼變成如下:

var CACHE_NAME = "cacheName";

var CACHE_URLS = [
  "/public/index.html",      // html檔案
  "/main.css",               // css 樣式表
  "/public/images/xxx.jpg",  // 圖片
  "/main.js"                 // js 檔案 
];

// 監聽 install 事件,把所有的資原始檔快取起來
self.addEventListener("install", function(event) {
  event.waitUntil(
    caches.open(CACHE_NAME).then(function(cache) {
      return cache.addAll(CACHE_URLS);
    })
  )
});

// 監聽fetch事件,監聽所有的請求

self.addEventListener("fetch", function(event) {
  var requestURL = new URL(event.request.url);
  console.log(requestURL);
  if (requestURL.pathname === '/' || requestURL.pathname === "/index.html") {
    event.respondWith(
      caches.open(CACHE_NAME).then(function(cache) {
        return cache.match("/index.html").then(function(cachedResponse) {
          var fetchPromise = fetch("/index.html").then(function(networkResponse) {
            cache.put("/index.html", networkResponse.clone());
            return networkResponse;
          });
          return cachedResponse || fetchPromise;
        })
      })
    )
  } else if (CACHE_URLS.includes(requestURL.href) || CACHE_URLS.includes(requestURL.pathname)) {
    event.respondWith(
      caches.open(CACHE_NAME).then(function(cache) {
        return cache.match(event.request).then(function(response) {
          return response || fetch(event.request);
        });
      })
    )
  } 
});

self.addEventListener("activate", function(e) {
  e.waitUntil(
    caches.keys().then(function(cacheNames) {
      return Promise.all(
        cacheNames.map(function(cacheName) {
          if (CACHE_NAME !== cacheName && cacheName.startWith("cacheName")) {
            return caches.delete(cacheName);
          }
        })
      )
    })
  )
});

如上程式碼中的fetch事件,var requestURL = new URL(event.request.url);console.log(requestURL); 列印資訊如下所示:

如上我們使用了 new URL(event.request.url) 來決定如何處理不同的請求。且可以獲取到不同的屬性,比如host, hostname, href, origin 等這樣的資訊到。

如上我們監聽 fetch 事件中所有的請求,判斷 requestURL.pathname 是否是 "/" 或 "/index.html", 如果是index.html 頁面的話,對於 index.html 的來說,使用上面的原則是:使用 "快取優先,網路作為回退方案,並頻繁更新快取", 所以如上程式碼,我們首先開啟我們的快取,然後使用快取匹配 "/index.html",不管匹配是否成功,都會進入then回撥函式,然後把快取返回,在該函式內部,我們會重新請求,把請求最新的內容儲存到快取裡面去,也就是說更新我們的快取。當我們第二次訪問的時候,使用的是最新快取的內容。

如果我們請求的資原始檔不是 index.html 的話,我們接著會判斷下,CACHE_URLS 中是否包含了該資原始檔,如果包含的話,我們就從快取裡面去匹配,如果快取沒有匹配到的話,我們會重新請求網路,也就是說我們對於頁面上所有靜態資原始檔話,使用 "快取優先,網路作為回退方案" 來返回首頁需要的所有靜態檔案。

因此我們現在再來訪問我們的頁面的話,如下所示:

如上所示,我們可以看到,我們第一次請求的時候,載入index.html 及 其他的資原始檔,我們可以從上圖可以看到 載入時間的毫秒數,雖然從快取裡面讀取第一次資料後,但是由於我們的index.html 總是會請求下,把最新的資源再返回回來,然後更新快取,因此我們可以看到我們第二次載入index.html 及 所有的service worker中的資原始檔,可以看到第二次的載入時間更快,並且當我們修改我們的index.html 後,我們重新整理下頁面後,第一次還是從快取裡面讀取最新的資料,當我們第二次重新整理的時候,頁面才會顯示我們剛剛修改的index.html頁面的最新頁面了。因此就驗證了我們之前對於index.html 處理的邏輯。

使用 快取優先,網路作為 回退方案,並頻繁更新快取模式。該模式總是從快取裡面讀取 index.html頁面,那麼它的響應時間相對來說是非常快的,並且從快取裡面讀取頁面後,我們同時會請求下,然後返回最新的資料,我們把最新的資料來更新快取,因此我們下一次進來頁面的時候,會使用最新的資料。
github簡單的demo