作者 | 彭星
編輯 | 尾尾

一、回顧歷史：移動(dòng)時(shí)代之初，Web遭遇兩大枷鎖

Web 在移動(dòng)時(shí)代遭遇兩大枷鎖1.Web 在移動(dòng)時(shí)代遭遇兩大枷鎖

當(dāng) Web 自信滿(mǎn)滿(mǎn)，步入移動(dòng)時(shí)代之時(shí)，它還沒(méi)有做好充足的準(zhǔn)備。

回顧 2014 到 2015 年那段時(shí)間，作為前端開(kāi)發(fā)人員，我正忙著前后端分離和體驗(yàn)優(yōu)化。那時(shí)，我投入精力最多的就是移動(dòng)站點(diǎn)的體驗(yàn)優(yōu)化，例如提升首屏速度，提升動(dòng)畫(huà)流暢性等。為了達(dá)到更好的優(yōu)化效果，我心力憔悴，HTTP 緩存、HTTP2 等一些優(yōu)化技術(shù)都用上了，但體驗(yàn)依然比 Native App 差很多，始終無(wú)法突破移動(dòng)設(shè)備上瀏覽器（和 WebView） 給 Web 帶來(lái)的 用戶(hù)體驗(yàn)枷鎖。

除開(kāi) Web App 的體驗(yàn)問(wèn)題，還有一個(gè)很重要的問(wèn)題制約著 Web 在移動(dòng)時(shí)代的發(fā)展，那就是第二個(gè)枷鎖——用戶(hù)留存枷鎖。Native App 在安裝完成之后會(huì)在桌面上有一個(gè)入口，后續(xù)用戶(hù)觸達(dá) App 只有一步，而 Web App 在移動(dòng)時(shí)代最主要的入口還是搜索引擎，用戶(hù)從瀏覽器到站點(diǎn)需要經(jīng)過(guò)搜索引擎，還需要記住和輸入上次搜索的內(nèi)容。當(dāng)然，用戶(hù)還可以直接輸入站點(diǎn) URL 地址，但這對(duì)于移動(dòng)用戶(hù)來(lái)說(shuō)，無(wú)疑成本巨大，這就導(dǎo)致用戶(hù)和 Web 站點(diǎn)之間的粘性非常脆弱。

兩大枷鎖禁錮了 Web 在移動(dòng)端的發(fā)展，雖然移動(dòng) Web 可以觸達(dá)的用戶(hù)是 App 的三倍之多，但用戶(hù)的留存時(shí)間卻明顯少于在 App 上的留存時(shí)間，參考 What is Progressive web App (and Why Should You Care)：
https://codeburst.io/what-is-progressive-web-app-and-why-should-you-care-e397e24b1257


對(duì)比下來(lái)，互聯(lián)網(wǎng)公司更愿意投入人力在 Native App 的開(kāi)發(fā)上，而忽略 Web。因此，Native App 順勢(shì)迅速成長(zhǎng)起來(lái)，大量的需求出現(xiàn)了，也吸引了各類(lèi)培訓(xùn)機(jī)構(gòu)開(kāi)啟相關(guān) NA 開(kāi)發(fā)的課程，吸引了很多人轉(zhuǎn)做 NA 開(kāi)發(fā)，各種 Native App 的技術(shù)、教程、實(shí)踐等，也如雨后春筍般布滿(mǎn)了各大技術(shù)論壇。

2. 打造解開(kāi)枷鎖的鑰匙

對(duì)于前期的失利，Web 顯然是不甘心的。想要繼續(xù)前進(jìn)，就必須打造解開(kāi)枷鎖的鑰匙——Progressive Web App（ PWA ） 以及支撐 PWA 的一系列關(guān)鍵技術(shù)應(yīng)運(yùn)而生。

早在 2014 年， W3C 公布就公布過(guò) Service Worker 的相關(guān)草案，但是其在生產(chǎn)環(huán)境被 Chrome 支持是在 2015 年。因此，如果我們把 PWA 的關(guān)鍵技術(shù)之一 Service Worker 的出現(xiàn)作為 PWA 的誕生時(shí)間，那就應(yīng)該是 2015 年。

