關於PWA落地問題的思考

Horky發表於2017-03-29

PWA是最近一個熱門話題，很多開發同學都在嘗試落地，其中也有些還在猶豫。這篇文章主要闡述對幾個問題的看法，供大家參考。
注: 這不是一篇介紹PWA的文章。

簡而言之(TL;DR)：
 . PWA落地最大的糾結在於iOS支援的問題，且短時間難以得到改善。如果你的業務僅限於iOS，就不用再往下看了。
    . 事實上，PWA本身與其它技術方案並不衝突，比如各類的Web效能優化方案，以及基本的H5技術仍然可以落地共存，PWA只是在其之上進行更進一步。這正是其所謂漸進式命名的由來。
 . PWA正在擁有一個完善的技術體系，涉及五個層次，從Web平臺，到各類工具。
 . 無論是從最近Web生態的發展，到未來應用開發技術的演進，再到實際開發落地和維護，PWA都代表了一個正確方向，值得投入。

iOS之痛是個偽命題

iOS中Safari核心支援一直是PWA繞不開的問題。2016年參加Google I/O時，與Chrome團隊做了一次交流。他們明確表達了期望UC參與Chromium社群，越多人使用Chromium核心，Safari承受的壓力就越大，就能促使其快速跟進Chrome提出的一系列新標準，其中的重點就是PWA方向。Safari團隊雖然將Service Worker列入其五年計劃，但並沒鬆口開工。反觀Microsoft Edge要積極的多。曾經打破瀏覽器格局的WebKit(Safari)已顯然要成為移動時代的IE6了，主要著眼於其封閉的生態思考！

但是，iOS支援的問題不應該阻礙了PWA技術選型！原因是PWA是漸近增強式(Progressive)的技術，其核心是增強，而不是直接替代（比如沒有替換某個H5特性，而是新增。），在不支援的場景下可以安全降級。以離線儲存為例，AppCache實在太難用, 在沒有支援Cache API的情況下可以使用Local Storage實現，如果支援了Cache API，就可以直接使用ServiceWorker+Cache來實現。在技術方案上，有一個基本的實現方案，是通用的。

在支援PWA相關標準的環境下，還可以進一步使用加強的技術方案。正如軟體開發沒有銀彈一樣，不能期望一個新技術可以解決所有問題。之前要解決的問題還是要繼續分析解決，比如JS邏輯優化、圖片壓縮、CDN配置優化之類的工作，還是應當要一樣展開的。

如果一定在iOS要使用到某些PWA特性帶來的好處。可以考慮:

  • 評估使用Polyfill的可行性。直接到下面Polyfills那一節看下。
  • 實現一套在獨立執行緒(類似於Service worker)運作的擴充套件機制，使用JS Bridge提供給頁端使用。有一定的風險，可以提供主要特性的支援，比如Cache & Fetch。
  • 通過各種渠道(Mailing list, App Store, Twitter, etc.)向Safari吐槽。這條簡單易行！

PWA === Servie Worker + Fetch + Cache?

初次進行PWA落地，我們往往會聚焦於幾個搶眼的特性。從小步快走的角度來看這是正確的，但不能僅限於這一點，我們還需要更加系統瞭解PWA的技術體系。

從整個技術體系上看，分成五個層次:

  • PWA Features 通過標準定義，開放傳播。易於各方理解和支援，特別是凝聚一些中間力量。因為Top的玩家也可以選擇玩封閉的生態。
  • Web Platforms (各家瀏覽器及WebView) Web平臺的支援，才能讓PWA有應用的空間。特別是進一步與OS的結合，提高了Web應用與原生應用的競爭力，才能保證Web App能夠成為應用開發的選項之一。從平臺的角度思考，它一定會支援多種技術方案，更多的應用形式能幫助整個應用市場活躍起來。
  • 元件庫及工具庫(Polymer等) 開發最容易糾結在庫、框架、元件的選擇上，因為這是實實在在的痛點。有了進一步封裝的庫、元件、解決方案，無論具體什麼形式，它必須要簡化PWA的開發，是一個可以複用的技術方案，以降低開發成本和技術風險。
  • 工具及支撐平臺 工具則包括開發除錯、檢測等可以提高開發效率的工具。支撐平臺則是為這個生態提供基礎服務的。
  • 設計思想和開發模式 在一個技術生態內，對實踐的指導原則可以理解對最佳實踐的抽象總結，可以幫助開發者更好理解這個生態面對的問題和解決的思路。最終它會影響到工具和元件，甚至是平臺和Features。

Features不用多說，Web Platforms則是除了Safari之外的主流瀏覽器都有支援，只是Edge在支援的範圍上有所差異。以下是工具和元件的構成:

最後特別需要提醒的是，落地過程也是一個持續學習和優化的過程。比如Polymer本身有一些效能優化策略，如果簡單的使用可能會發現有效能上的降級，UC的同學也是在實踐中積累了些經驗。

工具庫示例:sw-toolbox

