iOS 9，為前端世界都帶來了些什么？

注！ 該譯文存在大量英文術語，筆者將默認讀者知曉 ES6、viewport、native app、webview 等常用前端術語，并不對這些已知術語進行漢語翻譯
對于新發布或較新的產品名稱與技術術語，諸如 Apple Pen、Split View 等專有名詞，筆者將在文中使用其英文名，但會嘗試對部分名詞進行漢語標注
另外，出于對 wiki 式閱讀的偏愛，筆者為您添加了很多額外的鏈接，方便您查閱文檔或出處

簡而言之

如果你不想閱讀整篇文章，這里為你準備了一個總結：

新的設備特性

• iPhone 6s 與 6s Plus 擁有 “3D Touch”，這是一個全新的硬件特性，它可以偵測壓力，是一個可以讓你拿到手指壓力數據的 API
• iPad Pro 的 viewport 為 1024px，與以往的 iPad 全都不同
• 想在 iPad Pro 上支持新的 Apple Pen？不好意思，目前似乎并沒有適用于網站的 API

新的操作系統特性（與 web 相關的）

• iPad 上的 Safari 現在可以通過 Split View（分屏視圖）與其他應用一起使用，這意味著新的 viewport 尺寸將會越來越常見
• 新的 Safari View Controller（SFSafariViewController）可以讓你在 native app 內提供與 Safari 界面、行為連貫一致的應用內網頁瀏覽體驗
• 注意啦！Safari 新加入了 Content Blocker（內容攔截器）。以后，并不是所有的訪問都一定會出現在你的 Google Analytics 了
• Universal Links 可以讓應用的擁有者在 iOS 內部“占有”自己的域名。因此，訪問 yourdomain.com 將會打開你的應用（類似 Android 的 Intents 機制）
• App Search（應用搜索）：現在，Apple 將會抓取你的網頁內容（與 native app 內容）用于 Spotlight 與 Siri 的搜索結果，想知道你的標簽都兼容嗎？
• 你的網站現在可以通過 JavaScript API 訪問 iCloud 的用戶數據

新的 API 支持

• Performance Timing API 在 iOS 9 得到回歸
• 關于 HTML5 Video，你現在可以在支持 Picture in Picture（畫中畫）的 iPad 設備上提供這項新功能；你的視頻甚至可以在 Safari 關閉后繼續播放
• 更好的 ES6 支持：classes（類）, computed properties（可計算屬性）, template literals（模版字符串）等
• Backdrop CSS filters（背景濾鏡）
• CSS @supports 與 CSS Supports JavaScript API
• CSS Level4 偽選擇器
• 用于支持分頁內容的 CSS Scroll Snapping
• WKWebView 現在可以訪問本地文件了
• 我們仍然需要等待 Push Notification，camera access，Service Workers 這些現代 web API 的到來

新的操作系統

• 新一代 Apple TV 的 tvOS： 沒有瀏覽器，也沒有 webview。但是 JavaScript、XHR 和 DOM 可以通過一個叫做 TVML 的標記語言來使用
• Apple Watch 的 watchOS：完全沒有任何瀏覽器和 webview

再注！ 由于原文寫于 Apple 發布會之前，為了不讓讀者感到奇怪，筆者將會對文章進行適當改寫與補充，以保證本文的連貫性

新的 iOS 設備特性

iPhones 6s 與 3D Touch

從 web 設計與開發的角度來說，新的 iPhone 6s 與 6s Plus 與之前的版本并沒有太多差別。不過，有一個特性注定會吸引我們的目光：3D Touch

我們無法確定 Apple 是不是只是重命名了一下 “Force Touch”（用于 Apple Watch、TrackPad 2 與最新的 MacBook 上）或者 3D Touch 的確是一個為 iPhone 定制的似曾相識卻不同的東西。3D Touch 允許操作系統和應用偵測每一個手指與屏幕接觸時的壓力。從用戶體驗的角度來說，最大的變化莫過于當你用點力去觸碰或者拖拽屏幕時，操作系統將會觸發諸如 peek，pop 這些新機制。那么問題來了：我們是否能夠在網站中使用這個新玩意呢？讓我們一點點來看：

