iOS Deep Linkin 和 Deferred Deep Linking

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…