iOSer 必知必會的深度連接技術——WWDC2019更新

iOSer做爲移動開發者中的一員，不得不說深度連接在當下這個「流量」時代已經成爲咱們的必修課了，那麼什麼是深度連接呢？簡單的說就是，能夠經過一個簡單的「連接」，打開App並直接進入該App中的內容頁。前提是該手機上已安裝該App，且該App須要支持深度連接。例如：在Safari裏看到的澎湃新聞App的某一篇新聞 「中國又一新的世界遺產...」 點擊下面滾動Banner上的「打開App」按鈕即可直接進入澎湃新聞App（已安裝）中對應的新聞頁面：

可見在移動端採用深度連接技術，極大的省去了用戶打開App、再搜索內容或者點擊某處進入指定頁面等繁瑣的操做，直接點擊網頁上的打開按鈕便可一鍵到達App內的指定頁面。

1、iOS上深度連接的由來

在介紹深度連接是怎麼來的以前，有一個基礎概念須要和你們同步一下：

SandBox（沙盒）

SandBox（沙盒）是蘋果官方規定的iOS系統強制應用程序只可以讀取應用程序內部數據，不能夠訪問其餘應用信息數據的一種機制。

1. 在iOS系統的設備中每個App都有本身的儲存空間；
2. App只能訪問本身沙盒目錄下的內容，不能訪問其它存儲空間的內容；
3. 應用程序的數據請求須要通過權限檢測，檢測不經過則不執行；

爲何使用沙盒？

SandBox（沙盒）是安全體系中的一種機制，從而蘋果公司在設計iOS系統時，考慮到應用之間的信息安全，對應用程序的訪問權限設置了限制。

SandBox（沙盒）的弊端

使用沙盒機制後App之間不能相互訪問進行通訊，從而使得App成爲一個個的信息孤島。（弱小可憐又無助）

如何解決SandBox（沙盒）問題？

不能說蘋果的初衷怎麼樣，可是帶來的問題是顯而易見的，那麼其實蘋果早在2010年 iOS 4 的時候就已經意識到App信息孤立的問題了，因此推出了 URL Scheme 技術，此技術使得iOS系統能夠經過特定的URL方式傳遞參數給另一個App。例如：iOSer://userid=123456&name=sands 。

不得不認可，這個技術確實解決了當初比較棘手的問題，可是在突飛猛進的今天，URL Scheme的詬病也日漸顯著，好比想要實現兩個App之間的跳轉則須要兼併開發，再好比URL Scheme可以打開App的前提是已經安裝了App，若是沒有安裝則必定會報錯，相信下面的錯誤你們必定都見的很多，更重要的是如今愈來愈多的瀏覽器已經再也不支持URL Scheme了，這必然讓咱們不得不另闢蹊徑。

相信蘋果也是深入的意識到了URL Scheme已經再也不是長久之計了，因此蘋果在2015年 iOS 9 中隆重推出了 Universal Links（通用連接） 。

2、深度連接解決的問題

Universal Links(通用鏈接) 一種可以經過點擊傳統 HTTPS連接 來 啓動App 或者 打開對應網站 的技術。

經過惟一的網址, 不須要特別的URI Scheme就能夠連接一個特定App裏面的視圖 。好比：一個App分享內容到微信，用戶在微信內置瀏覽器中看到H5頁面內容，而後用戶點擊觸發Universal Links連接後，便可直接打開App內相同的頁面內容。（PS: 因爲微信 6.5 版本以後作了 屏蔽操做 ，致使沒法直接打開App了，但這並不影響系統引導。）

NOTE

Universal links let users open your app when they tap links to your website within WKWebView and UIWebView views and Safari pages, in addition to links that result in a call to openURL:, such as those that occur in Mail, Messages, and other apps.

When a user is browsing your website in Safari and they tap a universal link to a URL in the same domain as the current webpage, iOS respects the user’s most likely intent and opens the link in Safari. If the user taps a universal link to a URL in a different domain, iOS opens the link in your app.

For users who are running versions of iOS earlier than 9.0, tapping a universal link to your website opens the link in Safari.