iOS 9 搭載的 Safari 包含了一些用于 “Force Touch” 的新 API，但它們其實并不是那個用于 iPhone 6s 3D Touch 的 API。你可以理解為這些 API 就是 MacBook 版 Safari 里為 Force Touch 準備的那些 API ，因為共享一套 codebase，所以它理所當然得存在了 iOS 版里而已。

Force Touch API 為我們添加了兩個新東西：

1. 你的 click 事件處理函數將會從 MouseEvent 中收到一個新的屬性：webkitForce
2. DOM 也新增了四個事件：(webkit)mouseforcewillbegin，mouseforcedown，mouseforceup 與mouseforcechange。下邊的示意圖將告訴你這些事件是在何時被觸發的：

相信你已經從它們的名字中意識到了，這些事件都是基于鼠標而非觸摸的，畢竟它們是為 MacBook 設計的。并且，TouchEvent 也并沒有包含 webkitForce 這個屬性，它僅僅存在于 MouseEvent 里。在 iOS Safari 里，你確實可以找到 onwebkitmouseforce 這一系列事件處理器，但是很可惜它們并不會被觸發，click 返回的 MouseEvent 也永遠只能得到一個 webkitForce: 0

可喜可賀的是，故事還沒有結束。Touch Events v2 draft spec（觸摸事件第二版草案） 中正式添加了 force 屬性。3D Touch 也得以在 iPhone 6s 與 6s+ 中通過 TouchEvent 訪問到。不過，筆者也要在這里提醒大家，由于沒有 webkitmouseforcechange 這樣給力的事件，在手機上我們只能通過輪詢 TouchEvent 的做法 來不斷檢測壓力值的改變……非常坑爹

@Marcel Freinbichler 第一個在 推ter 上曬出了自己的 Demo。在 6s 或 new Macbook 的 Safari（目前僅 Safari 支持）上訪問就可以看到圓圈會隨著壓力放大。墻內的小伙伴可以訪問 Forcify 這個網址，體驗下 3D/Force Touch 帶來的的奇妙體驗。

如果你不巧在用不支持 3D/Force Touch 的設備，發現尼瑪用力按下去之后居然圓圈也有反映！？

放心，這真的不是你的設備突然習得了“感應壓力”這項技能，而是因為 Forcify 是一個用于在所有設備上 polyfill 3D/Force Touch API 的 JS 庫……它不但封裝了 OSX/iOS 兩個平臺之間 API 的差異，還使用”長按”來模擬了 force 值的變化……

iPad Pro

全新的 iPad Pro（12.9 寸）打破了以往 iPad 渲染網站的方式。在此之前，市面上所有的 iPad（從初代 iPad，到 iPad Air 4，到 iPad Mini）都是以 768px 的寬度提供 viewport。

而屏幕更大的 iPad Pro 選擇了寬 1024px 的 viewport，這使得它天生就能容納更多的內容。不少人說iPad Pro 就是抄 Microsft Surface Pro 的嘛……嗯哼，IE/Edge 在 Surface Pro 上就是以 1024px 作為視口寬度的……

從交互的角度上來說，iPad Pro 雖然不支持 3D Touch，但是可以搭配 Smart Keyboard 與/或 Apple Pen（帶有壓力偵測）使用。對于鍵盤其實并沒有什么好說的，如果一個網站在搭配鍵盤的桌面電腦上好用，它在 iPad Pro 上應該也不賴。而對于 Apple Pen，很可惜，目前似乎并沒有 API 能讓你在網站上獲得這根筆的壓力與角度。

新的 iOS 操作系統特性

iPad 上的多任務處理

