前端應當曉得的PWA

2019年8月24日 99次阅读 来源: 瀟湘待雨

一、傳統web 運用

當前web運用在挪動時期並沒有到達其在桌面裝備上盛行的水平，下面有張圖來對照與原生運用之間的差異。
《前端應當曉得的PWA》
究其原因，無外乎下面不可避免的幾點：

  • 挪動裝備收集限定-不可疏忽的加載時刻
  • web運用依靠於瀏覽器作為進口
  • 體驗與原生的差異

假如能處置懲罰以上的幾點，對web app 來講會有多大的提拔可以設想。

二、PWA是什麼

PWA 全稱Progressive Web Apps(漸進式Web運用程序)，旨在運用現有的web手藝供應用戶更優的運用體驗。
基本要求

  • 牢靠（Reliable）
    縱然在不穩定的收集環境下，也能霎時加載並展現
  • 疾速響應（Fast）
    疾速響應，而且有膩滑的動畫響運用戶的操縱
  • 粘性(Engaging)
    像裝備上的原生運用，具有沉醉式的用戶體驗，用戶可以增加到桌面

PWA 自身強調漸進式，並不要求一次性到達平安、機能和體驗上的一切要求，開闢者可以經由歷程 PWA Checklist 檢察現有的特徵。

除以上的基準要求外，還應該包含以下特徵：

  • 漸進式 – 適用於一切瀏覽器，因為它是以漸進式加強作為主旨開闢的
  • 銜接無關性 – 可以藉助 Service Worker 在離線或許收集較差的狀況下平常接見
  • 相似運用 – 由因而在 App Shell 模子基礎上開闢，因為應具有 Native App 的交互和導航，給用戶 Native App 的體驗
  • 延續更新 – 始終是最新的，無版本和更新題目
  • 平安 – 經由歷程 HTTPS 協定供應效勞，防備窺伺和確保內容不被改動
  • 可索引 – 運用清單文件和 Service Worker 可以讓搜索引擎索引到，從而將其識別為『運用』
  • 粘性 – 經由歷程推送離線關照等，可以讓用戶迴流
  • 可裝置 – 用戶可以增加經常使用的 webapp 到桌面，免去去運用市肆下載的貧苦
  • 可鏈接 – 經由歷程鏈接即可分享內容，無需下載裝置

看起來有點頭昏眼花，這又是一個新的飛起的輪子嗎？這裏重申一下,PWA背地不是一種新的手藝，而是鳩合當前多種web手藝的一種鳩合。離別應用各自的功用來完成漸進式的團體需求。下面就沿着前面提出的題目離別相識一下相干手藝

三、手藝組成

由以下幾種手藝組成：

  • App Manifest
  • Service Worker
  • Notifications API
  • Push API

个中Service Worker是PWA手藝的癥結，它們可以讓app滿足上面的三基準。其他手藝則是如虎添翼，讓app越發的壯大。

3.1 service worker背景

離線緩存背景

針對網頁的體驗，夙昔到后都做了許多勤奮，儘力去下降響應時刻，這裏就不表述多樣的手藝手段。
另一個方向的就是緩存，削減與效勞器非必要的交互，不過關於離線的狀況下瀏覽器緩存就無力了，
如許離線緩存的需求就湧現了。

離線緩存的進程

web運用在離線緩存生長的歷程當中也不是一簇而就的，閱歷了逐步完美的歷程。
初期的處置懲罰方案是AppCache
然則，事實證明這是一個失利的嘗試，缺點太多，已被燒毀了。詳細可以檢察Application Cache is a douchebag
然則方向照樣準確的，那就繼承廢寢忘食的探究。

workers

耐久化先放一邊，來談談另一個題目
基於瀏覽器中的 javaScript 單線程的實際逐步不能滿足當代web需求的近況,比方耗時的盤算，用戶的交互明顯會受影響。
為了將這些耗時操縱從主線程中解放出來，初期W3C新增了一個Web Worker 的 API，可以離開主線程零丁實行，而且可以與主線程交互。
不過Web Worker是臨時性的依靠於建立頁面 ，不能滿足我們耐久化的需求。
衝著這個目標，下面就比較輕易處置懲罰了，搞個能耐久存在的就好了。
在Web Worker的基礎上，W3C新增了service worker來滿足我們耐久化的需求。
其生命周期與頁面無關，關聯頁面未封閉時，它也可以退出，沒有關聯頁面時，它也可以啟動
功用

Service Worker雖然滿足了離線緩存來，其功用可不僅僅局限於此。 可以供應

  • 雄厚的離線體驗，
  • 周期的背景同步，
  • 音訊推送關照，
  • 阻攔和處置懲罰收集要求，
  • 治理資本緩存

