【轉載】下一代Web應用模型：Progressive Web App

時間 2019-11-10

標籤轉載下一代 web 應用模型 progressive app 欄目 HTML 简体版

原文原文鏈接

下一代 Web 應用？

近年來，Web 應用在整個軟件與互聯網行業承載的責任愈來愈重，軟件複雜度和維護成本愈來愈高，Web 技術，尤爲是 Web 客戶端技術，迎來了爆發式的發展。javascript

包括但不限於基於 Node.js 的前端工程化方案；諸如 Webpack、Rollup 這樣的打包工具；Babel、PostCSS 這樣的轉譯工具；TypeScript、Elm 這樣轉譯至 JavaScript 的編程語言；React、Angular、Vue 這樣面向現代 Web 應用需求的前端框架及其生態，也涌現出了像同構 JavaScript與通用 JavaScript 應用這樣將服務器端渲染（Server-side Rendering）與單頁面應用模型（Single-page App）結合的 Web 應用架構方式，能夠說是百花齊放。php

可是，Web 應用在移動時代並無達到其在桌面設備上流行的程度。究其緣由，儘管上述的各類方案已經充分利用了現有的 JavaScript 計算能力、CSS 佈局能力、HTTP 緩存與瀏覽器 API 對當代基於 Ajax 與響應式設計的 Web 應用模型的性能與體驗帶來了工程角度的巨大突破，咱們仍然沒法在不借助原生程序輔助瀏覽器的前提下突破 Web 平臺自己對 Web 應用固有的桎梏：客戶端軟件（即網頁）須要下載所帶來的網絡延遲；與 Web 應用依賴瀏覽器做爲入口所帶來的體驗問題。css

Web 與原生應用在移動平臺上的使用時長對比圖片來源: Googlehtml

在桌面設備上，因爲網絡條件穩定，屏幕尺寸充分，交互方式趨向於多任務，這兩點形成的負面影響對比 Web 應用免於安裝、隨叫隨到、無需更新等優勢，瑕不掩瑜。可是在移動時代，脆弱的網絡鏈接與全新的人機交互方式使得這兩個問題被無限放大，嚴重製約了 Web 應用在移動平臺的發展。在用戶眼裏，原生應用不會出現「白屏」，清一色都擺在主屏幕上；而 Web 應用則是瀏覽器這個應用中的應用，使用起來並不方便，並且加載也比原生應用要慢。前端

Progressive Web Apps（如下簡稱 PWA）以及構成 PWA 的一系列關鍵技術的出現，終於讓咱們看到了完全解決這兩個平臺級別問題的曙光：可以顯著提升應用加載速度、甚至讓 Web 應用能夠在離線環境使用的 Service Worker 與 Cache Storage；用於描述 Web 應用元數據（metadata）、讓 Web 應用可以像原生應用同樣被添加到主屏、全屏執行的 Web App Manifest；以及進一步提升 Web 應用與操做系統集成能力，讓 Web 應用能在未被激活時發起推送通知的 Push API 與 Notification API 等等。html5

將這些技術組合在一塊兒會是怎樣的效果呢？「印度阿里巴巴」 —— Flipkart 在 2015 年一度關閉了本身的移動端網站，卻在年末發佈瞭如今最爲人津津樂道的 PWA 案例 FlipKart Lite，成爲世界上第一個支撐大規模業務的 PWA。發佈的一週後它就亮相於 Chrome Dev Summit 2015 上，筆者當時就被驚豔到了。爲了方便各媒介上的讀者觀看，筆者作了幾幅圖方便給你們介紹：java

圖片來源: Hux & Medium.comios

當瀏覽器發現用戶須要 Flipkart Lite 時，它就會提示用戶「嘿，你能夠把它添加至主屏哦」（用戶也能夠手動添加）。這樣，Flipkart Lite 就會像原生應用同樣在主屏上留下一個自定義的 icon 做爲入口；與通常的書籤不一樣，當用戶點擊 icon 時，Flipkat Lite 將直接全屏打開，再也不受困於瀏覽器的 UI 中，並且有本身的啓動屏效果。git

圖片來源: Hux & Medium.comgithub

更強大的是，在沒法訪問網絡時，Flipkart Lite 能夠像原生應用同樣照常執行，還會很騷氣的變成黑白色；不但如此，曾經訪問過的商品都會被緩存下來得以在離線時繼續訪問。在商品降價、促銷等時刻，Flipkart Lite 會像原生應用同樣發起推送通知，吸引用戶回到應用。