自 2015 年以來(lái)，PWA 相關(guān)的技術(shù)不斷升級(jí)優(yōu)化，在用戶(hù)體驗(yàn)和用戶(hù)留存兩方面都提供了非常好的解決方案。PWA 可以將 Web 和 App 各自的優(yōu)勢(shì)融合在一起：漸進(jìn)式、可響應(yīng)、可離線(xiàn)、實(shí)現(xiàn)類(lèi)似 App 的交互、即時(shí)更新、安全、可以被搜索引擎檢索、可推送、可安裝、可鏈接。

其中，App Manifest 讓 Web 站點(diǎn)能被添加到手機(jī)桌面，解決了用戶(hù)到達(dá)站點(diǎn)鏈條太長(zhǎng)的問(wèn)題；Service Worker 讓 Web 站點(diǎn)能夠離線(xiàn)狀態(tài)下正常使用，還有能讓用戶(hù)離線(xiàn)接受站點(diǎn)消息推送的 Web Push，這兩點(diǎn)非常值得關(guān)注。

3. 解開(kāi)枷鎖，劍指NA痛點(diǎn)

而與此同時(shí)，如火如荼的 Native App 卻沒(méi)能很好地彌補(bǔ)自己的劣勢(shì)。

對(duì)于 Native App 來(lái)說(shuō)，其 最大的痛點(diǎn)是由于其天生封閉的基因，內(nèi)容無(wú)法被索引，這會(huì)導(dǎo)致后續(xù)一系列的問(wèn)題。例如，用戶(hù)想知道紅燒肉的做法，還需要先知道 App 的名字，下載 App 后才能獲取內(nèi)容，這個(gè)流程是十分不合理的。而隨著移動(dòng)互聯(lián)網(wǎng)的發(fā)展，用戶(hù)下載 App 的熱情也逐漸減弱，再加上用戶(hù) 80% 的時(shí)間被 Top3 的超級(jí) App 占據(jù)，對(duì)于站點(diǎn)來(lái)說(shuō)，應(yīng)用分發(fā)成本也因此越來(lái)越高了。

相對(duì)于 Native App 的封閉，PWA 卻是完全開(kāi)放的——PWA 現(xiàn)有的所有技術(shù)都是遵循 W3C 的標(biāo)準(zhǔn)，完全開(kāi)放，因此能夠快速被站點(diǎn)接受、被瀏覽器快速支持。

值得一提的是，為了解開(kāi)傳統(tǒng) Web 的兩個(gè)枷鎖，除 PWA 之外，業(yè)界也誕生了很多技術(shù)方案，例如部分廠商推出的小程序技術(shù)。

二、細(xì)解PWA：是否能真正彌補(bǔ) Web 劣勢(shì)？

PWA 不是特指某一項(xiàng)技術(shù)，而是應(yīng)用了多項(xiàng)技術(shù)的 Web App。其核心技術(shù)包括 App Manifest、Service Worker、Web Push、Credential Management API ，等等。其核心目標(biāo)就是提升 Web App 的性能，改善 Web App 的用戶(hù)體驗(yàn)。

下面我們?cè)敿?xì)地看一下這些核心技術(shù)，是否能夠真正彌補(bǔ) Web 劣勢(shì)。

1. Web App Manifest

Web App Manifest 是為了解決用戶(hù)留存問(wèn)題而誕生的，它是一個(gè)外鏈的 JSON 文件，在這個(gè)文件中，像瀏覽器暴露了站點(diǎn)的名稱(chēng)，地址，圖標(biāo)等等元數(shù)據(jù)，可以看下面這個(gè)例子。Web App Manifest 有很多配置項(xiàng)，MDN 的文檔：
https://developer.mozilla.org/en-US/docs/Web/Manifest