自 iOS 9 起，iPad 允許兩個應用在同一時刻并肩執行，有三種方式：Slide Over，Split View 與Picture-in-Picture。不過，每一種方式都有其硬件需求，比如說 Slide Over 需要 iPad Air, iPad Mini 2 以上的設備，而 Split View 由于對內存的要求目前只支持 iPad Air 2 與 iPad Pro。

Slide Over（滑過來！）

Slide Over 支持的 App 并不多，不過 Safari 名列其中，這意味著我們的網站將可能在這個模式下被渲染。當網站處于 Slide Over 模式下時，它將在屏幕的右 1/4 位置渲染，并且置于其他 native app 之上。

這個模式也為 Responsive Web Design（響應式網站設計）提出了新的挑戰：一個只為 iPad 優化的網站，也需要能在該設備上以無需手動刷新的形式支持小屏幕的渲染。因此，如果你正在使用服務器端探測（RESS），那么你的 iPad 版本需要以某種方式包含手機版本的網站，或者在進入該模式后重新加載一次。（如果你不了解 RESS，你可以觀看我的另一篇博文）

在這個模式下，無論橫屏還是豎屏，所有的 iPad（包括 Pro）都會把你的網站以 320px 的 viewport 寬度進行渲染，就好像在一個大 iPhone 5 上一樣。你可以在 CSS 中通過 media query（媒體查詢）探測到這個模式：

/* iPad Air or iPad Mini */
(device-width: 768px) and (width: 320px)
/* iPad Pro */
(device-width: 1024px) and (width: 320px) 

Split View（分屏視圖）

在較新版本的 iPad 上，你可以將 Slide Over 的 Side View（側視圖）升級為 Split View。此時，兩個應用將以相同比例在你的屏幕上同時工作。

在這個模式下，我們的網站將可能……

• 以屏幕 1/3 比例渲染時，viewport 在 iPad Air/mini 猶如 iPhone 5，寬 320px。而在 iPad Pro 上則像是 iPhone 6：寬 375px
• 以屏幕 1/2 比例渲染時，viewport 在 iPad Air/mini 上呈現為 507px 寬，而在 iPad Pro（橫屏）下呈現為 678px 寬
• 以屏幕 2/3 比例渲染時，viewport 在 iPad Air/mini 上呈現為 694px 寬，而在 iPad Pro（橫屏）下呈現為 981px 寬

在一些較新版本的 iPad 上，使用 HTML5 video 標簽的網站可以將其暴露到 Picture in Picture 機制中。通過 API（本文稍后會講）或用戶的觸發，視頻可以獨立于網站在其他應用的上方繼續播放。

iOS 9 下的響應式網頁設計

下圖向你展示了 iOS 9 所有可能的 viewport 尺寸，檢查檢查你的響應式斷點都包含它們了嗎？

如果你用過 推ter 或者 非死book（或者微信，微博……），那么你一定知道很多 native app 在打開一個網頁鏈接時并不會默認使用 Safari。它們試圖讓你留在它們的應用里，所以通過提供 webview 讓你在應用內進行網頁瀏覽。可是問題在于，這類 webview 并不會與瀏覽器共享 cookies，sessions，autofill（自動填充）與 bookmark（書簽），為了解決這些問題，就有了 Safari View Controller。

現在，native app 可以使用 Safari View Controller 來打開網站，它提供與 Safari 完全一致的隱私政策、local storage，cookies、sessions 同時讓用戶留在你的 app 中，它通過一個 “Done”（完成）按鈕使用戶可以回到 native app 的上一個 controller。這個全新的 controller 還可以讓我們在 Share（分享）按鈕上添加自定義的操作，這些操作在用戶使用 Safari 應用時并不會出現。同時，native app 對這個自定義 Safari 實例具有完全的內容控制，你可以屏蔽不想被渲染的內容。

當你需要基于 web 的鑒權，比如 OAuth 時，使用 Safari View Controller 同樣是一個好主意，這樣就不再需要打開瀏覽器再重定向回你的應用。不過注意了，Safari View Controller 只適用于在線、公開的 web 內容。如果你的 web 內容假設在本地或者私服，那么 WKWebView 仍然是最推薦的選擇。

