iOS Deep Linkin 和 Deferred Deep Linking

henry_shr發表於2017-10-15
iOS

1. 什麼是deep linkin 和 deferred Deep Linking

a. deep linkin:在移動開發領域，deep linking 則是指 mobile app 在 handle 特定 URI 的時候可以直接跳轉到對應的內容頁或觸發特定邏輯，而不僅僅是啟動 app
b. deferred Deep Linking: deferred deep linking 是指使用者開啟一個 web page 的時候並沒有安裝對應的 app，希望使用者在安裝 app 以後可以 deep link 到對應內容

2. 如何實現deep linkin

1）URL Scheme 的方式，在iOS9 以前很長一段時間都是採用這種方式，通常URL schema 格式如:schema://new/list?key1=value1&key2=value2 這種方式，然後都有自己一套解析schema的路由router,路由也是元件化的重要組成部分，網上有很多相關資料，就不詳細介紹了。
這種方式需要在appdelegate 中實現，然後裡面根據做schema 解析，根據URL

- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation { }

2）Universal Links 的方式，蘋果在iOS9 後引入這種方式，帶來了幾大好處

  • Custom URL scheme 因為是自定義的協議，所以在沒有安裝 app 的情況下是無法直接開啟的，而 universal links 本身是一個 HTTP/HTTPS 連結，所以有更好的相容性
  • Universal links 支援從其他 app 的 MKWebView 或 UIWebView 中跳轉到目標 app
  • Universal links 本身可以被搜尋引擎索引。
  • 微信不再能封禁跳轉了，終於可以實現平滑跳轉

尤其是最後一條，實現Universal links 跳轉，已經成為各大公司運營推廣，帶回APP流程的一個重要手段

那如何才能實現Universal links呢，首先滿足實現Universal links 需要以下幾個必要條件：

  • xcode 7 以上，需要做一些配置資訊
  • iOS 9 以上的系統
  • 註冊通過的ssl 協議（https）
  • 分享的地址域名和需要條狀的Universal links域名不能相同，需要跨域

具體的實現不詳細描述，是一個需要前端和客戶端一起配合的一個專案
前端的工作主要有以下幾個點

  • 滿足ssl 協議的域名

  • 上傳蘋果驗證通過的apple-app-site-association檔案到域名根目錄下

  • 寫出相容性很強的js,判斷ios9 以上和以下分別怎麼處理，微信平臺和非微信平臺，判斷已經安裝和未安裝等情況

客戶端需要做的工作

  • Xcode中開啟Associated Domains服務

  • 要在蘋果開發者網站中開啟App的Associated Domains功能

  • appdelegate 中實現Universal links 的代理

  • 解析Universal links 連結實現頁面的跳轉

具體細節的實現參考連結：www.cocoachina.com/ios/2015090…

h5 如何做各種情況相容（暫時未考慮android 情況）

首先有以下幾種情況

已經安裝

A. 微信內

1. iOS 9 以上
    universal link開啟
    universal link關閉 ：不存在關閉這一行為，只是蘋果給的一個記錄最後一次的開啟方式，但是這個是在safari 瀏覽器生效
2. iOS 9 以下
    方案一：schema 技術，由於微信遮蔽，加浮層引導 右上角safari 開啟
    方案二：跳應用寶，應用寶可以轉跳複製程式碼

B. 微信外:

     1. iOS 9 以下： schema 方式開啟
     2. iOS 9 以上：universal link ，schema 均可，universal link 更好複製程式碼
未安裝

未安裝跳轉下載頁面

如何判斷是否安裝呢，尤其是在微信平臺，目前比較通用的做法是先正常連結universal link 或者schema 地址，然後採用一個timeout做一個延時跳轉到下載中間頁面地址
程式碼大概如下：

