iOS 11.3將迎來PWA，你做好準備了嗎？
作者｜Maximiliano Firtman
譯者｜張健欣
Apple 在 iOS 11.3 中引入了萬眾期待的 PWA，這使得開發跨平台的 PWA 成為了可能。但是需要注意的是，這只是 beta1 版本，還有許多問題需要 Apple 的開發團隊解決。本文將結合實際測試，介紹 iOS PWA 目前存在的問題、新增的功能和尚未支持的功能、用戶體驗設計方面需要注意的問題以及一些開發注意事項。
幾天前，Richky Mondello 發布了一條令人驚訝的推特之後，Safari 11.1 beta 發布日誌說已經實現了 Web App Manifest 和 Service Workers，這意味著跨平台的 PWA 成為了可能。快來看看這次發布都有哪些內容。
測試不太方便
還不能直接在 iOS 上測試這些新增的內容，因為 Safari 上的 Developer Tools 還不讓你查看 iOS 上的 Service Workers，並且也沒有用於使 Service Worker 和它的客戶端通信的客戶端 API 的 MessageChannel。但是我設法搗鼓了這個功能幾個小時。雖然我發現了一些 bug，但是我確信 WebKit 團隊將會在最終版本中解決這些不能通過單元測試的 bug。除此之外，我更傾向於關注 iOS PWA 與 Android PWA 比起來有哪些顯著的區別。
如果你已經發布了一個 PWA 或者正打算髮布一個 PWA，你一定會關注用戶體驗和在 iOS 上可能遇到的問題。
18 個月之前（差不多已經有一年半時間了吧！？），我發布了一篇文章「Don"tuse iOS meta tags irresponsibly in your Progressive Web Apps.」諸如 Twitter 和 Flipkart 等公司那時注意到這些問題，然後刪除掉了 iOS meta 標籤或者解決了那些問題（歡迎免費諮詢）。
那時的問題是，一些公司沒有經過測試並意識到 Android 上的 PWA 與 iOS 的區別，就決定通過 Apple meta 標籤來實現 iOS 上的主屏支持。
很遺憾，我不得不說問題和我 18 個月之前所說的仍然一樣，只有一個大的區別：現在你不用再兼容 iOS；iOS 會支持 Web App Manifest，因此你的 PWA 會自動成為 iOS PWA。但是，Apple 支持 PWA 的方式和 Android 不太一樣，這意味著：Cupertino，我們有麻煩了。
安裝的圖標只在線可用
如果你在 Home Screen 安裝你的 PWA，Service Workers 會被註冊但是不運行（SW 不將 Web App 作為一個客戶端），因此不要在 beta1 版中期望離線體驗。但是，我認為這是一個 bug 導致的，應該會在將來的版本中解決。
在 Beta1 中不支持主屏離線 PWA
PWAs：克隆攻擊
Safari 上的 WebView 可通過 HTTPS 訪問 Service Workers API。這些 WebView（即，Chrome、Firefox 和 Facebook 的 App 內置瀏覽器等）會被 Apps 添加到 Home Screen（Web.app）和 Safari View Controller（例如，當你點擊 iOS 版 Twitter 上的鏈接時）。
這聽起來不錯，對吧？但是，這裡有一個嚴重的問題：在 Safari 上，每個 App 的 WebView 和主屏 Web Apps 上的引擎不會共享 Service Workers，也不會共享 Cache Storage，這意味著用戶最終會在同一台設備上有同一個 PWA 的所有文件的多份拷貝。
你也許會想：嗨，Max，在 Android 和其它瀏覽器（Chrome、Firefox、Opera、Samsung Internet、UC Web）上也有這樣的問題。你說的對，但是這裡有些不同。在 Android 上，操作系統的 WebView 不支持 Service Workers，主屏上的 PWA 共享那個圖標所屬的瀏覽器的 SW 和緩存。另外，在同一台設備的不同瀏覽器上載入相同的 Web Apps 似乎不怎麼常見。
現在，假如說，你是一個 iOS 用戶並且經常使用一個 PWA，例如 Twitter Lite。當你特別想使用它的時候，你打開瀏覽器 (或者 WebView)，例如 iOS 版的 Chrome 或 Firefox。你得到這個 App 的一份拷貝。假如你又把它添加到 Home Screen，那麼你的設備上就有了那個 App 的第二份拷貝。在 iOS 上，如果你在 Mail 上收到一個指向到某個 tweet 的鏈接，由於你不能改變默認瀏覽器，Safari 會自動打開，然後這個 App 的第三份拷貝就會被「安裝」到你的設備上。結束了嗎？還沒有。如果你使用 Facebook 或者其它提供 App 內置瀏覽器的一些新聞 Apps，當你點擊指向某個 tweet 的鏈接或者 Twitter 賬戶時，你會得到另外一份拷貝！幸運的是，Safari View Controller 似乎與 Safari 共享 SW 和緩存。
同一個 PWA 在同一個設備上有 3 個不同的 service workers（可以通過 ID 區分），從左到右依次是：Safari、Chrome 和 Facebook。
因此，iOS 用戶可能最終會在同一台設備上有同一個 PWA 的 4 份或者更多的拷貝（我說的是 service workers 和緩存的文件，而不是圖標）。
Web App Manifest 支持
當你的 HTML 中有一個 manifest 鏈接，Safari 會使用這個 manifest 鏈接而不是老的非標準的 app-mobile-* meta 標籤。那簡直太棒了！然而，在 beta1 中，與 Android 相比，你也許會遇到一些預料之外的行為。
讓我們說說哪些屬性被忽略了（但是由於這只是 beta1，因此我不知道哪些功能會實現而哪些屬性不會）：
另一方面，令我驚訝的是，start_url 被鄭重提出，這相對於先前的 Add to the Home Screen 來說，是一個巨大的改變。現在，使用 pushState 的單頁應用在將應用添加到 iOS 的主屏來方便從 home 頁啟動時，不再需要使用奇怪的方式。然而，要記住的是，來自 manifest 配置的 URL 會顯示在對話框中。
另外，display-mode CSS media queries 正常生效。
獨立模式的 scope 和鏈接
當你用元素創建一個鏈接時，Manifest 中的 scope 配置會產生不同的效果。這個鏈接應該在 PWA 內部打開，還是在一個瀏覽器中打開？
Android 瀏覽器通常在瀏覽器或一個 Custom Tab 頁中打開 PWA 上下文範圍的 URL。如果你不指定 Web App Manifset 中的 scope 屬性，Android 通常會將 manifest 所在的文件夾作為 scope，而這通常是符合預期的行為。
如果不指定 scope 屬性，Safari 不會定義一個默認的 scope，如果是這種情況，那麼你的 PWA 中的每一個鏈接都會在你的 App 的 iOS 窗口中打開。這會造成什麼問題？這是 iOS，沒有返回按鈕和返回手勢，因此用戶可能會被鎖在你鏈接的外部網站。如果你指定 scope，一切都會和 Android 類似地生效，超出 scope 的目的鏈接會在 Safari 中打開——有一個到你的 PWA 的返回按鈕（狀態欄上的一個小按鈕）。
每次返回主屏，iOS 都會重新載入 PWA
不幸的是，iOS 上的 Home Screen Web Apps 曾經存在的一個 bug 還存在。難道它是一個正常的功能？每當離開 PWA，你就會失去上下文信息，而當用戶返回的時候，PWA 會從零開始重新載入。
就性能、耗電和用戶感知問題來說，這個行為會造成更糟糕的問題。如果你鏈接到外部站點，iOS 上的返回按鈕會從零開始載入 PWA，這會花費一些時間而用戶可能並不希望這樣（你可以使用 local storage 來繞過這個問題，但是，這並不是一個理想的方案）。
另外，對於像 Twitter 之類的使用雙因子認知方案的 App 來說有一個非常嚴重的問題。如果你需要到另外一個 App 去獲得一個 token，或者打開一個文本消息或郵件，你就會離開 PWA。當你返回去粘貼 code 的時候，你已經丟失了上下文狀態，然後你需要重新開啟登錄流程，而這樣你剛剛獲取的 code 也就失效了。我登錄 Twitter 的時候就是這樣！這意味著，iOS 上的 Twitter PWA 對我來說完全不可用。
不支持的功能
不幸的是，iOS PWA 不支持 Web App Banner 和 Manifest 規範的 appinstalled 等事件，因此你需要尋找其它方法來監測這個事件（你可能會用 start_url 的 hash 值和 navigator.standalone 來實現監測）。
與預期中一樣，即使推送通知的需求在今天非常迫切，iOS PWA 也不支持 Web 推送通知（我了解 Apple，它不會一次性給我們所有東西）。另外，iOS PWA 不支持背景同步，也沒有 Web 分享 API。從 iOS 的視角來看，最後一點簡直不是個問題，Web 分享功能應該直接使用原生的 SocialKit 框架實現。
UX 問題和 bug
正如我之前的文章中說的，iOS 有一些不同，例如：
1. 在 iOS，你沒有一個物理的或邏輯上的返回按鈕或手勢。你必須總是在用戶界面中提供一個返回按鈕。這意味著，你不能使用 OAuth 登錄機製作為頂級 document（這樣會無法返回）。如下圖所示，我在 Twitter Lite PWA 上點擊「登錄」；沒有辦法返回或者取消這個操作。即使我進入郵箱，我也沒有辦法再訪問登錄頁面。
在 Twitter Lite 中無法退出這個頁面
2. 在 iOS 上你不能使用透明的圖標。大多數 PWA 在 Android 上使用圓形圖標，如果在 iOS 上也使用圓形圖標，透明顏色的部分就會變成黑色，這應該不是一個好主意。
PWA 圖標增加到 iOS 時顯示透明的原始背景不符合 iOS 設計指南
3. iOS 上已經存在了 5 年的狀態欄 bug 依然存在。如果你不做任何聲明，用戶的狀態欄就會消失，沒有時鐘、電量和 wifi 圖標（技術上來說，這是黑色遮蓋了黑色）。解決這個問題的方法是使用 status-bar meta 標籤，現在又支持白色、黑色和灰色半透明來實現全屏體驗（這裡需要特別注意 iPhone X，你可能要在 CSS 中使用新的 notch-helpers）。由於某些原因，黑色和灰色半透明現在被標記為 deprecated 並且將來會被移除。我猜是因為要優先考慮 manifest 中的 theme-color 的緣故，但是為什麼標記黑色為 deprecated 但不標記白色呢？
Tinder 使用 status bar meta 標籤來讓狀態欄顯示白色，而 Twitter 沒有使用 status bar meta 標籤，因此你會看到 Twitter 的狀態欄上沒有時鐘和狀態欄圖標。
我們還有時間來改進
Apple 還有改進的空間，可以讓我們開發 PWA 更容易一些。同時，我們也還有一些時間來檢查自己的 PWA，例如：
※2018年不可錯過的12個移動UX設計趨勢
※Uber的App是如何實現其商業需求的？
TAG:移動開發前線 |