首先，這是一種標準的HTTPS連接，爲何要強調這一點呢？由於它解決了一個很核心的問題，即便你的設備上沒有安裝App，那麼點擊該連接也不會出現上面「Safari沒法打開該網頁，由於網址無效」的報錯，它能夠看成普通網頁正常被訪問，爲用戶體驗層面的提高提供了更多的可能。

其次，經過 Universal Links 跳轉到本身App從而進行通信的方式不須要兩個App之間的兼併開發，別人的App裏不須要爲打開本身的App作任何配置，只須要本身開發配置好本身的App和網頁便可，無論本身的網頁是在哪個App裏被打開，網頁和App之間實現的 Universal Links 都一直有效。

最後，使用這種方式還有幾個細節優點點，好比省去了URL Scheme跳轉App前的系統確認提示框，相比之下更直接，另外，App未安裝時點擊以後直接訪問網頁，一方面解決了URL Scheme在瀏覽器層面不可知的成功或者失敗，同時還可以呈現給用戶網頁內容，引導用戶下載或是進行網頁操做，無論從哪一層面來講，這都是一種完勝URL Scheme的方式。

3、如何實現iOS上的深度連接

添加 Universal Links 的支持很簡單。你只須要三步便可實現：

• 建立一個 apple-app-site-association 文件，文件內容是關於你的App可以處理的URLs的JSON數據
• 上傳上面建立好的這個 apple-app-site-association 文件到你的支持HTTPS的Web服務器。你能夠將這個文件放到你服務器的根目錄下或者 .well-known 的子文件夾裏
• 在你的App裏配置、處理 Universal Links

建立和上傳 Association 文件

爲了在你的網站和App之間建立一個安全的鏈接，你創建了它們之間的信任關係。這個信任關係的創建分兩步：

• 一個是你添加到你的網站的 apple-app-site-association 文件
• 另外一個是你添加到你的App的 com.apple.developer.associated-domains 權限（這一部分在下面的 準備處理 Universal Links 的App 中介紹）

在您的apple-app-site-association文件中，您能夠指定網站中應做爲通用連接處理的路徑以及不該做爲通用連接處理的路徑。保持路徑列表至關短，並經過正則通配符的方式來匹配更多的路徑集。以下是一個 apple-app-site-association 文件的示例，該文件標識了應做爲通用連接處理的三個路徑。

{
    "applinks": {
        "apps": [],
        "details": [
            {
                "appID": "9JA89QQLNQ.com.mob.moblink",
                "paths": [ "/moblink/news/", "/videos/moblink/2019/*"]
            },
            {
                "appID": "ABCD1234.com.mob.moblink",
                "paths": [ "*" ]
            }
        ]
    }
}
複製代碼

注意

不要 在 apple-app-site-association 文件名後面添加 .json 後綴 。

• apps：這個key必須存在，而且對應value必須是一個空數組
• details：這個key對應的value是一個包含一個或多個字典的數組，其中每個字典都對應一個網站支持的app，另外，數組中字典的順序決定了系統查詢匹配的順序，因此你能夠指定app只處理你網站的部分路徑
• appID：這個key對應的value是Team ID後面拼接上Bundle ID，這個很重要，千萬不能錯
• paths：這個key對應的value是指定你的網站中哪些路徑是須要（或者不須要）app處理的字符串數組。

不須要匹配的path則在對應路徑前面加 NOT 便可，例如："paths": [ "/moblink/news/", "NOT /videos/moblink/2010/*", "/videos/moblink/201?/*"]因爲系統會順序查找路徑規則，一旦發現規則相匹配時則中止查找，因此你應該將優先級高的寫在優先級低的後面。若是將前面的示例改成： "paths": [ "/moblink/news/", "/videos/moblink/201?/*", "NOT /videos/moblink/2010/*"]則數組中最後一條規則就沒有用了，由於它必定會被前一條規則攔截掉。

在 apple-app-site-association 文件中有不少種方式來指定網站路徑。你能夠：

