移動PWA初探

在去年上海舉辦的2017谷歌開發者大會上，PWA作爲會議的一個重要內容被推介，筆者作爲參會嘉賓看了PWA的內容後，覺得這種技術會是未來移動發展的一個趨勢。Google開發技術推廣工程師Michael Yeung介紹稱，新浪微博正在打造一款全新體驗的Web Mobile PWA應用，讀者可以通過微博提供的PWA版訪問網址：m.weibo.cn/beta。

在當前的移動跨平臺開發方案中，主要的技術有PWA和Weex、RN（這個筆者在16年專門進行了研究，並出版了相關的書籍）。不過縱觀這些移動技術可以發現，PWA是優化web app，RN是用web調用native思路，weex還是使用web棧調用native的思路。

在移動碎片化嚴重的當前，如何制定一個統一的標準，纔是爲了移動技術發展的方向，也就是說：“Web不會趨向於Native，而是Native趨向於Web”。

PWA簡介

PWA全稱Progressive Web Apps（漸進式網絡應用），該項目由谷歌在2015年主導推出，主要的特性是讓Web App的體驗能更接近原生應用，顯著提高應用加載速度，甚至可以在離線狀態下運行，多種手機/PC瀏覽器已支持加載PWA網頁。

所謂的P（Progressive）這裏有兩層含義，一方面是漸進增強，讓WEB APP的體驗和功能能夠用漸進增強的方式來更接近原生APP的體驗及功能；另一方面是指下一代WEB技術，PWA並不是描述一個技術，而是一些技術的合集。PWA 本質上是 Web App，藉助一些新技術也具備了 Native App 的一些特性，兼具 Web App 和 Native App 的優點。

PWA 的主要特點包括下面三點：

可靠 - 即使在不穩定的網絡環境下，也能瞬間加載並展現

體驗 - 快速響應，並且有平滑的動畫響應用戶的操作

粘性 - 像設備上的原生應用，具有沉浸式的用戶體驗，用戶可以添加到桌面

PWA 本身強調漸進式，並不要求一次性達到安全、性能和體驗上的所有要求，開發者可以通過 PWA Checklist 查看現有的特徵。

PWA特性

下面就從安全、性能和體驗三個方面來介紹PWA所具有的特性。

可靠

當用戶打開我們站點時（從桌面 icon 或者從瀏覽器），通過 Service Worker 能夠讓用戶在網絡條件很差的情況下也能瞬間加載並且展現。

Service Worker 是用 JavaScript 編寫的 JS 文件，能夠代理請求，並且能夠操作瀏覽器緩存，通過將緩存的內容直接返回，讓請求能夠瞬間完成。開發者可以預存儲關鍵文件，可以淘汰過期的文件等等，給用戶提供可靠的體驗。

更詳細的內容可以訪問： Service Worker

體驗

如果站點加載時間超過 3s，53% 的用戶會放棄等待。頁面展現之後，用戶期望有平滑的體驗，過渡動畫和快速響應。

爲了保證首屏的加載，我們需要從設計上考慮，在內容請求完成之前，可以優先保證 App Shell 的渲染，做到和 Native App 一樣的體驗，App Shell 是 PWA 界面展現所需的最小資源。

更多的資料可以參考： App Shell 設計規範

粘性

PWA具有的粘性表現在如下幾個方面：

• PWA 是可以安裝的，用戶點擊安裝到桌面後，會在桌面創建一個 PWA 應用，並且不需要從應用商店下載；
• PWA 可以藉助 Web App Manifest 提供給用戶和 Native App 一樣的沉浸式體驗；
• PWA 可以通過給用戶發送離線通知，讓用戶迴流。

同時，Web App Manifest 允許開發者控制 PWA 添加到桌面，允許定製桌面圖標、URL等等。

關於Web App Manifest更多的內容可以參考：Web App Manifest和Push Notification。

其他

除此之外，講到 PWA 兼具 Web App 和 Native App 的特徵的，Web App 無版本問題、可索引也是很重要的特性。

總結一下，PWA 具有下面一些特性：

• 漸進式 - 適用於所有瀏覽器，因爲它是以漸進式增強作爲宗旨開發的。
• 連接無關性 - 能夠藉助 Service Worker 在離線或者網絡較差的情況下正常訪問。
• 類似應用 - 由於是在 App Shell 模型基礎上開發，因爲應具有 Native App 的交互和導航，給用戶 Native App的體驗。
• 持續更新 - 始終是最新的，無版本和更新問題。
• 安全 - 通過 HTTPS 協議提供服務，防止窺探和確保內容不被篡改。
• 可索引 - 應用清單文件和 Service Worker 可以讓搜索引擎索引到，從而將其識別爲『應用』。
• 粘性 - 通過推送離線通知等，可以讓用戶迴流。
• 可安裝 - 用戶可以添加常用的 webapp 到桌面，免去去應用商店下載的麻煩。
• 可鏈接 - 通過鏈接即可分享內容，無需下載安裝。

PWA 是對站點體驗的一個飛躍式的提升，可以在移動設備上的 Chrome(version > 52) 訪問 天氣PWA 體驗一下。

漸進式

所謂漸進式，就是逐步的改善，不是一蹴而就的，採取這種方案，主要有兩點原因：

• 降低站點改造的代價，逐步支持各項新技術，不要一蹴而就；
• 新技術標準的支持度還不完全，新技術的標準還未完全確定。

所以，從改造的成本考慮，我們也建議採取漸進式的方式，可以考慮按照下面的步驟來改造：

