寫在前面

上一篇已經(jīng)介紹了iOS系統(tǒng)層面提供的應(yīng)用之間跳轉(zhuǎn)的技術(shù)和實施方案，本篇會帶大家更深入的了解UniveralLinks技術(shù)术吝，探究其綁定運作原理菩鲜，使用時的技巧。

運作原理

對于UniversalLinks的生效和綁定原理耗式，官方文檔并未說明，通過親自嘗試整理出了其綁定原理趁猴，這有助于對于觸發(fā)時機把握：

1. App從iOS9開始刊咳，安裝App成功后，系統(tǒng)會檢查App是否對UniversalLinks技術(shù)做了支持儡司，如果檢查到有做支持娱挨，則從App的associated-domains配置里讀取綁定域名。

2. 訪問該域名下預設(shè)的JSON文件apple-app-site-association枫慷，讀取JSON文件中的app綁定信息让蕾，與當前App內(nèi)的信息做對比浪规。

3. 如果匹配成功，在系統(tǒng)本地內(nèi)部就做完了雙向綁定探孝。

也就是只要App安裝完成笋婿，就可以即刻觸發(fā)UniversalLinks打開App啦！不需要像推送那樣顿颅，需要打開一次缸濒。

巧用UniveralLinks判斷App是否安裝

上一篇文章也提到了，目前所有包括UniversalLinks技術(shù)都無法直接對App的安裝做判斷粱腻。

但我要說：非也庇配！UniversalLinks提供的一項特性可以讓我們反向推斷App是否安裝，而且準確率相當高绍些，不像scheme跳轉(zhuǎn)那樣捞慌，只能做延時。

UniversalLinks在觸發(fā)時柬批，也就是鏈接被點擊時啸澡，系統(tǒng)會與本地已經(jīng)建立雙向綁定的數(shù)據(jù)進行匹配，匹配到的話氮帐，這個網(wǎng)絡(luò)請求就會在系統(tǒng)層面被攔截嗅虏，系統(tǒng)就會轉(zhuǎn)而打開綁定的App，并把完整URL傳給App的openURL的Delegate方法來處理上沐。反之皮服，如果App沒有安裝，那么點擊鏈接時系統(tǒng)無法匹配到信息参咙，則就將請求放行龄广，讓服務(wù)端接收到這個請求來處理。

看到這里已經(jīng)很明了了吧昂勒，用戶只要點擊了耸三，服務(wù)端可以通過是否接收到請求來判斷App是否已安裝踏烙。

當然這里也會不準技即，但概率比較小溺职，原因如果用戶是長按打開沉御，或者打開App后點擊了右上角的系統(tǒng)的返回按鈕后渺鹦，系統(tǒng)會下次觸發(fā)UniversalLinks的時候就不會攔截請求了约巷，導致接收到請求的設(shè)備其實已經(jīng)App枝冀，而我們無法知道痊夭。要想重新讓系統(tǒng)攔截刁岸，用戶需要點擊的時候長按link，并且選擇通過App打開她我，之后才又會被攔截虹曙。

但已經(jīng)比scheme跳轉(zhuǎn)設(shè)置一個timeout要來的靠譜的多了迫横。

巧用UniveralLinks拉新引舊

UniversalLinks作為一個平滑使用體驗的工具類技術(shù)來說，本身不具備拉新客戶的功能：比如新用戶如果從站外點擊UniversalLinks酝碳，那么用戶沒有裝App的話矾踱，只是會訪問m站而已，無它疏哗；引導老用戶從H5遷移到App的能力也比較弱呛讲，一直使用m站的用戶，只有在頁面頂部看到有一個入口返奉，點擊才能打開App贝搁。原因是用戶如果直接輸入了m站的地址，在站內(nèi)訪問芽偏，是不會觸發(fā)UniversalLinks的雷逆，只是會在綁定的H5頁面頂部有一個bar提醒用戶，點擊可以跳轉(zhuǎn)到App的相同功能污尉，可以說是很弱的关面。

讓我們看看怎么才能讓它具備強制拉新引舊能力：