無需擔憂網絡延遲；有着獨立入口與獨立的保活機制。以前兩個問題的一併解決，宣告着 Web 應用在移動設備上的浴火重生：知足 PWA 模型的 Web 應用，將逐漸成爲移動操做系統的一等公民，並將向原生應用發起挑戰與「復仇」。

更令筆者興奮的是，就在今年 11 月的 Chrome Dev Summit 2016 上，Chrome 的工程 VP Darin Fisher 介紹了 Chrome 團隊正在作的一些實驗：把「添加至主屏」重命名爲「安裝」，被安裝的 PWA 再也不僅以 widget 的形式顯示在桌面上，而是真正作到與全部原生應用平級，同樣被收納進應用抽屜（App Drawer）裏，同樣出如今系統設置中。

圖片來源: Hux & @adityapunjani

圖中從左到右分別爲：相似原生應用的安裝界面；被收納在應用抽屜裏的 Flipkart Lite 與 Hux Blog；設置界面中並列出現的 Flipkart 原生應用與 Flipkart Lite PWA （能夠看到 PWA 巨大的體積優點）

筆者相信，PWA 模型將繼約 20 年前橫空出世的 Ajax 與約 10 年前風靡移動互聯網的響應式設計以後，掀起 Web 應用模型的第三次根本性革命，將 Web 應用帶進一個全新的時代。

PWA 關鍵技術的前世此生

Web App Manifest

Web App Manifest，即經過一個清單文件向瀏覽器暴露 Web 應用的元數據，包括名字、icon 的 URL 等，以備瀏覽器使用，好比在添加至主屏或推送通知時暴露給操做系統，從而加強 Web 應用與操做系統的集成能力。

讓 Web 應用在移動設備上的體驗更接近原生應用的嘗試其實早在 2008 年的 iOS 1.1.3 與 iOS 2.1.0 時就開始了，它們分別爲 Web 應用增長了對自定義 icon 和全屏打開的支持。

圖片來源: appleinsider.com

可是很快，隨着愈來愈多的私有平臺經過 <meta>/<link> 標籤來爲 Web 應用添加「私貨」，<head> 很快就被塞滿了：

<!-- Add to homescreen for Safari on iOS --> <meta name="apple-mobile-Web-app-capable" content="yes"> <meta name="apple-mobile-Web-app-status-bar-style" content="black"> <meta name="apple-mobile-Web-app-title" content="Lighten"> <!-- Add to homescreen for Chrome on Android --> <meta name="mobile-Web-app-capable" content="yes"> <meta name="theme-color" content="#000000"> <!-- Icons for iOS and Android Chrome M31~M38 --> <link rel="apple-touch-icon-precomposed" sizes="144x144" href="images/touch/apple-touch-icon-144x144-precomposed.png"> <link rel="apple-touch-icon-precomposed" sizes="114x114" href="images/touch/apple-touch-icon-114x114-precomposed.png"> <link rel="apple-touch-icon-precomposed" sizes="72x72" href="images/touch/apple-touch-icon-72x72-precomposed.png"> <link rel="apple-touch-icon-precomposed" href="images/touch/apple-touch-icon-57x57-precomposed.png"> <!-- Icon for Android Chrome, recommended --> <link rel="shortcut icon" sizes="196x196" href="images/touch/touch-icon-196x196.png"> <!-- Tile icon for Win8 (144x144 + tile color) --> <meta name="msapplication-TileImage" content="images/touch/ms-touch-icon-144x144-precomposed.png"> <meta name="msapplication-TileColor" content="#3372DF"> <!-- Generic Icon --> <link rel="shortcut icon" href="images/touch/touch-icon-57x57.png">

顯然，這種作法並不優雅：分散又重複的元數據定義多餘且難以維持同步，與 html 耦合在一塊兒也加劇了瀏覽器檢查元數據將來變更的成本。與此同時，社區裏開始出現使用 manifest 文件以中心化地描述元數據的方案，好比 Chrome Extension、 Chrome Hosted Web Apps (2010) 與 Firefox OS App Manifest (2011) 使用 JSON；Cordova 與 Windows Pinned Site 使用 XML；