• 用 * 來指定你的整個網頁都支持
• 包含一個特殊的URL，例如 /moblink/news 來指定部分連接支持
• 在特殊URL後面加 * ，例如 /videos/moblink/2017/* 來指定一組連接支持

注意
paths數組中的路徑字符串是大小寫敏感的，必定要注意區分大小寫。

建立 apple-app-site-association 文件後，將其上傳到HTTPS Web服務器的根目錄或 .well-known 子目錄。該文件須要經過HTTPS直接訪問-無需重定向-位於 https://<domain>/apple-app-site-association 或 https://<domain>/.well-known/apple-app-site-association 。接下來，你須要在你的App中處理 Universal Links。

準備處理 Universal Links 的App

Universal Links使用了兩項技術：第一個是在Web瀏覽器和App之間啓用Handoff的相同機制，第二個是共享Web憑據。關於這兩項技術能夠參考官方 Web Browser–to–Native App Handoff 和 Shared Web Credentials Reference 。當用戶點擊一個 Universal Link 時，iOS系統啓動你的App，而且帶了一個你能夠查詢到你的App是經過什麼方式被啓動的 NSUserActivity 對象參數到你的App裏。

要在你的App裏支持 Universal Links，只須要作以下兩步：

• 添加一個指定的你的App支持的域名權限
• 更新你的 AppDelegate 當接收到 NSUserActivity 對象時做出適當的響應

在你App的 com.apple.developer.associated-domains 權限裏，包含了全部你的App想要看成universal link處理的域名列表。在Xcode的項目主頁中，選擇 Capabilities tab頁，而後打開 Associated Domains ，以 applinks: 開頭添加上你的App支持的域名，例如：applinks:z.t4m.cn 、 applinks:*.ulml.mob.com

注意：這個域名權限列表最多添加20到30個。

配置好Associated Domains以後，就要在 AppDelegate.m 中實現 HandOff 的UIApplicationDelegate 方法以便你的App可以接收到universal link並進行適當的處理。

- (BOOL)application:(UIApplication *)application continueUserActivity:(NSUserActivity *)userActivity restorationHandler:(void (^)(NSArray<id<UIUserActivityRestoring>> * _Nullable))restorationHandler
{
    NSLog(@"title: %@", userActivity.title);
    // NSUserActivityTypeBrowsingWeb
    NSLog(@"activityType: %@", userActivity.activityType);
    // The webpage URL property always contains an HTTP or HTTPS URL, and you can use NSURLComponents APIs to manipulate the components of the URL.
    NSLog(@"webpageURL: %@", userActivity.webpageURL);
    // 根據webpageURL的路徑、參數等做出適當的處理
    // <your code here ...>
    return YES;
}

到此，iOS上深度連接的實現就完成了。總體來看，實現iOS上的深度連接涉及到先後端的操做和聯調會特別多，尤爲是HTTPS證書和錯誤處理訪問到網站那一塊，看似簡單，但真正一步一步作起來的時候，大大小小的問題仍是很多的，若是對於先後端不是特別熟悉的話可能仍是須要一些時間的。這裏我建議你們能夠選擇第三方深度連接服務，好比MobLink、魔窗、LinkedMe等等，相比之下，MobLink全球領先的移動端場景還原解決方案 以避免費、服務好和功能而出名，較爲推薦。

4、WWDC2019: What's New in Universal Links

時隔多年，在剛結束沒有多久的 WWDC 2019 中，又再一次提到了Universal Links，雖然 整個session不長，也就不到20分鐘的時間，但足以體驗蘋果一直在作這件事兒。

首先，劃一下重點：Universal Links 以前只支持在 iOS 和 tvOS 上，如今全面登錄到 macOS 上了，不管你是用 UIKit 仍是 AppKit 開發的 Mac App 均可以使用Universal Links。

這一次 WWDC2019 Universal Links 主要的變化有兩點：

• apple-app-site-association 文件支持精細化地址匹配寫法
• 全面支持macOS系統

OverView 總覽

Universal Link 的基本運做機制

• 經過在 XCode 的 App 配置中配置了相關信息以及安全域名指定
• 經過在 Https only 的安全域名上部署一個配置 apple-app-site-association 文件
• apple-app-site-association 文件中配置上豐富的 website 與 app 的連接信息
• 在 website 與 app 之間創建起了安全有效的握手機制
• 實現 website 的 url 與 app 的直接聯動
• 相對於自定義的 schemes 來講 Universal Link 能帶給你更安全更流暢的體驗

補充：schemes 上最使人詬病的就是 app 劫持，不少 app 會冒充註冊知名大廠的 app scheme 從而攔截調常規的大廠 scheme 喚起，這一點在 Universal Link 就能很好的避免。

apple-app-site-association 文件精細化匹配

上圖是 MobLink 這款提供深度連接功能的SDK的apple-app-site-association文件老的寫法示例。

這是新的寫法，支持了更多更強的配置能力。

• apps 這個字段只有在 iOS 上有用，tvOS/macOS 這個字段能夠忽略
• details 字段結構大幅度變化
  • 之前是字典 appID 爲 Key，如今是數組，而且支持 appIDs 這樣的 key，能夠一套配置適配多個 appID，大幅度減小工做量
  • 新增 components 字段，能夠進一步約束 Universal Link 的生效條件
    • 能夠經過 / 來配置支持的 path 格式條件
    • 能夠經過 # 來配置支持的錨點條件
    • 能夠經過 ? 來配置支持的字段條件
    • exclude 是排除字段，符合這個條件的 Universal Link 不生效

Universal Links 網絡服務的配置建議

在部署網絡服務，配置 apple-app-site-association 文件的時候，蘋果建議還要遵循一下幾點 Tips

• 必須支持 https：

必須是正規證書，不能使用自定義證書。

• URL 使用 ASCII 編碼

由於在 URL 中會使用不少符號諸如 # ？% ，所以要使用 ASCII 編碼。

• 減小 apple-app-site-association 文件的大小

減小大小有助於在擁堵的網絡條件下，更順暢的生效 Universal Link。若是你的應用面向不通的國家，針對不一樣的國家有不一樣的配置文件，能夠經過國家標記符來分別配置，從而讓用戶只下載最精簡的 JSON 文件。

• apple-app-site-association 文件的下載和更新策略：

當 App 安裝到設備的時候，會從配置域名上下載這個JSON文件到本地，從而根據配置生效相關的功能。而且設備上下載的這個JSON文件會不按期的更新（親測過，App 發佈版本更新的時候也會準確觸發JSON文件的更新）。

• 使用 Smart Banner

網頁中的 Smart Banner 與 Universal Links 一塊兒配合使用，能夠有效的引導未安裝 app 的用戶前往下載，已安裝 app 的用戶就能夠順暢的進行跳轉

Universal Links 支持 macOS

在 XCode 中配置 Universal Links

開發 Universal Links的代碼，支持macOS：

// Configuring Your App
func application(_ application: Application, continue userActivity: NSUserActivity,
restorationHandler: @escaping ([ UserActivityRestoring]?) -> Void) -> Bool { 
    guard userActivity.activityType == NSUserActivityTypeBrowsingWeb,
    let url = userActivity.webpageURL,
    let components = URLComponents(url: url, resolvingAgainstBaseURL: true) else {
    return false
    }
    for queryItem in components.queryItems ?? [] {
     …
    return true
}
複製代碼

在支持 macOS 的狀況下，appDelegate 的 Universal Link 的處理也是這個 delegate，區別只是 UIApplication 變爲 NSApplication。

因爲這個 delegate 會由不少其餘的快捷方式觸發，不只僅由 Universal Link 觸發，因此經過 NSUserActivityTypeBrowsingWeb 來判斷來源，剩下的就是標準的 url 處理了。

macOS 下的 Universal Links 工做機制與 iOS 下存在必定的差別

• 默認打開網頁，會提示用戶是否須要打開app
• 遠程登陸下沒法生效
• Appstore 簽名 macApp 能夠在下載 App 後馬上生效
• 開發者簽名的 macApp 必須在用戶運行過一次後生效

在 mac app 中打開一個 Universal Link

// UIApplication
UIApplication.shared.open(url, options: [ .universalLinksOnly: true ]) {
 …
}

// NSWorkspace
let configuration = NSWorkspace.OpenConfiguration()
configuration.requiresUniversalLinks = true
NSWorkspace.shared.open(url, configuration: configuration) {
 …
}