趣談 iOS Universal Link_37手遊iOS技術運營團隊

作者：iHTCboy

本文對 iOS Universal Link（通用連結）的淺入淺出介紹，從產品的角度來了解其發展歷程。

1、瞭解 Universal Link 背後的故事

2、學習 Universal Link 功能的使用

3、總結 Universal Link 產品的思考

一、前言

說起 Universal Link（通用連結），對於有過 iOS 開發的同學，一定有用上過。目前在申請微信分享或登陸時，需要配置 Universal Link 連結。對於 Universal Link，大家應該都瞭解：

蘋果 WWDC 2015 提出的 iOS 9 的新功能。
方便地通過開啟一個 https 連結來直接啟動 App (手機有安裝 App 的情況下)。
實現 web-app 的無縫連結時，能夠提供極佳的使用者體驗。

但是，反過來說，為什麼需要 Universal Link ? 這就是本文想要趣談的一個內容。以下內容，是基於之前在團隊分享的內容整理而成。

二、為什麼需要 Universal Link ?

我們知道一個新事物的出現，肯定不是憑空出現，同理，Universal Link 的出現，肯定是基於某個原因或者基礎而產生。所以，Universal Link 基於 Scheme 基礎上而提出來的。

URL Scheme

URL Scheme 一般用在在一個 App 裡跳轉到另一個 App，屬於應用間的跳轉。當然在瀏覽器(也可以理解為是 App) web 頁面也可以通過 scheme:// 跳轉到 App，但是這種方式在每次跳轉的時候都會彈框詢問，如果裝置中沒有安裝此 App 則會直接彈出錯誤提示，體驗不友好。大家對以下 scheme 應該不會陌生：

```http scheme://

weixin://dl/moments（朋友圈） weixin://scanqrcode（微信掃碼） alipayqr://platformapi/startapp?saId=10000007（支付寶掃碼） shoebox:// （Apple Pay） ```

為什麼會出現 URL Scheme ？

那麼，另一個問題又來了，為什麼會出現 URL Scheme ？

在當年 iPhoneOS 出來時，就已經是有沙盒機制，導致二個 App 之間無法讀取對方的沙盒空間，無法直接通訊，所以，蘋果提供了 Apple URL Scheme Reference 來解決自家的 app 無法互動的問題。

舉例來說，在 Safari 瀏覽器看到某個網頁上的電話號碼，能不能直接調起撥打電話？我們知道可以這樣編碼：

```html HTML link: 1-408-555-5555

Native app URL string: tel:1-408-555-5555 ```

可以看蘋果的文件看到，URL Schemes 是跟 iPhoneOS 開放給開發者，詳細的蘋果 URL Schemes 可以文件：About Apple URL Schemes。

使用 URL Schemes 最多的 App 應該是效率工具類，因為它們有工作流的需求，所以它們把 URL Schemes 玩出了很多花樣，包含 callback-URL 回撥功能。

Scheme 缺點是什麼 ?

出現 Universal Link，那麼說明 URL Schemes 有什麼不足呢？那可以反過來說，Universal Link 有什麼優點呢？

Universal Link 優點

Universal Link 優點，主要有 4 個：

通用性
靈活性
安全性
隱私性

通用性：一個 URL 對你的網站和 App 都通用，Universal Links 是標準的 URL 格式，而自定義 URL Scheme 可能理解為特殊 URL 方案，預設只有你的 App 能解析，瀏覽器無法解析。

靈活性：即使未安裝你的 App，Universal Links 也可以使用。未安裝你的應用程式時，開啟連結，Safari 中開啟顯示你網站的內容，是符合使用者預期的體驗，同時，網頁可以顯示跳轉 AppStore 下載的引導，進一步的提升使用者體驗。

安全性：只有開發者自己的網路域名配置了 apple-app-site-association，才能呼叫對應的 App。而 URL Scheme 配置的 Scheme，任意的 App 都可以配置相同的 Scheme，無法保證開發者 App 的安全呼叫。另外，當用戶安裝你的 App 時，iOS 會檢查你已上傳到網路伺服器的檔案配置，以確保只有你的網站允許呼叫您的 App。