2013 年，W3C WebApps 工做組開始對基於 JSON 的 Manifest 進行標準化，於同年年末發佈第一份公開 Working Draft，並逐漸演化成爲今天的 W3C Web App Manifest：

{
  "short_name": "Manifest Sample",
  "name": "Web Application Manifest Sample",
  "icons": [{
      "src": "launcher-icon-2x.png",
      "sizes": "96x96",
      "type": "image/png"
   }],
  "scope": "/sample/",
  "start_url": "/sample/index.html",
  "display": "standalone",
  "orientation": "landscape"
  "theme_color": "#000",
  "background_color": "#fff",
}
<!-- document --> <link rel="manifest" href="/manifest.json">

諸如 name、icons、display 都是咱們比較熟悉的，而大部分新增的成員則爲 Web 應用帶來了一系列之前 Web 應用想作卻作不到（或在以前只能靠 hack）的新特性：

scope：定義了 Web 應用的瀏覽做用域，好比做用域外的 URL 就會打開瀏覽器而不會在當前 PWA 裏繼續瀏覽。
start_url：定義了一個 PWA 的入口頁面。好比說你添加 Hux Blog 的任何一個文章到主屏，從主屏打開時都會訪問 Hux Blog 的主頁。
orientation：終於，咱們能夠鎖定屏幕旋轉了（喜極而泣…）
theme_color/background_color：主題色與背景色，用於配置一些可定製的操做系統 UI 以提升用戶體驗，好比 Android 的狀態欄、任務欄等。

這個清單的成員還有不少，好比用於聲明「對應原生應用」的 related_applications 等等，本文就不一一列舉了。做爲 PWA 的「戶口本」，承載着 Web 應用與操做系統集成能力的重任，Web App Manifest 還將在往後不斷擴展，以知足 Web 應用高速演化的須要。

Service Worker

咱們原有的整個 Web 應用模型，都是構建在「用戶能上網」的前提之下的，因此一離線就只能玩小恐龍了。其實，對於「讓 Web 應用離線執行」這件事，Service Worker 至少是 Web 社區的第三次嘗試了。

故事能夠追溯到 2007 年的 Google Gears：爲了讓自家的 Gmail、Youtube、Google Reader 等 Web 應用能夠在本地存儲數據與離線執行，Google 開發了一個瀏覽器拓展來加強 Web 應用。Google Gears 支持 IE 六、Safari 三、Firefox 1.5 等瀏覽器；要知道，那一年 Chrome 都還沒出生呢。

在 Gears API 中，咱們經過向 LocalServer 模塊提交一個緩存文件清單來實現離線支持：

// Somewhere in your javascript var localServer = google.gears.factory.create("bata.localserver"); var store = localServer.createManagedStore(STORE_NAME); store.manifestUrl = "manifest.json" // manifest.json - 假設 JSON 有註釋 { 　　"betaManifestVersion":　1, 　　"version": 　"1.0", 　　"entries":　[　 　　　　{　"url": 　"index.html"}, 　　　　{　"url": 　"main.js"} 　　] }

是否是感到很熟悉？好像 HTML5 規範中的 Application Cache 也是相似的東西？

<html manifest="cache.appcache"> CACHE MANIFEST CACHE: index.html main.js

是的，Gears 的 LocalServer 就是後來你們所熟知的 App Cache 的前身，大約從 2008 年開始 W3C 就開始嘗試將 Gears 進行標準化了；除了 LocalServer，Gears 中用於提供並行計算能力的 WorkerPool 模塊與用於提供本地數據庫與 SQL 支持的 Database 模塊也分別是往後 Web Worker 與 Web SQL Database（後被廢棄）的前身。

HTML5 App Cache 做爲第二波「讓 Web 應用離線執行」的嘗試，確實也服務了好比 Google Doc、尤雨溪早年做品 HTML5 Clear、以及一直用 Web 應用做爲本身 iOS 應用的 FT.com（Financial Times）等很多 Web 應用。那麼，還有 Service Worker 什麼事呢？

是啊，若是 App Cache 沒有被設計得爛到徹底不可編程、沒法清理緩存、幾乎沒有路由機制、出了 Bug 一點救都沒有，可能就真沒 Service Worker 什麼事了。App Cache 已經在前不久定稿的 HTML5.1 中被拿掉了，W3C 爲了挽救 Web 世界真是不惜把本身的臉都打腫了……