這些恰好也是PWA的目標，所以說Service Worker是PWA的癥結手藝。

前提前提

Service Worker 出於平安性和其完成道理，在運用的時刻有肯定的前提前提。

  • 因為 Service Worker 要求 HTTPS 的環境
    固然平常瀏覽器許可調試 Service Worker 的時刻 host 為 localhost 或許 127.0.0.1
  • Service Worker 的緩存機制是依靠 Cache API (略過)
  • 依靠 HTML5 fetch API（略過）
  • 依靠 Promise 完成

由上可知，不是一切的瀏覽器都支撐的，支撐狀況也許以下：

《前端應當曉得的PWA》
iOS 內的一切的瀏覽器都基於 safari，所以iOS要在11.3以上
IE是摒棄支撐了，不過Edge好歹支撐了。

3.2 Cache

Cache是Service Worker衍生出來的API，合營Service Worker完成對資本要求的緩存。
不過cache並不直接緩存字符串，而是直接緩存資本要求（css、js、html等）。
cache也是key-value情勢，平常來講key就是request，value就是response

  • caches.open(cacheName) 翻開一個cache
  • caches是global對象，返回一個帶有cache返回值的Promise
  • cache.keys() 遍歷cache中一切鍵，獲得value的鳩合
  • cache.match(Request|url) 在cache中婚配傳入的request，返回Promise；
  • cache.matchAll只要第一個參數與match差別，須要一個request的數組，固然返回的效果也是response的數組
  • cache.add(Request|url) 並非純真的add，因為傳入的是request或許url，在cache.add內部會自動去挪用fetch取回request的要求效果，然後才是把response存入cache；
  • cache.addAll相似，通常在sw install的時刻用cache.addAll把一切須要緩存的文件都要求一遍
  • cache.put(Request, Response) 這個相當於cache.add的第二步，即fetch到response后存入cache
  • cache.delete(Request|url) 刪除緩存

3.3 註冊Service Worker

註冊即聲明sw文件的位置，明顯應該在主js中引入。也許以下：

//基於promise
function registerServiceWorker(){
    // 註冊service worker
    return navigator.serviceWorker.register('./sw1.js').then(registration => {
        console.log('註冊勝利');
        // 返回
        return registration;
    })
    .catch(err => {
        console.error('註冊失利', err);
    });
}
window.onload = function () {
    //是不是支撐
    if (!('serviceWorker' in navigator)) {
        return;
    }
    registerServiceWorker()
}

3.4 生命周期

Service worker 有一個獨立於web 頁面的生命周期。
假如在網站上裝置 serice worker ，你須要註冊，註冊后瀏覽器會在背景裝置 service worker。然後進入下面的差別階段。
激活以後，service worker 將掌握一切的頁面，歸入它的局限，不過第一次在頁面註冊 service worker 時不會掌握頁面，直到它再次加載。
service worker 見效以後,它會處於下面兩種狀況之一：

  • service worker 住手來節約內存，
  • 頁面提議收集要求后，它將處置懲罰要求獵取和音訊事宜。

由上圖看知，分為這麼幾個階段：

  • Installing
    發作在 Service Worker 註冊以後，示意最先裝置，觸發 install 事宜回調指定一些靜態資本舉行離線緩存
  • Installed
    Service Worker 已完成了裝置，而且守候其他的 Service Worker 線程被封閉。
  • Activating
    在這個狀況下沒有被其他的 Service Worker 掌握的客戶端，許可當前的 worker 完成裝置
  • Activated
    在這個狀況會處置懲罰 activate 事宜回調 (供應了更新緩存戰略的時機)。並可以處置懲罰功用性的事宜 fetch (要求)、sync (背景同步)、push (推送)
  • Redundant
    被替代，即被燒毀

相識聲明周期實在是為了我們在差別時刻段去監聽事宜來完成響應操縱。對PWA來講主要兩個事宜。

  • install 事宜回調：

event.waitUntil()：傳入一個 Promise 為參數，比及該 Promise 為 resolve 狀況為止。
self.skipWaiting()：self 是當前 context 的 global 變量，實行該要領示意強迫當前處在 waiting 狀況的 Service Worker 進入 activate 狀況。

  • activate 回調：

event.waitUntil()：傳入一個 Promise 為參數，比及該 Promise 為 resolve 狀況為止。
self.clients.claim()：在 activate 事宜回調中實行該要領示意獲得頁面的掌握權, 如許以後翻開頁面都邑運用版本更新的緩存。舊的 Service Worker 劇本不再掌握着頁面，以後會被住手。