隱私性：很久以前，大家都可以利用 Scheme 檢查 App 是否安裝，這樣有什麼作用呢？其實，當你知道使用者都安裝了什麼應用後，可以分析使用者的喜好或習慣，當然，目前。另一方面，很多 App 會冒充註冊知名的 App scheme 從而攔截調合法 App 的 scheme 調起。

注：iOS 9 開始蘋果把 URL Schemes 改為白名單機制，也就是隻有配置了白名單的 scheme 才可正常檢查其他應用是否安裝。同時，最多隻能設定 50 個不同的 Schemes 白名單（超出 50 個的 schemes 呼叫 canOpenURL 返回 NO）。

另外，微信建立應用時，必須配置 Universal Link 連結，詳細見文件：微信開放平臺釋出新版本SDK，請開發者儘快更新。從安全性和隱私性來說，微信是做的最好和最前衛，連海外 Facebook、Google 的 SDK 現在都還沒有提出 Universal Link 的想法。

Universal Link 配置

只支援 iOS 9+
擁有一個域名
通過 SSL 訪問域名(即支援HTTPS)
上傳一個 JSON 檔案到域名下(名為 apple-app-site-association 的json格式檔案)

關於 Universal Link 的配置，網上已經有很多教程，這裡就不再贅述了。具體可以教程官方文件： Support Universal Links、Supporting Universal Links in Your App。

Universal Link 坑點

雖然蘋果提供 http://search.developer.apple.com/appsearch-validation-tool/ 網頁讓開發者檢查 Universal Link 配置是否正常，但是檢查不正常的連結，Universal Link 可能是正常的。最大的坑就是必須要跨域，比如配置 Universal Link 連結為：http://applink.app.com，那麼不能直接在頁面中呼叫此連結來喚起 App，必然是其它二級域名，所以，一般 Universal Link 配置連結是用一個單獨的二級域名，與業務域名分開。

最後，最常用的檢查配置是否正常的方式有2個：

Universal Link 特性回顧

最後，回顧一下，Universal Link 這幾年以來的新特性。

在 2015 年 iOS 9 推出 Universal Link 功能，在 2017 年在 tvOS 端推出。

直到 2019年，支援精細化地址匹配，可以多個 App 共用一套配置、路徑等。

舉例來說，可以萬用字元匹配。

*：星號匹配 0 個或多個字元，並且貪婪地匹配。它將匹配儘可能多的字元。
?：問號匹配一個字元。
?*：要匹配至少一個字元，請使用問號，後跟星號。

支援 macOS 10.15 以上，需要注意，Mac 的 App，如果是從 Mac AppStore 下載的 App，預設Universal Link 已經生效，而開發者自己分發的 App 則至少需要開啟一次之後才能生效。

2020 年，蘋果釋出了 SwiftUI，跨平臺開發的 UI 框架（支援 iOS、macOS、tvOS、watchOS），所以，如果自然的也要支援 watchOS 啦。需要注意的是，如果 Universal Link 無效，則 watchOS 不能處理，會提示錯誤資訊。因為雖然從 watchOS 5 開始支援 WebKit，但至今 watchOS 還沒有內建 Safari 瀏覽器。哈哈，不知道大家是否期待支援~

同時，支援大小寫忽略的模式匹配，通過配置 "caseSensitive": false，來取消大小寫敏感。解決前端不同頁面或者大小寫的問題。

Unicode 模式的支援，比如中文 螞蟻上樹，預設情況下需要 ulr encode 才能讀取。通過 "percentEncoded": false 這樣用什麼語言都直接顯示，方便顯示和維護，也減少了連結長度。

最後一個重點功能，替代變數的支援，比如 App 在多國家地區出售不同產品，那麼可能某個國家或地區不銷售某個產品，放在以前就需要寫一堆的/en_US/、 /fr_CA/ 不能的語言地區標識。

現在，蘋果預設提供了常用的變數，舉例來說，用 $(alpha) 來表示 [ "A","a", "B", "b", "C", ... "Z", "z" ] 內任意的字元。其它同理。

舉例來說，通過欄位 "substitutionVariables": 來自定義字符集，然後可以套用到 "components": 裡，用 $() 來包含替換。