時至今日，咱們終於迎來了 Service Worker 的曙光。簡單來講，Service Worker 是一個可編程的 Web Worker，它就像一個位於瀏覽器與網絡之間的客戶端代理，能夠攔截、處理、響應流經的 HTTP 請求；配合隨之引入 Cache Storage API，你能夠自由管理 HTTP 請求文件粒度的緩存，這使得 Service Worker 能夠從緩存中向 Web 應用提供資源，即便是在離線的環境下。

Service Worker 就像一個運行在客戶端的代理

好比說，咱們能夠給網頁 foo.html 註冊這麼一個 Service Worker，它將劫持由 foo.html 發起的一切 HTTP 請求，並通通返回未設置 Content-Type 的 Hello World!：

// sw.js self.onfetch = (e) => { e.respondWith(new Response('Hello World!')) }

Service Worker 第一次發佈於 2014 年的 Google IO 上，目前已處於 W3C 工做草案的狀態。其設計吸收了 Application Cache 的失敗經驗，做爲 Web 應用的開發者的你有着徹底的控制能力；同時，它還借鑑了 Chrome 多年來在 Chrome Extension 上的設計經驗（Chrome Background Pages 與 Chrome Event Pages），採用了基於「事件驅動」的喚醒機制，以大幅節省後臺計算的能耗。好比上面的 fetch 其實就是會喚醒 Service Worker 的事件之一。

Service Worker 的生命週期

除了相似 fetch 這樣的功能事件外，Service Worker 還提供了一組生命週期事件，包括安裝、激活等等。好比，在 Service Worker 的「安裝」事件中，咱們能夠把 Web 應用所須要的資源通通預先下載並緩存到 Cache Storage 中去：

// sw.js self.oninstall = (e) => { e.waitUntil( caches.open('installation') .then(cache => cache.addAll([ './', './styles.css', './script.js' ])) ) });

這樣，當用戶離線，網絡沒法訪問時，咱們就能夠從緩存中啓動咱們的 Web 應用：

//sw.js self.onfetch = (e) => { const fetched = fetch(e.request) const cached = caches.match(e.request) e.respondWith( fetched.catch(_ => cached) ) }

能夠看出，Service Worker 被設計爲一個相對底層（low-level）、高度可編程、子概念衆多，也所以異常靈活且強大的 API，故本文只能展現它的冰山一角。出於安全考慮，註冊 Service Worker 要求你的 Web 應用部署於 HTTPS 協議下，以避免利用 Service Worker 的中間人攻擊。筆者在今年 GDG 北京的 DevFest 上分享了 Service Worker 101，涵蓋了 Service Worker 譬如「網絡優先」、「緩存優先」、「網絡與緩存比賽」這些更復雜的緩存策略、學習資料、以及示例代碼，能夠供你們參考。

Service Worker 的一種緩存策略：讓網絡請求與讀取緩存比賽

你也能夠嘗試在支持 PWA 的瀏覽器中訪問筆者的博客 Hux Blog，感覺 Service Worker 的實際效果：全部訪問過的頁面都會被緩存並容許在離線環境下繼續訪問，全部未訪問過的頁面則會在離線環境下展現一個自定義的離線頁面。

在筆者看來，Service Worker 對 PWA 的重要性至關於 XMLHTTPRequest 之於 Ajax，媒體查詢（Media Query）之於響應式設計，是支撐 PWA 做爲「下一代 Web 應用模型」的最核心技術。因爲 Service Worker 能夠與包括 Indexed DB、Streams 在內的大部分 DOM 無關 API 進行交互，它的潛力簡直無可限量。筆者幾乎能夠斷言，Service Worker 將在將來十年裏成爲 Web 客戶端技術工程化的兵家必爭之地，帶來「離線優先（Offline-first）」的架構革命。

Push Notification

PWA 推送通知中的「推送」與「通知」，其實使用的是兩個不一樣但又相得益彰的 API：

Notification API 相信你們並不陌生，它負責全部與通知自己相關的機制，好比通知的權限管理、向操做系統發起通知、通知的類型與音效，以及提供通知被點擊或關閉時的回調等等，目前國內外的各大網站（尤爲在桌面端）都有必定的使用。Notification API 最先應該是在 2010 年先後由 Chromium 提出草案以 WebkitNotifications 前綴方式實現；隨着 2011 年進入標準化；2012 年在 Safari 6（Mac OSX 10.8+）上得到支持；2015 年 Notification API 成爲 W3C Recommendation；2016 年 Edge 的支持；Web Notifications 已經在桌面瀏覽器中得到了全面支持（Chrome、Edge、Firefox、Opera、Safari）的成就。