{"name": "百度天氣","short_name": "天氣","icons": [{"src": "/dist/static/img/icons/android-chrome-192x192.png","sizes": "192x192","type": "image/png"}],"start_url": "/?from=homescreen","background_color": "#3E4EB8","display": "standalone","theme_color": "#2F3BA2" }

在瀏覽器中通過(guò) 引入這個(gè) JSON 文件，瀏覽器識(shí)別到這個(gè)文件的存在，會(huì)根據(jù)自己的機(jī)制決定是否彈出添加到桌面對(duì)話(huà)框，并在桌面上生成一個(gè)應(yīng)用的圖標(biāo)，通過(guò)點(diǎn)擊桌面圖標(biāo)進(jìn)入應(yīng)用具有沉浸式的體驗(yàn)，全屏顯示，沒(méi)有瀏覽器地址欄，并且還會(huì)自動(dòng)添加應(yīng)用啟動(dòng)畫(huà)面，入下圖所示。

圖片來(lái)源于《下一代 Web 應(yīng)用模型 — Progressive Web App》：

https://huangxuan.me/2017/02/09/nextgen-web-pwa/

Web App Manifest 當(dāng)前也存在一些問(wèn)題，比如 Web App Manifest 添加到桌面依賴(lài)于手機(jī)操作系統(tǒng)是否給瀏覽器開(kāi)通在桌面創(chuàng)建快捷方式的權(quán)限，目前在國(guó)內(nèi)，大部分情況下，瀏覽器的這個(gè)權(quán)限被默認(rèn)禁止，需要用戶(hù)手動(dòng)開(kāi)啟，拿小米手機(jī)為例，可以進(jìn)入設(shè)置 -> 更多應(yīng)用 -> 找到對(duì)應(yīng)的瀏覽器 -> 權(quán)限管理 -> 桌面快捷方式 -> 允許，對(duì)于大部分用戶(hù)來(lái)說(shuō)，這個(gè)操作可能過(guò)于復(fù)雜了，這也是 PWA 添加到桌面在國(guó)內(nèi)還沒(méi)有被廣泛接受的主要原因，很多廠商，包括百度在內(nèi)，都在盡力推動(dòng)手機(jī)廠商開(kāi)啟這個(gè)權(quán)限。

其他 Web App Manifest 的詳細(xì)資料可以參考 LAVAS 官網(wǎng)中 Web App Manifest 的文檔：

https://lavas.baidu.com/doc/engage-retain-users/introduction

2. Service Worker

PWA 之所以能離線(xiàn)，是 Service Worker 的功勞。這并不是 W3C 第一次嘗試讓 Web 站點(diǎn)離線(xiàn)，在 Service Worker 之前，有個(gè)東西叫 Application Cache，，是不是很熟悉？但是，由于Application Cache 存在很多無(wú)法容忍和無(wú)法解決的問(wèn)題（可以查看這篇博客 Application Cache is a Douchebag：https://alistapart.com/article/application-cache-is-a-douchebag），它在 HTML5.1 版本中被移出了。

現(xiàn)在，我們終于有一個(gè)沒(méi)有那么多問(wèn)題的離線(xiàn)方案了，那就是 Service Worker。

Service Worker 是一個(gè)特殊的 Web Worker，獨(dú)立于頁(yè)面主線(xiàn)程運(yùn)行，它能夠攔截和處理網(wǎng)絡(luò)請(qǐng)求，并且配合 Cache Storage API，開(kāi)發(fā)者可以自由的對(duì)頁(yè)面發(fā)送的 HTTP 請(qǐng)求進(jìn)行管理，這就是為什么 Service Worker 能讓 Web 站點(diǎn)離線(xiàn)的原因。

Service Worker 的工作流程如下圖所示。