筆者八卦一下，Safari View Controller 實際上也算是半個社區推進的產物。早在 2014 年 12 月，Tumblr 的 iOS 工程師 Bryan 就發表了一篇著名的 We need a “Safari view controller” 敘述現有 webview 在第三方登錄鑒權時的窘境。
2015 年 6 月，Apple Safari 工程師 Ricky Mondello 的 推ter 宣告了這個設想的落地：You all asked for it. Come see me introduce it. Introducing Safari View Controller 1:30 PM, Tuesday. Nob Hill.

現在，iOS 9 上的 Safari 支持一種全新的 App Extensions（應用拓展）：Content Blocker（內容攔截器）。這類拓展以 native app 的形式存在，你可以在 App Store 上下載到，它們可以攔截 Safari 內的任何內容，包括：跟蹤器、廣告、自定義字體、大圖片、JavaScript 文件等等。

作為 web 開發者，盡管我們不能禁用 Content Blocker，我們仍然應該注意到它們的存在。諸如 Crystal 的一些攔截器宣稱他們可以提高網頁的打開速度。Crystal 聲稱可以加快網頁的加載速度 3.9 倍并且少用 53% 的帶寬。不過問題是：到底哪些東西被攔截器攔截了？這篇文章提到了一些我們未來可能會遇到的問題。

在 iOS 9 發布后，Peace，一個 Content Blocker，曾在 App Store 排名躋身前十。從用戶的角度來說，如果一個網站由于被 Content Blocker 攔截了某些重要資源而不能正常工作，你可以長按重新加載按鈕并且以不啟用 Content Blocker 的方式重新加載這個網站（見下圖，來自 http://MacWorld.com）

Content Blocker 能隱藏元素，也有能力通過 CSS 選擇器、域名、類型、或者 URL 來過濾并攔截某個文件的加載，Purify Blocker 給用戶提供了攔截某一種內容類型的進階選項，比如 Web Fonts。

UIWebView 已經被官方棄用，雖然它還在在那，不過它再也不會得到什么升級。與此相反，WKWebView 正在取代它的位置。一個最受期待的特性現在終于推出：加載本地文件到 WKWebView。因此，現在 Apache Cordova 應用與其他 web 內容都可以直接從 iOS 包中使用本地文件了，不再需要各種詭異的 hack 了。

此外，還有一些新特性也一并推出。比如說，通過 WKWebsiteDataStore，Objective-C 或 Swift 有能力查詢與管理 webview 的本地存儲（比如 localStorage 或 IndexedDB）。這就允許我們將原有的數據存儲替換成新的某些東西，比如說替換成一個不永久的（Chrome for iOS 的隱身模式就需要這種東西）

如果你既有一個網站，又有一個 native app，你現在可以通過 Universal Links 來增強用戶體驗。它允許你在操作系統內“占有”自己的域名，這樣，一切指向你網站的鏈接都會被重定向到你的 app。

目前，所有的 app 都是通過自定義 URI 來達到這個效果的，比如 comgooglemaps:// 就可以用來從網站或者其他原生 iOS 應用中打開 Google Maps。

想要提供這個特性的話，你首先需要在 native app 中實現 Deep Linking（深度鏈接），讓應用中的內容與 Safari 的 URL 吻合。然后，你需要在 Apple 的網站上關聯你的域名，取得這個域名的 SSL 認證并且把簽名后的 JSON 部署到該域名上。這是為了防止第三方的應用“占據”了屬于你而不屬于他們的域名，比如說 http://推ter.com 被非 推ter 的其他應用占據掉。

目前唯一的缺點是用戶好像并不能決定到底以哪種方式來打開內容（使用 web 還是 app），不過我們可以觀望一段時間看看它會如何發展。在不遠的這段時間里，你可能會發現在網站或 Google 搜索里點擊一個鏈接時會沒有任何預警的就跳進了 native app 里。