Push API 的出現則讓推送服務具有了向 Web 應用推送消息的能力，它定義了 Web 應用如何向推送服務發起訂閱、如何響應推送消息，以及 Web 應用、應用服務器與推送服務之間的鑑權與加密機制；因爲 Push API 並不依賴 Web 應用與瀏覽器 UI 存活，因此即便是在 Web 應用與瀏覽器未被用戶打開的時候，也能夠經過後臺進程接受推送消息並調用 Notification API 向用戶發出通知。值得一提的是，Mac OSX 10.9 Mavericks 與 Safari 7 在 2013 年就發佈了本身的私有推送支持，基於 APNS 的 Safari Push Notifications。

在 PWA 中，咱們利用 Service Worker 的後臺計算能力結合 Push API 對推送事件進行響應，並經過 Notification API 實現通知的發出與處理：

// sw.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 event event.notification.close(); }); self.addEventListener('notificationclose', event => { // Do something with the event });

對於 Push Notification，筆者的幾回分享中一直都提的稍微少一些，一是由於 Push API 還處於 Editor Draft 的狀態，二是目前瀏覽器與推送服務的互相支持都還不夠成熟：Android 上的 Chrome（與其它基於 Blink 的瀏覽器）目前只支持基於 Google 私有的 GCM/FCM 的通知推送，只有 Firefox 已經實現了成在由 IETF 進行標準化的 Web 推送協議（Web Push Protocol）。

不過，若是你已經在使用 Google 的雲服務（好比 Firebase），而且主要面向的是海外用戶，那麼在 Web 應用上支持基於 GCM/FCM 的推送通知並非一件費力的事情，筆者推薦你閱讀一下 Google Developers 的系列文章，不少國外公司已經玩起來了。

從 Hybrid 到 PWA，從封閉到開放

2008 年，當移動時代來臨，唱衰移動 Web 的聲音開始出現，而瀏覽器的進化並不能跟上時，來自 Nitobi 的 Brian Leroux 等人創造了 Phonegap，但願它能以 Polyfill 的形式、彌補目前瀏覽器與移動設備間的「鴻溝」，今後開啓了混合應用（Hybrid Apps）的時代。

幾年間，Adobe AIR、Windows Runtime Apps、Chrome Apps、Firefox OS、WebOS、Cordova/Phonegap、Electron 以及國內好比微信、淘寶，無數的 Hybrid 方案拔地而起，讓 Web 開發者能夠在繼續使用 Web 客戶端技術的同時，作到一些只有原生應用才能作到的事情，包括訪問一些設備與操做系統 API，給用戶帶來更加「Appy」的體驗，以及進入 App Store 等等。

衆多的 Hybrid 方案

PWA 做爲一個涵蓋性術語，與過往的這些或多或少經過私有平臺 API 加強 Web 應用的嘗試最大的不一樣，在於構成 PWA 的每一項基本技術，都已經或正在被 IETF、ECMA、W3C 或 WHATWG 標準化，不出意外的話，它們都將被歸入開放 Web 標準，並在不遠的未來獲得全部瀏覽器與全平臺的支持。咱們終於能夠逃出 App Store 封閉的祕密花園，從新回到屬於 Web 的那片開放自由的大地。

有趣的是，從上文中你也能夠發現，組成 PWA 的各項技術的草案正是由上述各類私有方案背後的瀏覽器廠商或開發者直接貢獻或間接影響的。能夠說，PWA 的背後並非某一家或兩家公司，而是整個 Web 社區與整個 Web 規範。正是由於這種開放與去中心化的力量，使得萬維網（World Wide Web）可以成爲當今世界上跨平臺能力最強、且幾乎是惟一一個具有這種跨平臺能力的應用平臺。

「咱們相信 Web，是由於相信它是解決設備差別化的終極方案；咱們相信，當 Web 在今天作不到一件事的時候，是由於它還沒來得及去實現，而不是由於他作不到。而 Phonegap，它的終極目的就是消失在 Web 標準的背後。」