Service Worker 的工作方式也衍生出了幾種不同的請(qǐng)求控制策略，networkFirst, cacheFirst, networkOnly, cacheOnly 和 fastest，對(duì)于不同類(lèi)型的請(qǐng)求，我們應(yīng)該采取不同的策略，靜態(tài)文件，我們可以選擇 cacheFirst 或者 fastest，甚至 cacheOnly，對(duì)于依賴(lài)后端數(shù)據(jù)的 AJAX 請(qǐng)求，我們應(yīng)該選擇 networkFirst 或者 networkOnly，保證數(shù)據(jù)的實(shí)時(shí)性。

Service Worker 從在瀏覽器注冊(cè)到進(jìn)入工作狀態(tài)和最終銷(xiāo)毀會(huì)經(jīng)歷不同的階段，下圖比較清楚的畫(huà)出了 Service Worker 的生命周期。

在整個(gè)生命周期中，Service Worker 會(huì)拋出不同的事件，如 install, active, fetch 等，可以通過(guò) self.addEventListener 來(lái)監(jiān)聽(tīng)。
比如，監(jiān)聽(tīng)網(wǎng)絡(luò)請(qǐng)求事件，這里我們采用的策略是 cacheFirst。

// service-worker.js self.addEventListenr('fetch', (e) => {e.respondWith(caches.match(e.request).then((response) => {return response || fetch(e.request);})); });

這里只是簡(jiǎn)單的介紹了一下 Service Worker，詳細(xì)的使用文檔可以參考 怎么使用 Service Worker。

Service Worker 它并不只是能夠緩存離線(xiàn)文件，后臺(tái)同步和 Web Push 都是依賴(lài)于 Service Worker 工作的，因此它的重要性不言而喻。

3. Push Notification

Push Notification 其實(shí)是兩個(gè) API 的結(jié)合， Notification API 和 Push API 。

Notification API 提供了開(kāi)發(fā)者可以給用戶(hù)發(fā)送通知的能力，包括申請(qǐng)顯示通知權(quán)限，發(fā)起通知，以及定制通知的類(lèi)型等等。Notification API 的歷史比較早，最早可以追溯到 2010 年，2011 年納入標(biāo)準(zhǔn)，時(shí)至今日，Notication API 已經(jīng)獲得了大多數(shù)平臺(tái)的支持，包括 Chrome, Edge, Firefox, Safari 等的支持，比較可惜的是，iOS Safari 至今還不支持。

Push API，則是讓服務(wù)器能夠向用戶(hù)發(fā)送離線(xiàn)消息，即使用戶(hù)當(dāng)前并沒(méi)有打開(kāi)你的頁(yè)面，甚至沒(méi)有打開(kāi)瀏覽器。瀏覽器在接到消息推送時(shí)，會(huì)喚醒對(duì)應(yīng)的 Service Worker，并拋出 push 事件，開(kāi)發(fā)者接收到事件之后調(diào)用 Notification API 彈出通知，這就完成了整個(gè)接受和展示的流程。

// service-worker.js self.addEventListener('push', event => {event.waitUntil(// Process the event and display a notification.self.registration.showNotification("Hey!")); });self.addEventListener('notificationclick', event => {// Do something with the eventevent.notification.close(); });self.addEventListener('notificationclose', event => {// Do something with the event });

在之前的分享和文章中，很少提及 Web Push，這并不是因?yàn)樗恢匾?#xff0c;而是因?yàn)樗趪?guó)內(nèi)被支持程度非常低，支持 Web Push 的成本比 App Manifest 或者 Service Worker 要高的多，它需要瀏覽器廠商提供消息推送服務(wù)，截止到本文截稿，國(guó)內(nèi)只有 UC 即將發(fā)布的 U2 內(nèi)核的瀏覽器才支持 Web Push API，Chrome 也因?yàn)槠湟蕾?lài)的 FCM/GCM 無(wú)法訪(fǎng)問(wèn)而導(dǎo)致 Web Push 無(wú)法使用。

瀏覽器接收到離線(xiàn)消息需要完成兩個(gè)過(guò)程：

1、瀏覽器訂閱通知

2、服務(wù)器發(fā)送通知