Apple 帶著自己的 web 蜘蛛殺進了搜索的市場，而我們需要支持它得以在 Siri 與 Spotlight 中提升自己的曝光率。這在我們同時擁有網站與 app 時尤為重要，因為現在 Apple 會索引你網站的內容，但打開時卻可能將用戶帶到了 app 里去。

盡管這會開啟 SEO 的新篇章，不過卻相當容易。你需要使用一些標簽標準，諸如 Web Schema、AppLinks、OpenGraph 或者 推ter Cards，配合上 App Banner 與 app-argument，如果你有你自己的 native app 的話。

關于“讓你的網頁支持 Apple 搜索”的更多詳情，請查閱 Apple 官方文檔 Mark Up Web Content

Apple 剛剛發布了一個 App Search Validation Tool（應用搜索驗證工具）來幫助你搞清楚，需要向你的網站添加什么才能支持 App Search

如果你擁有一個 native app，你很可能會將用戶數據保存在 iCloud 上。在過去，只有 iOS 與 Mac 應用被允許使用它。現在，通過 CloudKit JS，你的網站也可以連接上 iCloud 數據了。

現在，當你鏈接到一個 native app 時（通過自定義 URI 或者 Universal Link），Safari 會詢問用戶是否想要使用 native app 打開這個鏈接（見下圖）。如果用戶同意了，這個應用將被打開，并且在左上角會有一個返回按鈕可以返回 Safari ，返回到你的網站。

新的 API 支持

Navigation Timing API 在 iOS 9 迎來了回歸。讓我們回憶一下，這貨添加于 8.0 卻在一周后的 8.1 中去掉了。這對于 Web 性能是個好消息。通過這個 API，我們可以更精確的測量時間，還可以獲得一系列有關加載過程的時間戳，它們對于追蹤與在真實場景中做決策來改進用戶體驗都非常有用。

PiP API（被稱為 Presentation Mode API）目前只支持 iOS，它允許我們手動讓一個 <video> 元素進入或離開 PiP 模式如果 video.webkitSupportsPresentationMode 是支持的。

舉個例子，我們可以在內嵌模式與 PiP 模式中切換：

video.webkitSetPresentationMode(
    video.webkitPresentationMode === "picture-in-picture" ?
    "inline" : 
    "picture-in-picture"
); 

我們還可以通過新的 onwebkitpresentationmodechanged 事件來檢測 Presentation Mode（展示模式）的變化。

iOS 7 與最近的 Mac OS 使用 Backdrop filter（背景濾鏡）來模糊背景（指 native 開發），而在網站上實現這個卻并不容易。

iOS 9 上的 Safari 現在支持了來自 Filter Effect v2 spec（濾鏡特效第二版規范）的 backdrop-filter。比如說，我們可以使用一個半透明的背景并且對其背后的背景使用濾鏡：

header {
   background-color: rgba(255, 255, 255, 0.4);
   -webkit-backdrop-filter: blur(5px);
   backdrop-filter: blur(5px);
} 

在 web 上實現分頁內容（比如相冊跑馬燈）總是非常麻煩，無論是使用 JavaScript 框架、touch 事件還是 hacking 滾動條等等。Apple 新添加了一個很贊的 CSS 特性叫做 CSS Scroll Snapping。這個特性新增了一系列的 CSS 屬性讓你定義規則或者不規則的 snap zone（停留區域），這樣滾動的位置就會“啪”地一下停在這個區域，而非像以前一樣可以停在任何地方。

來看個例子：

#photo-gallery{
    width: 100%;
    overflow-x: scroll;
    -webkit-scroll-snap-points-x: repeat(100%);
    -webkit-scroll-snap-type: mandatory;
} 

想要看個跑起來后的例子？筆者為大家準備了 webkit 的官方 demo，不過這個屬性目前只支持 iOS 9 Safari 哦，并不支持 webview

CSS Supports，包括 CSS @supports 與來自 CSS Conditional Rules Module Level 3 spec 的 JavaScript CSS Supports API 都在 iOS 上迎來降臨。現在，我們可以針對某個 CSS 屬性的特定值的支持情況來編寫代碼：