const CURCACHE = 'CURCACHE_test_1'
const RUNTIME = 'runtime';
const CURCACHE_URLS = [
    './',
    '/asset/sw.jpg',
    'index.js'
]
self.addEventListener('install',e=>{
    e.waitUntil(
      //存儲緩存途徑對應的資本
        caches.open(CURCACHE).then(cache=>{
            cache.addAll(CURCACHE_URLS)
        }).then(
            self.skipWaiting()
        )
    )
})
 
 
   
  //代辦要求，運用緩存，要求發送之前
  self.addEventListener('fetch', e => {
    e.respondWith(
      //緩存是不是婚配 
      caches.match(e.request).then(function(response) {
        if (response != null) {
          //擲中緩存返回緩存，完畢要求
          return response
        }
        //未擲中緩存，平常要求
        return fetch(e.request.url)
      })
    )
  });

更新service worker
service worker 更新步驟以下：

  • 更新 service worker 的文件
    網頁翻開時效勞器會舉行對照，堅持最新
  • 新的 service worker 啟動install
  • 當前頁面見效的依舊是老的service worker，新的 service worker 會進入 “waiting” 狀況。
  • 頁面封閉以後，老的 service worker 會被幹掉，新的 servicer worker 接受頁面
  • 新的 service worker 見效後會觸發 activate 事宜。
const CURCACHE = 'precache_test_1'
//假定上個版本的key為precache_test_2 橫豎不即是CURCACHE
self.addEventListener('activate', e => {
  e.waitUntil(
      //遍歷當前緩存keys
      caches.keys().then(cacheNames=>{
        return Promise.all(
          cacheNames.map(function(cacheName) {
            //是不是即是當前key,保存本身
            if (cacheName !== CURCACHE) {
              return caches.delete(cacheName);
            }
          })
    )}).then(() => self.clients.claim())
 )
})

如許一個簡樸的service worker離線緩存完成了。掌握台可以看到，泉源是service worker

《前端應當曉得的PWA》
封閉收集以後再次接見，可以一樣獲得上面的效果，而且sw.js要求未能拿到，然則不影響，舊的文件依舊在，這裏證明了每次都回去對照sw文件以確保更新
《前端應當曉得的PWA》
到這裏，離線緩存就完成了。

四、增加到主屏幕

許可將站點增加至主屏幕，是 PWA 供應的一項主要功用。如許就不必再依靠於瀏覽器作為平台，相符挪動端的用戶習氣。

manifest.json

須要 manifest.json 文件去設置運用的圖標、稱號等基本信息以下：

{
    //被提醒裝置運用時湧現的文本
    "name": "PQJ-PWA",
    //增加至主屏幕後的文本
    "short_name":"PQJ",
    "description": "測試demo",
    //增加以後，啟動地點
    "start_url": "/index.html",
    //圖標信息
    "icons": {
      "128": "/asset/sw.jpg"
    },
    "developer": {
      "name": "pqj",
      "url": ""
    },
    "display": "standalone",
    "background_color": "#287fc5",
    "theme_color": "#fff",
    "permissions": {
        "desktop-notification": {
          "description": "Needed for creating system notifications."
        }
      }
}

然後以以下體式格局在html中引入

<link rel="manifest" href="/mainfest.json" />

如許完成以後，挪動端安卓運用chrome(親測),初次接見時會提醒是不是許可裝置到主屏幕，以運用icon的情勢湧現。
圖片和筆墨即由設置決議。

五、音訊關照

音訊關照也是運用service worker的關照功用舉行的，許可效勞器想用戶發作關照，而非用戶主動要求才去響應某些行動。
平常的關照邏輯須要效勞器來介入完成，此次展現只完勝利用。

  • 起首請求關照權限
  • 註冊service worker
  • 處置懲罰邏輯，發送關照
function getPermission(){
    return new Promise((resolve, reject) => {
        //權限獵取
        const permissionPromise = Notification.requestPermission(result => {
            resolve(result);
        });
    }).then(result => {
            //推斷前提
            if (result === 'granted') {
                execute();
            }
            else {
                console.log('no permission');
            }
        });
}

發送關照

function execute() {
    // 許可以後實行
    registerServiceWorker().then(registration => {
        // 關照
        registration.showNotification('Hello World!');
    });
}

完畢語

參考文檔

https://lavas.baidu.com/doc
https://developer.mozilla.org/zh-CN/Apps/Progressive

至此，本文引見就完畢了，更多請參考實例雖然PWA現在來看，面臨的限定還許多，然則也可以看出web構造在更好的提拔web運用方向上做的勤奮。正如一向提到的那句話，將來可期。
現在國內百度這方面做的比較成熟，新浪微博已有了pwa 測試版。

    原文作者：瀟湘待雨
    原文地址: https://segmentfault.com/a/1190000014836471
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