瀏覽器訂閱通知，是指開(kāi)發(fā)者調(diào)用 API 在消息服務(wù)器注冊(cè)，具體過(guò)程如下圖所示，通過(guò)服務(wù)器提供的 Public Key 從瀏覽器獲取 PushSubscription 對(duì)象，PushSubcription 包含瀏覽器對(duì)應(yīng)的消息服務(wù)器的地址和一些密鑰認(rèn)證數(shù)據(jù)，將它發(fā)送到服務(wù)器，服務(wù)器將這些數(shù)據(jù)存儲(chǔ)，發(fā)送離線(xiàn)消息需要使用到這些數(shù)據(jù)。訂閱通知的過(guò)程就完成了。

服務(wù)器發(fā)送通知，服務(wù)器用 Private Key 將消息加密發(fā)送到之前保存的 PushSubcription 中對(duì)應(yīng)的消息服務(wù)器，消息服務(wù)器解密消息后將消息推送到用戶(hù)的瀏覽器，瀏覽器喚醒 Service Worker，這就完成了整個(gè)消息推送的過(guò)程。

除了 Web App Manifest、Service Worker、Push API 這三個(gè)關(guān)鍵的技術(shù)外，PWA 還包含很多優(yōu)化的準(zhǔn)則，比如 PRPL 模式，App Shell 模型，Credential Management API ，等等。PWA 不是某一種特定的技術(shù)，換句話(huà)來(lái)說(shuō)，PWA 是采用各種技術(shù)達(dá)到站點(diǎn)用戶(hù)體驗(yàn)非常好的 Web App。單單從技術(shù)上講，已經(jīng)能夠很好地彌補(bǔ)傳統(tǒng) Web 的劣勢(shì)了。

三、放眼未來(lái)：PWA 將帶來(lái)新一輪前端技術(shù)洗牌？

1. 業(yè)界廠商紛紛支持，包括蘋(píng)果

各家瀏覽器廠商在 2017 年開(kāi)始大力支持 PWA，下圖統(tǒng)計(jì)了主流瀏覽器對(duì) PWA 的支持程度，可以看到，大部分瀏覽器對(duì) PWA 已經(jīng)支持得很好了。

圖片來(lái)源于 ispwaready

UC 瀏覽器開(kāi)發(fā)的 U2 內(nèi)核已經(jīng)支持 Push API 了，也是國(guó)內(nèi)第一個(gè)支持 Push API 的瀏覽器。現(xiàn)在瀏覽器廠商唯恐自己沒(méi)跟上標(biāo)準(zhǔn)，而被淘汰。

不僅國(guó)內(nèi)瀏覽器廠商的態(tài)度發(fā)生轉(zhuǎn)變，連蘋(píng)果都已經(jīng)在幾個(gè)月前悄悄的進(jìn)行了 Service Worker 的開(kāi)發(fā)了，相信在不遠(yuǎn)的將來(lái)，iOS 也將支持 PWA。

2. PWA 開(kāi)發(fā)門(mén)檻也在降低

為了降低 PWA 的開(kāi)發(fā)門(mén)檻，業(yè)界也推出了相應(yīng)的工具。

例如，百度推出的 Lavas 就是一個(gè)開(kāi)源的命令行工具，可以通過(guò)它來(lái)快速創(chuàng)建 PWA 項(xiàng)目。它提供了多種常用的 APP Shell 給用戶(hù)選擇，降低了開(kāi)發(fā)成本，也簡(jiǎn)化了工作流程，讓 PWA 項(xiàng)目變得易于管理。

3. 各大站點(diǎn)紛紛實(shí)踐，用PWA已成趨勢(shì)？

PWA 剛推出時(shí)，就獲得了很多大型站點(diǎn)的支持，比如印度最大的電商網(wǎng)站 Flipcart，它是第一個(gè)大規(guī)模應(yīng)用 PWA 的站點(diǎn)，也取得了非常好的收益，用戶(hù)停留時(shí)長(zhǎng)增長(zhǎng)了 3 倍。除 Flipcart 之外，還有很多不錯(cuò)的案例。下面我們來(lái)看看國(guó)內(nèi)外的兩個(gè)站點(diǎn)的實(shí)踐案例。