在不丟失 Web 的開放靈魂，在不須要依靠 Hybrid 把應用放在 App Store 的前提下，讓 Web 應用可以漸進式地跳脫出瀏覽器的標籤，變成用戶眼中的 App。這是 Alex Russell 在 2015 年提出 PWA 概念的原委。

而又正由於 Web 是一個總體，PWA 能夠利用的技術遠不止上述的幾個而已：Ajax、響應式設計、JavaScript 框架、ECMAScript Next、CSS Next、Houdini、Indexed DB、Device APIs、Web Bluetooth、Web Socket、Web Payment、孵化中的 Background Sync API、Streams、WebVR……開放 Web 世界 27 年來的發展以及將來的一切，都與 PWA 天做之合。

魚與熊掌的兼得

通過幾年來的摸索，整個互聯網行業彷彿在「Web 應用 vs. 原生應用」這個問題上達成了共識：

Web 應用是魚：迭代快，獲取用戶成本低；跨平臺強體驗弱，開發成本低。適合拉新。
原生應用是熊掌：迭代慢，獲取用戶成本高；跨平臺弱體驗強，開發成本高。適合保活。

要知道，雖然用戶花在原生應用上的時間要明顯多於 Web 應用，但其中有 80% 的時間是花在前五個應用中的。調查顯示，美國有一半的智能手機用戶平均每個月新 App 安裝量爲零，而月均網站訪問量卻有 100 個，更別提 Google Play 上有 60% 的應用從未被人下載過了。因而，整個行業的產品策略清一色地「拿魚換熊掌」，好比筆者的老東家阿里旅行（飛豬旅行），Web 應用佈滿阿里系各類渠道，提供「優秀的第一手體驗」，等你用的開心了，再引誘你去下載安裝原生應用。

原生應用、當代 Web 與 PWA 圖片來源: Hux & Google

可是，PWA 的出現，讓魚與熊掌兼得變成了可能 —— 它同時具有了 Web 應用與原生應用的優勢，有着本身獨有的先進性：「瀏覽器 -> 添加至主屏/安裝 -> 具有原生應用體驗的 PWA -> 推送通知 -> 具有原生應用體驗的 PWA」，PWA 自身就包含着從拉新到保活的閉環。

除此以外，PWA 還繼承了 Web 應用的另外兩大優勢：無需先付出幾十兆的下載安裝成本便可開始使用，以及不須要通過應用超市審覈就能夠發佈新版本。因此，PWA 能夠稱得上是一種「流式應用（Streamable App）」與「常青應用（Evergreen App）」

將來到來了嗎

在筆者分享 PWA 的經歷中，最不肯意回答的兩個問題莫過於「PWA 已經被普遍支持了嗎？」以及「PWA 與 ABCDEFG 這些技術方案相比有什麼優劣？」，可是這確實是兩個逃不開的問題。

PWA 的支持狀況？

當咱們說到 PWA 是否被支持時，其實咱們在說的是 PWA 背後的幾個關鍵技術都獲得支持了沒有。以瀏覽器內核來劃分的話，Blink（Chrome、Oprea、Samsung Internet 等）與 Gecko（Firefox）都已經實現了 PWA 所需的全部關鍵技術，並已經開始探尋更多的可能性。EdgeHTML（Edge）簡直積極得不能更積極了，全部的特性都已經處於「正在開發中」的狀態。最大的絆腳石仍然來自於 Webkit（Safari），尤爲是在 iOS 上，上述的四個 API 都未獲得支持，並且因爲平臺限制，第三方瀏覽器也沒法在 iOS 上支持。（什麼你說 IE？）

不過，也不要氣餒，Webkit 不但在它 2015 年發佈的五年計劃裏提到了 Service Worker，更是已經在最近實現了 Service Worker 所依賴的 Request、Response 與 Fetch API，還把 Service Worker 與 Web App Manifest 紛紛列入了「正在考慮」的 API 中；要知道，Webkit 但是把 Web Components 中的 HTML Imports 直接列到「不考慮」裏去了……（其實 Firefox 也是）

更況且，因爲 Web 社區一直以來所追求的「漸進加強、優雅降級」，一個 PWA 固然能夠在 iOS 環境正常執行。事實上，華盛頓郵報將網站遷移到 PWA 以後發現，不止是 Android，在 iOS 上也得到了 5 倍的活躍度增加，（不管是否是它們以前的網站寫得太爛吧），就算 iOS 如今還不支持 PWA 也不會怎麼樣，咱們更是有理由相信 PWA 會很快在 iOS 上到來。