$('a').click(function() {
    location.href = '自定義 URL scheme 或者 universal link 地址';
    setTimeout(function() {
        location.href = '下載中間頁面頁';
    }, 250);
    setTimeout(function() {
        location.reload();
    }, 1000);
}複製程式碼

具體h5 實現細節參考 或者 搜尋引擎 搜尋 h5 判斷是否安裝
segmentfault.com/a/119000000…

3. 如何實現 deferred Deep Linking

一開始也解釋了什麼是deferred deep linking ：是指使用者開啟一個 web page 的時候並沒有安裝對應的 app，希望使用者在安裝 app 以後可以 deep link 到對應內容。

實現思路大家都可能都猜的到：

就是h5 需要上報裝置的一些資訊到服務端，使用者下載後，第一次啟動也上裝置資訊，去服務端匹配是否應該跳轉和跳轉地址

這裡有三個需要解決的問題：

  • 判斷是否已經安裝了 app，如果已經安裝了直接 deep link 到 app，否則跳轉 App Store。

  • 使用者匹配（user matching），如何把一個 install 對應到某一次 web page view 或者某一次 click。

  • Deep linking

第一個問題其實上面也講到一些，就是判斷使用者是否已經安裝了app

window.location = 'schema url 或者 universal link 地址';  
setTimeout(function() {  
    window.location = '下載中間頁面或者APPStore 地址'
}, 250);複製程式碼

在 iOS 9.2 以前，Safari 裡是否用 app 開啟 scheme URL 會有一個彈框 所以如果使用者同意用 app 開啟連結以後就不會跳轉 App Store，反之，使用者選擇取消或者並沒有安裝 app 的時候，會跳轉 App Store。iOS 9.2 Apple 不再彈 block JS，所以無論如何都會跳轉 App Store。加上微信scheme URL 不生效，因此現在會推薦使用 universal links 來實現這樣的邏輯

第二個問題就實現這兒的核心，如何標識一個使用者，其實很多廣告追蹤也有這樣的場景

方案流程

  • 使用者在wap網頁上產生了行為，產生了使用者個人資料

  • wap網頁收集了一種能夠唯一標識裝置的資訊，並且傳送給了伺服器

  • app安裝完畢後第一次執行，也去通過app嘗試收集唯一標識裝置的資訊，並且發給伺服器

  • 伺服器經過對比，發現app的唯一標識與wap網頁發上來的唯一標識能夠匹配

  • 伺服器判斷，是同一個人操作，於是下發使用者個人資料
    縱觀整個流程發現，一切的核心，一切的關鍵，就是那個唯一標示

不難看出唯一標識是這裡面的重點，那麼問題來了，如何選取唯一標識，需要考慮，h5 具備哪些能力

那麼唯一標識需要滿足哪些條件呢

  1. 選擇當做唯一標識的內容，必須能讓app獲取的到
  2. 選擇當做唯一標識的內容，必須也能讓h5獲取的到
  3. 選擇當做唯一標識的內容，還必須有能力區分出不同的裝置，如果選的唯一標識好幾個裝置取出來的都一樣，那麼就亂套了

那麼我們看看遵循這幾個條件，我們能選擇啥？

常用的UDID,MAC,IDFA地址啥的這玩意app是能取到了，但是h5拿不到啊

那麼我們反過來推，h5 能取到什麼

  1. 裝置螢幕尺寸（iOS裝置如此的統一，一共就那麼幾個螢幕尺寸，重複的還不一堆一堆的）
  2. 裝置作業系統（iOS系統碎片化如此的低，大部分幾乎都升到較高階的系統版本，重複的依然一堆一堆）
  3. 裝置IP（IP這玩意會變啊，離開WIFI進入3G，經常變，並且IP這玩意在同一WIFI下也重複的一堆一堆的啊）
  4. 訪問時間（時間這玩意更沒譜了，你們的使用者量越大，某一個確定的時間段內，發生第一次安裝，重複的就越多）

上面的資料最大的特點就是，有一定的描述裝置體徵的資訊，但是如果只靠這一個描述資訊，那結果就是重複的太多太多，根本沒法確定一個唯一性。
但是，如果我們把這麼些描述資訊做成一個合集，同一時間內滿足所有的條件，那麼這個裝置重複的概率一下就縮減了太多太多。

比如：

裝置之前訪問過分享的連結，服務區手機到了上面的基本資訊，裝置通過引導安裝了app,安裝完畢第一次開啟的時候，app 也上報這些基本資訊，伺服器找到同樣的螢幕尺寸，同樣的作業系統版本，同樣的IP地址，訪問時間相差不超過8min（暫定）的裝置，在如此多得限定條件下，我們近乎可以認定為，是具有唯一性的裝置，是同一個人
可以看到這裡面眾多的資訊一起去過濾，比較強的過濾條件就是IP，但因為IP存在頻繁變化，所以追加了時間條件，IP也可能因為WIFI路由器的原因導致，IP也存在重複和誤傷，這時候，又輔助了簡單的裝置資訊進行二次過濾。
這樣我們就找到了一個並不完美的唯一標識

方案的弊端

因為他是不完美的唯一標識，所以就存在著

  1. 有時間段限制 如上：8 分鐘之內h5瀏覽引導，完成app下載，啟動操作的
  2. 誤傷，存在同一個IP出口，同一時間段，同樣的裝置特徵的情況下，有2個2個人以上的人做同樣的事情

但是在iOS9 以上，還有一種精準的解決方案就是iOS9 的SFSafariViewController

原理就是：
SFSafariViewController 可以和 safari 共享沙盒，可以共享cookie，cookie 的sessionid 可以唯一標識

但是你也可以看到同樣有非常大的弊端
只能在safari下開啟的才生效，在微信，QQ 這種不生效

這就造成了非常的侷限性，目前國內大部分分享都是通過微信的

參考資料
segmentfault.com/a/119000000…
www.cocoachina.com/ios/2016010…

相關文章