如上圖中，"/$(lang)_CA/$(Canadian food)/", "percentEncoded": false 表示匹配任意語言的加拿大下的 Canadian food 包含的產品，並且是用 Unicode 編碼，因為最後一個產品是 "tête-de-violon" 非英文字元。同理，第二個包含 "exclude": true，表示排除此路徑。

原來的 Universal Link 預設是使用者安裝應用時就通過 App 裡配置的 URL 請求 apple-app-site-association 配置檔案內容。但可能因為開發者網站的部署距離使用者遠近不同，導致訪問速度無法保障，所以，蘋果改為通過 Apple CDN 來請求 apple-app-site-association 配置檔案並快取起來，來針對不用地區的使用者，加速配置檔案的獲取。

最後，蘋果提供繞過 CDN 下載配置檔案的方法，也是方便開發者進行測試 Universal Link。具體來說，就是在設定中的 Developer 下 Associated Domains Development，然後在 Xcode 配置 associated-domains Universal Link 連結時，拼接 ?mode=developer，這樣表示開發者模組，此時的 Universal Link 可以是內網部署，不需要外網部署，非常的方便除錯。

三、總結

最後，我們從產品的角度來總結一下 URL Scheme 和 Universal Link 的功能發展。

URL Scheme 從最初的打破 App 之間無聯絡的溝通，到效率工具 App 的重度依賴，其中 Workflow App 當年最為流行，後來被蘋果收購。正好剛剛說的，被蘋果收購後可以獲取更多的系統級許可權，其實對於效率類 App 是非常利好的！後來，蘋果把 Workflow 改名 Shortcuts（捷徑），並且能與 Siri 互動。

舉例來說，Shortcuts 能讀取 NFC 卡的許可權，並且可以開啟所有的 App！不需要依賴 URL Scheme，開啟所有的 App！所以，URL Scheme 的作用，對於 Shortcuts 來說，根本不需要依賴了。

當然，快捷開啟 App，不得不說到 3D Touch，可能從蘋果來說，這是一個創新的互動方式，但是使用者並沒有習慣起來。隱藏式的互動設計，客觀來講，對於使用者體驗確實不友好。

當然，最後 URL Scheme 還是會長存！因為第三方 App 之間無法直接互動。除了互動，就是開啟 App 某個功能或者路徑，利用 PWA 新增到主螢幕也是一種方案，但是對於一般使用者需要教導，不太好推廣。

最後，Universal Link 總結來說，通用性、安全性、靈活性、隱私性，對於開發者來說，其他人無法偽造，所以的配置都由開發者來掌握。簡單來說，通過域名和後臺控制，可以隨時調整，對使用者無影響。

舉例來說，知乎在 web 頁面，利用 Universal Link 顯示 “App 內開啟”，而頂部是利用 Smart App Banners 在使用者安裝 App 和未安裝 App 時，展示開啟或者顯示（點選時開啟 App，或者開啟 AppStore 顯示）。當然，知乎還用了 URL Scheme 兜底，最後，就是顯示 Universal Link 的引導安裝的 web 落地頁面。

Handoff 也需要使用 Universal Link 的配置檔案來驗證許可權，Shared Web Credentials 也是優化 web 和 app 之間共享賬號登陸。

去年蘋果推出的小程式 App Clips（輕 App）也是使用 apple-app-site-association 來配置許可權。

今年推出的 in-app events AppStore 商店 App 內事件功能，也需要配置 Universal Link 。

最後的總結，我們說了 URL Scheme 和 Universal Link 的來歷，從目前來說，Universal Link 並不能完全替換 URL Scheme，但 Universal Link 因為其優點，蘋果把越來越多的功能許可權驗證，放到了 Universal Link 配置上，相信未來還會有更多 Universal Link。所以，瞭解這些功能的出現的背後原因和解決的問題，對於我們掌握事物都有幫助，希望大家有所收穫，如果覺得可以，歡迎點贊轉發啊~

歡迎大家一起在評論區交流~

歡迎關注我們，瞭解更多 iOS 和 Apple 的動態~

趣談 iOS Universal Link