iOS App間相互跳轉漫談 part2

寫在前面

上一篇已經介紹了iOS系統層面提供的應用之間跳轉的技術和實施方案，本篇會帶你們更深刻的瞭解UniveralLinks技術，探究其綁定運做原理，使用時的技巧。

運做原理

對於UniversalLinks的生效和綁定原理，官方文檔並未說明，經過親自嘗試整理出了其綁定原理，這有助於對於觸發時機把握：

1. App從iOS9開始，安裝App成功後，系統會檢查App是否對UniversalLinks技術作了支持，若是檢查到有作支持，則從App的associated-domains配置裏讀取綁定域名。

2. 訪問該域名下預設的JSON文件apple-app-site-association，讀取JSON文件中的app綁定信息，與當前App內的信息作對比。

3. 若是匹配成功，在系統本地內部就作完了雙向綁定。

也就是隻要App安裝完成，就能夠即刻觸發UniversalLinks打開App啦！不須要像推送那樣，須要打開一次。

巧用UniveralLinks判斷App是否安裝

上一篇文章也提到了，目前全部包括UniversalLinks技術都沒法直接對App的安裝作判斷。

但我要說：非也！UniversalLinks提供的一項特性可讓咱們反向推斷App是否安裝，並且準確率至關高，不像scheme跳轉那樣，只能作延時。

UniversalLinks在觸發時，也就是連接被點擊時，系統會與本地已經創建雙向綁定的數據進行匹配，匹配到的話，這個網絡請求就會在系統層面被攔截，系統就會轉而打開綁定的App，並把完整URL傳給App的openURL的Delegate方法來處理。反之，若是App沒有安裝，那麼點擊連接時系統沒法匹配到信息，則就將請求放行，讓服務端接收到這個請求來處理。

看到這裏已經很明瞭了吧，用戶只要點擊了，服務端能夠經過是否接收到請求來判斷App是否已安裝。

固然這裏也會不許，但機率比較小，緣由若是用戶是長按打開，或者打開App後點擊了右上角的系統的返回按鈕後，系統會下次觸發UniversalLinks的時候就不會攔截請求了，致使接收到請求的設備其實已經App，而咱們沒法知道。要想從新讓系統攔截，用戶須要點擊的時候長按link，而且選擇經過App打開，以後才又會被攔截。

但已經比scheme跳轉設置一個timeout要來的靠譜的多了。

巧用UniveralLinks拉新引舊

UniversalLinks做爲一個平滑使用體驗的工具類技術來講，自己不具有拉新客戶的功能：好比新用戶若是從站外點擊UniversalLinks，那麼用戶沒有裝App的話，只是會訪問m站而已，無它；引導老用戶從H5遷移到App的能力也比較弱，一直使用m站的用戶，只有在頁面頂部看到有一個入口，點擊才能打開App。緣由是用戶若是直接輸入了m站的地址，在站內訪問，是不會觸發UniversalLinks的，只是會在綁定的H5頁面頂部有一個bar提醒用戶，點擊能夠跳轉到App的相同功能，能夠說是很弱的。

讓咱們看看怎麼才能讓它具有強制拉新引舊能力：

• 首先要具有判斷是否安裝App的條件來區分新用戶仍是老用戶，若是未安裝則爲新，已安裝則爲舊。方法上面一節已經介紹。
• 接下來服務端開發一個特殊的UniversalLinks，相似於https://app.alibaba.com/babalink，對app作好雙向綁定，注意，這裏域名與m站的m.alibaba.com域名必須不一樣。
• babalink接收兩種參數scheme=&url=，前者是應用的scheme跳轉，服務端拼接傳入打開App後須要打開頁面的scheme值，這個值是給已安裝App的狀況用的；還有url中傳入須要跳轉的http頁面，一般是這個連接本來功能的m站連接。
• 這裏舉個栗子，例如跳轉到產品詳情，app的scheme是enalibaba://detail?id=123；而m站的頁面是https://m.alibaba.com/product?id=123；那麼服務端在搜索結果頁每一個結果的連接應該是https://app.alibaba.com/babalink?scheme=enalibaba://detail?id=123&url=https://m.alibaba.com/product?id=123每一個一級參數下的值都須要urlencode，這邊爲了查看方便就不作了。
• 這樣，用戶到了m站搜索結果頁的時候，每一個搜索結果點擊的都是上面這種連接，這種連接的域名與m站自己域名不一樣，在App已安裝的狀況下就會觸發系統攔截請求，跳轉App，App在打開時經過完整url中的scheme參數，進行頁面跳轉便可完成引導老用戶的操做。
• 再看看新用戶，新用戶由於沒有安裝App，因此這個link的請求會被髮送到服務端，服務端根據狀況控制將其引導到AppStore去安裝App，或者直接重定向到url參數的網頁。後者不用說仍是延續用戶在m站的上的繼續瀏覽，前者打開了AppStore安裝了App後，用戶打開時首頁怎麼辦？
• 這裏這裏能夠利用歸因系統來作到從AppStore打開，還能繼續以前的操做，大體原理是服務端接收到link的請求，從請求中將這個請求轉化爲用戶指紋存起來。
• 當用戶打開剛安裝好的App後，App會在啓動的時候將一些可做爲指紋的數據當作參數經過某個接口傳給服務端，服務端接收App的指紋數據參數後，經過算法匹配以前的用戶指紋，匹配上後將用戶點擊的完整連接返回給客戶端，由客戶端來說連接解析，利用其scheme值進行跳轉，便可完美continue用戶的行爲。

從其餘App直接打開

• 從瀏覽器打開，只要是當前頁面的域名和用戶點擊按鈕的universallinks的域名是不一樣的，就會觸發。
• 在App中打開會有些麻煩，只有經過[[UIApplication sharedApplication] opentURL:@"https://app.alibaba.com/babalink?scheme=enalibaba://detail?id=123&url=https://m.alibaba.com/product?id=123"]這樣打開，才能跳轉到目標app，若是把連接塞到webview中則不會觸發，請求必定會到服務端。
• 因此，微信裏直接經過聊天內容發送連接跳轉是作不到的。
• 這裏可讓連接檢測瀏覽器UA來判斷連接是否爲從其餘App打開，若是是，則重定向到https://app-c.alibaba.com/babalink?scheme=enalibaba://detail?id=123&url=https://m.alibaba.com/product?id=123注意這個連接的域名不是app.alibaba.com，這個h5頁面展現一個按鈕，跳轉連接爲https://app.alibaba.com/babalink?scheme=enalibaba://detail?id=123&url=https://m.alibaba.com/product?id=123。爲何？由於要跨域，並且點擊行爲在瀏覽器中進行是沒法阻斷的。
• 此時用戶點擊中間頁按鈕時，即使在其餘App，不論是Facebook仍是微信，均可以觸發UniversalLink啦！

總結

總結一下，巧用UniversalLink須要讓服務端的這個link具有

1. 繼續用戶m站行爲
2. 跳轉AppStore行爲
3. 重定向到中間頁行爲
4. 連接歸因存儲匹配能力