工具庫固化了一些常用的實現，以sw-toolbox為例，其核心是提供一組離線應用的策略機制，可以結合導航使用不同載入策略。詳細的策略說明文件是: The Offline Cookbook, 其中總結並定義了在離線應用中涉及的五種載入策略。sw-toolbox對應定義如下的策略:

  • networkFirst
  • cacheFirst
  • fastest
  • cacheOnly
  • networkOnly
    其中fastest的策略是同步從Cache和網路中載入，使用先返回的資料。另外還可以指定超時時間等載入選項。超時選項(networkTimeoutSeconds)設定是需要考慮的，因為Chrome的網路請求沒有預設的Timeout機制，UC則是自己做了實現。詳細內容看它的API定義文件。

整個使用非常簡潔，下面是一個service worker的寫法,使得進入offline/時僅從快取載入:

// DEMO for sw-toolbox.
importScripts('sw-toolbox/sw-toolbox.js');

// Optional
toolbox.options.cache.name = 'sw-toolbox-cache';

toolbox.precache(['./caching.html', './offline/index.html']);

// Define different strategies as below:
toolbox.router.default = toolbox.fastest;
// Below router means to load data from cache only while navigating to offline.
toolbox.router.get('/offline/.*', toolbox.cacheOnly);

// For more details, please refer to SW-Toolbox API:
//    https://googlechrome.github.io/sw-toolbox/api.html

完整的例子可以訪問這裡PWA Demo。

HTTPS還是HTTP2？

這裡有一個清晰的技術鏈條:

  • PWA要求使用HTTPS。
  • HTTP2較HTTPS提供更高的效能表現。
    所以在考慮PWA落地，還要糾結下HTTPS和HTTP2。HTTPS本身會有一定的成本（證照、CPU等)和效能影響(首次明顯)，HTTP2則有更好的效能收益，但應用上有不同的Web優化策略，核心是多路複用和Server Push，使得之前的一些優化實踐無效，甚至有負作用，比如內聯資源，分散伺服器等。可以簡單參考Web 開發者的 HTTP/2 效能優化指南。

除了自己的服務部署，還要涉及CDN的支援。正如之前HTTP Pipeline的支援，瀏覽器樂於支援，但實際測試資料卻發現效能更差，原因就是大部分的伺服器後臺和CDN都沒有支援。現在的情況是，目前國內的主要CDN可以支援HTTPS，如阿里雲還支援了HTTP2。 長遠來看一定是HTTP2，只是需要從業務本身出發，仔細評估下相關的風險和影響，絕非是後臺做了支援就萬事大吉了。

PWA特性支援不完整，怎麼破？

PWA這個體系涉及的功能很多，也是逐漸在完善。Chrome本身迭代比較快，國內瀏覽器有一個較長的跟進週期。所以特性支援不全是比較容易遇到的問題。舉個例子，餓了麼團隊在PWA實踐中遇到了Fetch Redirect失敗的問題，詳情可以參考:PWA 在餓了麼的實踐經驗。從頁端或者後臺還是比較容易處理的。

但是不是所有的問題都能這樣解決，也會有必須核心進行支援的問題，這種情況下，瀏覽器是可以做部分升級的。如果你遇到了，歡迎隨時和我們聯絡。

關於Polyfills

僅列幾個給有需要的同學參考:

PWA的未來

PWA首先瞄準的是應用開發，以其官方定義，是為應用開發者提供多一個選擇。所以會盡力縮小其與原生應用在能力上的差距。回頭想到2012年前後那股也是Chrome推動的WebApp，最終不了了之。現在的PWA機會其實也就是H5的未來空間。

可以想象未來5年，應用開發的技術模式一定會有很大的變化。總體方向就是高動態性、低開發成本（包括了低風險）, 產品形式上超級應用 (包括OS)和輕快的小型應用兩極分化，前者越來越寡頭，後者則佔據絕大多數。

縱觀現在App開發技術上的創新都是在這個方向上，包括RN, Weex, AMP(或者Instant Article), PWA, Android Instant App之類。無論Native容器、或者原生應用本身如何發展，產品對動態性的需求只會越來越高。而產品技術的複雜度也會越來越高，開發週期、變更成本、維護成本都有越來越高的要求。

Web的優勢是開放的標準，一是持續改進，不斷擴充套件和豐富，使其展現能力越來越強。二是技術清晰透明，易於理解和傳播，有助於降低開發成本，包括風險。著眼於未來，不在於現在誰的市場佔比提升速度，而在於哪方能更穩健地持續提供系統的支援，讓生態更完整。

具體到內容展現，或者渲染技術上。雖然Web目前仍然有較大的效能問題，但它正通過自身的優化、以及提供原生擴充套件不斷縮小差距。以UC實踐的經驗來看，除了核心演進外，前端對渲染效能的理解和優化也是同樣關鍵的問題。可以參考Roger的對頁端開發高效能（互動/動畫） Mobile WebApp 的一些思考。

再回到2016年底到現在3月份，Node.js的成熟推廣，Weex/RN發力，再到小程式造的勢(輕快)，讓頁端承擔應用+H5主力開發的模式越來越清晰。
再從Google對Web開發者的推崇(16年底的開發者大會)以及對業界的技術推廣活動，到iOS AppStore的熱修復門，一邊推，一邊收緊，所產生的不確定性反而讓H5方向更為明確。

問題總是越辨越明，歡迎大家指正。

相關文章