• 首先要具備判斷是否安裝App的條件來區(qū)分新用戶還是老用戶，如果未安裝則為新十厢，已安裝則為舊等太。方法上面一節(jié)已經(jīng)介紹。
• 接下來服務(wù)端開發(fā)一個特殊的UniversalLinks蛮放，類似于https://app.alibaba.com/babalink缩抡，對app做好雙向綁定，注意包颁，這里域名與m站的m.alibaba.com域名必須不同瞻想。
• babalink接收兩種參數(shù)scheme=<scheme URL>&url=<http URL>，前者是應(yīng)用的scheme跳轉(zhuǎn)娩嚼，服務(wù)端拼接傳入打開App后需要打開頁面的scheme值蘑险，這個值是給已安裝App的情況用的；還有url中傳入需要跳轉(zhuǎn)的http頁面岳悟，通常是這個鏈接原本功能的m站鏈接佃迄。
• 這里舉個栗子，例如跳轉(zhuǎn)到產(chǎn)品詳情贵少，app的scheme是enalibaba://detail?id=123呵俏；而m站的頁面是https://m.alibaba.com/product?id=123；那么服務(wù)端在搜索結(jié)果頁每個結(jié)果的鏈接應(yīng)該是https://app.alibaba.com/babalink?scheme=enalibaba://detail?id=123&url=https://m.alibaba.com/product?id=123每個一級參數(shù)下的值都需要urlencode滔灶，這邊為了查看方便就不做了普碎。
• 這樣，用戶到了m站搜索結(jié)果頁的時候录平，每個搜索結(jié)果點擊的都是上面這種鏈接麻车，這種鏈接的域名與m站本身域名不同缀皱，在App已安裝的情況下就會觸發(fā)系統(tǒng)攔截請求，跳轉(zhuǎn)App动猬，App在打開時通過完整url中的scheme參數(shù)唆鸡，進行頁面跳轉(zhuǎn)即可完成引導老用戶的操作。
• 再看看新用戶枣察，新用戶因為沒有安裝App争占，所以這個link的請求會被發(fā)送到服務(wù)端，服務(wù)端根據(jù)情況控制將其引導到AppStore去安裝App序目，或者直接重定向到url參數(shù)的網(wǎng)頁臂痕。后者不用說還是延續(xù)用戶在m站的上的繼續(xù)瀏覽，前者打開了AppStore安裝了App后猿涨，用戶打開時首頁怎么辦握童？
• 這里這里可以利用歸因系統(tǒng)來做到從AppStore打開，還能繼續(xù)之前的操作叛赚，大致原理是服務(wù)端接收到link的請求澡绩，從請求中將這個請求轉(zhuǎn)化為用戶指紋存起來。
• 當用戶打開剛安裝好的App后俺附，App會在啟動的時候?qū)⒁恍┛勺鳛橹讣y的數(shù)據(jù)當做參數(shù)通過某個接口傳給服務(wù)端肥卡，服務(wù)端接收App的指紋數(shù)據(jù)參數(shù)后，通過算法匹配之前的用戶指紋事镣，匹配上后將用戶點擊的完整鏈接返回給客戶端步鉴，由客戶端來講鏈接解析，利用其scheme值進行跳轉(zhuǎn)璃哟，即可完美continue用戶的行為氛琢。

從其他App直接打開

• 從瀏覽器打開，只要是當前頁面的域名和用戶點擊按鈕的universallinks的域名是不同的随闪，就會觸發(fā)阳似。
• 在App中打開會有些麻煩，只有通過[[UIApplication sharedApplication] opentURL:@"https://app.alibaba.com/babalink?scheme=enalibaba://detail?id=123&url=https://m.alibaba.com/product?id=123"]這樣打開铐伴，才能跳轉(zhuǎn)到目標app撮奏，如果把鏈接塞到webview中則不會觸發(fā)，請求一定會到服務(wù)端盛杰。
• 所以挽荡，微信里直接通過聊天內(nèi)容發(fā)送鏈接跳轉(zhuǎn)是做不到的藐石。
• 這里可以讓鏈接檢測瀏覽器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頁面展示一個按鈕逗嫡，跳轉(zhuǎn)鏈接為https://app.alibaba.com/babalink?scheme=enalibaba://detail?id=123&url=https://m.alibaba.com/product?id=123青自。為什么？因為要跨域驱证，而且點擊行為在瀏覽器中進行是無法阻斷的延窜。
• 此時用戶點擊中間頁按鈕時，即便在其他App抹锄，不管是Facebook還是微信逆瑞，都可以觸發(fā)UniversalLink啦！

總結(jié)

總結(jié)一下伙单，巧用UniversalLink需要讓服務(wù)端的這個link具備

1. 繼續(xù)用戶m站行為
2. 跳轉(zhuǎn)AppStore行為
3. 重定向到中間頁行為
4. 鏈接歸因存儲匹配能力