寫在前面
上一篇已經介紹了iOS系統層面提供的應用之間跳轉的技術和實施方案，本篇會帶大家更深入的瞭解UniveralLinks技術，探究其繫結運作原理，使用時的技巧。
運作原理
對於UniversalLinks的生效和繫結原理，官方文件並未說明，通過親自嘗試整理出了其繫結原理，這有助於對於觸發時機把握：
-
App從iOS9開始，安裝App成功後，系統會檢查App是否對UniversalLinks技術做了支援，如果檢查到有做支援，則從App的associated-domains配置裡讀取繫結域名。
-
訪問該域名下預設的JSON檔案
apple-app-site-association，讀取JSON檔案中的app繫結資訊，與當前App內的資訊做對比。 -
如果匹配成功，在系統本地內部就做完了雙向繫結。
也就是隻要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具備
- 繼續使用者m站行為
- 跳轉AppStore行為
- 重定向到中間頁行為
- 連結歸因儲存匹配能力