PWA vs. Others

賀老（賀師俊）曾說過：「從純 Web 到純 Native，之間有許多可能的點」。當考慮移動應用的技術選型時，除了 Web 與原生應用，咱們還有各類不一樣程度的 Hybrid，還有今年爆發的諸多 JS-to-Native 方案。

雖然我在上文中用了「復仇」這樣的字眼，不過不管從技術仍是商業的角度，咱們都不必把 Web 或是 PWA 放到 Native 的對立面去看。它們固然存在競爭關係，可是更多的時候，Web-only 與 app-only 的策略都是不完美的，當公司資源足夠的時候，咱們一般會選擇同時開發二者。固然，不管與不與原生應用對比，PWA 讓 Web 應用變得體驗更好這件事自己是毋庸置疑的。「不談場景聊技術都是扯淡」，咱們仍然仍是須要根據本身產品與團隊的狀況來決定對應的技術選型與平臺策略，只是 PWA 讓 Web 應用在面對選型考驗時更增強勢了而已。

衆多的技術選型，以及筆者的一種猜想

筆者不負責任得作一些猜想：雖然重量級的 Hybrid 架構與基礎設施還是目前很多場景下最優的解決方案；可是隨着移動設備自己的硬件性能提高與新技術的成熟與普及，JS-to-Native 與以 PWA 爲首的純 Web 應用，將分別從兩個方向擠壓 Hybrid 的生存空間，消化當前 Hybrid 架構主要解決的問題；前者將逐漸演化爲相似 Xarmarin 這樣針對跨平臺原生應用開發的解決方案；後者將顯著下降當前 Hybrid 架構的容器開發與部署成本，將 Hybrid 返璞歸真爲簡單的 Webview 調用。

這種猜想固然不是沒有依據的瞎猜，好比前者能夠參考阿里巴巴集團級別遷移 Weex 的戰略與微信小程序的 roadmap；後者則能夠參考當前 Cordova 與 Ionic 兩大 Hybrid 社區對 PWA 的熱烈反響。

PWA in China

看看 Google 官方宣傳較多的 PWA 案例就會發現，FlipKart、Housing.com 來自印度；Uber、華盛頓郵報來自北美；惟一來自中國的 AliExpress 主要開展的則是海外業務。

因爲中國的特殊性，筆者在第一次聊到 PWA 時不免表現出了必定程度的悲觀：

國內較重視 iOS，而 iOS 目前還不支持 PWA。
國內的 Android 實爲「安卓」，不自帶 Chrome 是一，可能還會有其餘兼容問題。
國內廠商可能並不會像三星那樣對推進自家瀏覽器支持 PWA 那麼感興趣。
依賴 GCM 推送的通知不可用，Web Push Protocol 尚未國內的推送服務實現。
國內 Webview 環境較爲複雜（好比微信），黑科技比較多。

反觀印度，因爲 Google 服務健全、標配 Chrome 的 Android 手機市佔率很是高，PWA 的用戶達到率簡直直逼 100%，也不免得到無數好評與支持了。筆者奢望着本文能對推進 PWA 的國內環境有必定的貢獻。不過不管如何，PWA 在國內的春天可能的確會來得稍微晚一點了。

結語

「咱們信仰 Web，不只僅在於軟件、軟件平臺與單純的技術，還在於『任何人，在任什麼時候間任何地點，均可以在萬維網上發佈任何信息，並被世界上的任何一我的所訪問到。』而這纔是 Web 的最爲革命之處，堪稱咱們人類，做爲一個物種的一次進化。」

請不要讓 Web 再繼續離咱們遠去，瀏覽器廠商們已經從新走到了一塊兒，而下一棒將是交到咱們 Web 應用開發者的手上。喬布斯曾相信 Web 應用才移動應用的將來，那就讓咱們用代碼證實給這個世界看吧。

讓咱們的用戶，也像咱們這般熱愛 Web 吧。

注：在筆者撰文期間，Google 在 Google China Developers Days 上宣佈了 developers.google.cn 域名的啓用，方便國內開發者訪問。對於文中全部鏈向 developers.google.com 的參考文獻，應該均可以在 cn 站點中找到。

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。