• 第一步，應該是安全，將全站 HTTPS 化，因爲這是 PWA 的基礎，沒有 HTTPS，就沒有 Service Worker
• 第二步，應該是 Service Worker 來提升基礎性能，離線提供靜態文件，把用戶首屏體驗提升上來
• 第三步，App Manifest，這一步可以和第二步同時進行 後續，再考慮其他的特性，離線消息推送等

同時，PWA作爲最新的不太成熟的技術，當前瀏覽器還沒有達到完全支持的程度，W3C 關於這些技術的標準也還在處於草稿狀態，沒有定稿。根據知名統計網站Can I use的統計，對PWA相關技術的支持程度如下：

• App Manifest 的支持度達到 57.43%；
• Service Worker 的支持度達到 72.82%；
• Notifications API 的支持度達到 43.3%；
• Push API 的支持度達到 72.39%；
• Background Sync 暫未統計到，Chrome 49 以上均支持。

比較遺憾的是上面提到的所有技術，目前只有 Android 的部分瀏覽器支持，iOS 的Safari暫不支持，不過，Safari 瀏覽器已經在考慮了。

Service Worker

W3C 組織早在 2014 年 5 月就提出過 Service Worker 這樣的一個 HTML5 API ，主要用來做持久的離線緩存。對於API相關的內容，這裏仔細整理了一下：瀏覽器中的 javaScript 都是運行在一個單一主線程上的，在同一時間內只能做一件事情。隨着 Web 業務不斷複雜，我們逐漸在 js 中加了很多耗資源、耗時間的複雜運算過程，這些過程導致的性能問題在 WebApp 的複雜化過程中更加凸顯出來。

W3C 組織早早的洞察到了這些問題可能會造成的影響，這個時候有個叫 Web Worker 的 API 被造出來了，這個 API 的唯一目的就是解放主線程，Web Worker 是脫離在主線程之外的，將一些複雜的耗時的活交給它幹，完成後通過 postMessage 方法告訴主線程，而主線程通過 onMessage 方法得到 Web Worker 的結果反饋。

一切問題好像是解決了，但 Web Worker 是臨時的，我們能不能有一個東東是一直持久存在的，並且隨時準備接受主線程的命令呢？基於這樣的需求推出了最初版本的 Service Worker ，Service Worker 在 Web Worker 的基礎上加上了持久離線緩存能力。當然在 Service Worker 之前也有在 HTML5 上做離線緩存的 API 叫 AppCache, 但是 AppCache 存在很多 不能忍受的缺點。

W3C 決定 AppCache 仍然保留在 HTML 5.0 Recommendation 中，在 HTML 後續版本中移除。

Issue: https://github.com/w3c/html/issues/40

Mailing list: https://lists.w3.org/Archives/Public/public-html/2016May/0005.html

WHATWG HTML5 作爲 Live Standard，也將 AppCache 標註爲 Discouraged 並引導至 Service Worker。Ok ，那麼 Service Worker 到底用來幹啥的呢？

Service Worker 有以下功能和特性：

• 一個獨立的 worker 線程，獨立於當前網頁進程，有自己獨立的 worker context。
• 一旦被 install，就永遠存在，除非被 uninstall。
• 需要的時候可以直接喚醒，不需要的時候自動睡眠（有效利用資源，此處有坑）。
• 可編程攔截代理請求和返回，緩存文件，緩存的文件可以被網頁進程取到（包括網絡離線狀態）。
• 離線內容開發者可控。
• 能向客戶端推送消息。
• 不能直接操作 DOM。
• 出於安全的考慮，必須在 HTTPS 環境下才能工作。
• 異步實現，內部大都是通過 Promise 實現。

所以我們基本上知道了 Service Worker 的偉大使命，就是讓緩存做到優雅和極致，讓 Web App 相對於 Native App 的缺點更加弱化，也爲開發者提供了對性能和體驗的無限遐想。

瀏覽器Service Worker支持情況

根據Can I use發現，目前市場上對Service Worker的支持情況如下：

從這張圖可以發現，Chrome 作爲開路先鋒早早的在 V40 版本就支持了，還提供了完善的 debug 方案（ Service Worker debug ）；Firefox，Opera 不甘示弱在後續版本也進行了支持；安卓手機 4.x 以上版本新系統形勢一片大好（具體各手機的實現還得進一步探測）；安卓 Chrome 同樣給力；但是目前IE和Safair是不支持的，不過已經被列入未來的支持計劃中。

Service Worker使用

Service Worker 出於安全性和其實現原理，在使用的時候有一定的前提條件。

• 由於 Service Worker 要求 HTTPS 的環境，我們通常可以藉助於 github page 進行學習調試。當然一般瀏覽器允許調試 Service Worker 的時候 host 爲 localhost 或者 127.0.0.1 也是 ok 的。
• Service Worker 的緩存機制是依賴 Cache API 實現的。
• 依賴 HTML5 fetch API。
• 依賴 Promise 實現。

Service Worker註冊

要安裝 Service Worker， 我們需要通過在 js 主線程（常規的頁面裏的 js ）註冊 Service Worker 來啓動安裝，這個過程將會通知瀏覽器我們的 Service Worker 線程的 javaScript 文件在什麼地方呆着。先看一段代碼： 、`if ('serviceWorker' in navigator) { window.addEventListener('load', function () { navigator.serviceWorker.register('/sw.js', {scope: '/'}) .then(function (registration) {

            // 註冊成功
            console.log('ServiceWorker registration successful with scope: ', registration.scope);
        })
        .catch(function (err) {

            // 註冊失敗:(
            console.log('ServiceWorker registration failed: ', err);
        });
});

}`