@supports(-webkit-scroll-snap-type: mandatory) {
    /* we use it */
} 

同樣，使用 JavaScript：

if (CSS.supports("-webkit-scroll-snap-type", "mandatory")) {} 

• ECMAScript 6 的更完善支持：classed、computed properties、template literial 與 weak sets
• 新的 CSS Level4 偽類/元素選擇器：:not、:matches、:any-link、:placeholder-shown、:read-write、:read-only
• Native app 現在可以通過 extension 來向 Safari 的 Shared Links（分享鏈接）窗口上注入信息
• 大量無前綴 CSS 屬性的支持（終于），比如 transition、animation、@keyframes、flex 與 columns
• Mac OS El Capitán 上的 Safari 9 提供了一個全新設計的 Web Inspector（Web 檢查器）。幸運的是，iOS 9 的遠程調試完全兼容 Mac OS 上的 Safari 8，所以你倒是不用急著升級你的 Mac OS
• iOS 9 通過 -apple-font 加入了一些 Dynamic Fonts（動態字體），并且它們現在應用的是 Apple 的新字體：San Francisco，筆者的博客就已經用上它啦
• scrollingElement 現在可用了
• <input type=file> 現在允許你從 iCloud Drive 與已安裝的第三方應用，比如 Google Drive 中選擇文件

• 當你加載一個 HTTPS 協議的頁面時，你不能混用 HTTP 與 HTTPS 的資源

Bugs

Bug 通常都要在幾周之后才會顯露出來，我也會持續跟進并更新這篇文章。目前為止，我的發現如下：

• 對于 Home Screen webapps（添加至主屏的 web 應用），apple-mobile-web-app-status-bar-style 這個 meta 標簽不起作用了！所以你現在不能再像過去一樣使用 black-translucent 讓你的 webapp 渲染在狀態欄的后面了。（iOS 9.2 fixed 了這個 bug）
• Speech Synthesis API （語音綜合 API）不再工作了

仍在等待……

當 Mac 上的 Safari、桌面電腦與 Android 上的 Chrome 都已經為網站支持 Push Notification （通知推送）時，iOS 上的 Safari 仍然不支持這個特性。就 API 而言，我們仍然沒有：WebRTC、getUserMedia、Service Worker、FileSystem API、Network Information API、Battery Status API、Vibration API 等等……你又在 iOS 上等待哪些特性呢？

watchOS 與 tvOS

新發布的 watchOS 2.0 與 tvOS 9.0 都是基于 iOS 的操作系統，它們針對特定的設備發行（Apple Watch 與新的 Apple TV）。從用戶的角度來說，那里并沒有瀏覽器了。從開發者的角度，那里也沒有 Webview 了。

盡管有不少人抱怨（大部分都是針對 webview 的缺失），我并不能確定這是不是個壞主意。我猜測 Apple 會嘗試通過 Siri 來將 “web” 帶給 TV、手表、甚至 CarPlay 的用戶。所以，如果你遵循了上述的 “App Search” 的步驟，你的內容將可能通過 Siri 在這些設備上以 widget（小部件）或者快捷回復的形式變得可以訪問。

對于 Apple TV ，它支持使用 JavaScript、DOM API 與 XMLHttpRequest 來讓我們構建某種類似 Client-Server webapp 的東西。沒有 HTML 和 CSS，這是什么把戲？其實它支持的叫 TVML，是一種基于 XML、為那些可以被渲染在 TV 屏幕上的特定內容而優化后的標簽。這些標簽只可以在來自應用商店的 native app 中渲染，但是這些 TVML 是由服務器端來生成的。

著作權聲明

本文譯自 iOS 9, Safari and the Web: 3D Touch, new Responsive Web Design, Native integration and HTML5 APIs — Breaking the Mobile Web
譯者 黃玄，發布于 Hux Blog、前端外刊評論 - 知乎專欄 ，轉載請保留以上鏈接