案例1：Twitter Lite PWA

首先，國(guó)外的 Twitter 在 2017 年上線(xiàn)了 Twitter Lite PWA， Google 開(kāi)發(fā)者網(wǎng)站上有 Twitter PWA 的案例分析。Twitter Lite PWA 同樣收益驚人：

• 平均用戶(hù)停留時(shí)長(zhǎng)增長(zhǎng) 65%
• Web 站點(diǎn)發(fā)推的數(shù)量增長(zhǎng) 75% (Amazing)
• 跳出率降低 20%

Twitter Lite 能取得這樣的成績(jī)，歸功于 PWA 的新技術(shù)和用戶(hù)體驗(yàn)至上的設(shè)計(jì)原則：它通過(guò) Service Worker 緩存文件，讓頁(yè)面可以離線(xiàn)，同時(shí)降低網(wǎng)絡(luò)消耗；通過(guò) Web Push 接受服務(wù)器推送的消息；采用 App Shell 的設(shè)計(jì)模型，配合 Service Worker 能讓頁(yè)面瞬間展現(xiàn)。

案例2：ele.me PWA

Google 開(kāi)發(fā)者網(wǎng)站上也對(duì) ele.me 的案例進(jìn)行了 分析。從這個(gè)案例分析中，我們可以看到 ele.me PWA 改造的收益如下：

• 預(yù)緩存的頁(yè)面平均加載時(shí)間減少 11.6%
• 所有頁(yè)面的平均加載時(shí)間減少 6.35%
• 在 3G 網(wǎng)絡(luò)并且是第一次加載時(shí)，從頁(yè)面加載到用戶(hù)可操作的時(shí)間下降到 4.93s

可見(jiàn)，ele.me 同樣取得了很不錯(cuò)的收益。不同于 Twitter Lite，ele.me 是 MPA 站點(diǎn)，這會(huì)讓站點(diǎn)變的更復(fù)雜，并且體驗(yàn)不如 SPA 那么順暢，但是 ele.me 充分利用了 PWA 的各種新技術(shù)和設(shè)計(jì)模式，將 MPA 的影響降到最小，比如使用了 PRPL 模式，最大程度的降低頁(yè)面的首屏?xí)r間，還采用了 App Skeleton 的設(shè)計(jì)方式讓用戶(hù)對(duì)正在加載的頁(yè)面內(nèi)容有心里預(yù)期。

Twitter 和 ele.me 只是 PWA 站點(diǎn)中兩個(gè)效果比較顯著的案例，同樣還有很多其他的案例，可以訪(fǎng)問(wèn) Google 的案例分析頁(yè)面合集：

https://developers.google.cn/web/showcase/

實(shí)際收益明顯，再加上 Google 的強(qiáng)力支持，使得 PWA 的增長(zhǎng)非常迅速，越來(lái)越多的互聯(lián)網(wǎng)大站跟進(jìn)。下面這張圖列出了一些站點(diǎn)，從最開(kāi)始的 Flipcart，到目前的 Instangram、Uber、Twitter、Starbucks 等，不僅數(shù)量在增加，站點(diǎn)等級(jí)和質(zhì)量也在不斷地提升。放眼國(guó)內(nèi)，百度、餓了么、阿里都已經(jīng)有部分站點(diǎn)支持 PWA 了，滴滴也表示有興趣，可見(jiàn)，PWA 不僅在國(guó)外非常受重視，在國(guó)內(nèi)同樣受到各大互聯(lián)網(wǎng)企業(yè)的重視。

按照當(dāng)前的發(fā)展趨勢(shì)，PWA 將會(huì)帶來(lái) Web App 的大量需求，新一輪大前端技術(shù)洗牌很可能近在眼前了。

總結(jié)

以上是生活随笔為你收集整理的PWA将带来新一轮大前端技术洗牌？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。