URL SCHEME 喚端

前言

最近正好在整治外投拉端拉下載的事，借這個機會整理了一下 URL SCHEME 喚端的應用和原理。本文主要會從手機系統層面、APP容器層面去講解 URL SCHEME 的工做原理，好比在瀏覽器中輸入一個scheme後爲何可以打開一個APP，中間到底發生了什麼。本文主要涉及的知識點：

1. url scheme 的組成結構
2. app 如何註冊 scheme 信息
3. 對於一些不知名app，怎麼去獲取它的scheme信息
4. 如何經過scheme打開一個app
5. 爲何在有些平臺scheme會被攔截

誕生背景

通常來講，咱們的手機上會有不少的我的信息，好比聯繫人、銀行卡、我的照片等，若是任何一個安裝的應用均可以隨意獲取這些信息，就會形成嚴重的隱私泄漏。爲了解決這個問題，蘋果官方提出了一個叫作沙盒機制的方案，就是全部的應用只能去訪問系統聲明可訪問的資源，這樣就避免了用戶隱私的泄漏，可是這個機制在保護用戶隱私的同時，也阻斷了多個應用間的信息共享和消息通訊的能力。好比你想將一些事件添加到日曆裏，或者你想打開某個其餘的app，就變得很是困難，因而就有了url scheme 的解決方案。起初url scheme只針對一些內置應用開放，好比日曆、短信、郵件，後來才逐漸演變成了全部app均可以進行scheme註冊和訪問。

URL SCHEME 組成結構

一個完整的 url scheme 格式以下，它主要由四個部分組成，前面的 app 就是應用的一個 scheme 標識，好比淘寶的標識爲 taobao，微信的標識爲 weixin，後面的item就是打開應用後須要訪問的路由，再後面就是一系列參數的key值和value值，其中scheme部分將被系統識別並完成app打開行爲，後面的參數將由app自身完成解析和處理。

# {scheme}://{action}?{parameter}={value}&{parameter}={value}...
app://item?id=${itemId}&ut_sk=${utSk}&spm=widle.12011849.1.1
複製代碼

如何註冊一個 SCHEME

scheme 的註冊很是隨意，以IOS爲例，安裝包中有一個標準的配置文件，文件名叫 info.plist，在應用被安裝的時候會進行 scheme 的註冊，註冊的格式如截圖所示，它的關鍵字叫 CFBundleURLSchemes，下面是具體的value值，這個截圖是微信真實的配置文件，從這個文件裏面能夠看出，咱們能夠經過weixin://喚起微信客戶端，也能夠經過wechat://去喚起客戶端，甚至能夠經過QQ41C152CF去喚起客戶端，好比瀏覽器輸入QQ41C152CF://，就能夠打開微信客戶端。

如何查找其餘APP的scheme

對於一些比較知名的app，好比微信微博淘寶，能夠直接經過搜索就能夠找到，可是對於一些小衆的app，好比火山小視頻、積目盒子等，可能就很難搜索到了，這個時候就只能本身去拆包。下面是詳細的拆包教程：

1. 須要安裝一個應用助手，我使用的是愛思助手，在應用助手中搜索微信並下載

2. 找到下載的文件，通常是ipa文件，右鍵進行解壓

3. 解壓完成後咱們找到payload裏面的WeChat包，右鍵點擊顯示包內容

4. 找到info.plist 文件，在編輯器中打開，而後搜索 CFBundleURLSchemes 就能夠看到該APP全部的scheme信息了。

如何打開一個 APP

對於前端來講，喚端其實很容易，只須要經過 location.href 完成喚端跳轉便可，若是跳轉無反應，大機率是被攔截了

# 跳轉微信
location.href = 'weixin://'
複製代碼

更底層的，ios系統提供了一個openURL的系統方法，能夠用來打開一個連接，若是連接頭是某app的scheme，就會打開對應的app，ios示例代碼以下，若是你的喚端scheme在app的跳轉白名單內，就會經過openURL完成跳轉邏輯

# 建立一個url對象
NSURL *url = [NSURL URLWithString:@"weixin://"];

# 調用openURL打開url
[[UIApplication sharedApplication] openURL:url];
複製代碼

scheme被攔截

出於安全考慮或者出於商業目的，大部分app都會管控跳轉白名單，好比微信就禁止跳轉淘寶，若是你嘗試在頁面內訪問 taobao:// ，是不會有任何反應的。這裏的攔截邏輯一般出如今webview層面，當頁面發起一次地址請求時，會觸發webview的從新加載事件，而客戶端就能夠監聽這次事件並決定是否要執行，以ios爲例，經過shouldStartLoadWithRequest能夠完成監聽和攔截，若是返回YES，就表示容許本次加載，若是返回NO，則表示阻止本次加載，在這個方法中，客戶端能夠請求服務端校驗地址是否在白名單內並決定是否要繼續加載。

# YES表示容許加載url
# NO表示阻止加載url
- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType {
    if (特殊schema && 校驗成功) {
        # 打開第三方APP
        return NO;
    } else if (url校驗成功) {
        return YES;
    } else{
        return NO;
    }
}
複製代碼

完整鏈路

當H5發起scheme跳轉時，會觸發webview的從新加載事件，此事件會被客戶端劫持並進行白名單校驗，若是經過則調用系統方法openURL完成app跳轉（前提是該scheme被其餘app註冊過）

url scheme的缺陷

雖然url scheme是目前應用最廣的喚端方案，可是它仍然存在不少的侷限性。

1. 沒法判斷是否喚起成功，雖然app能夠經過canOpenURL來判斷可否打開，可是數量有限，且只適用於ios，大部分場景下仍然不能正常判斷。h5常見的應對方案是監聽頁面離開事件，好比2s內離開的認爲跳轉成功，2s後還停留在頁面的認爲跳轉失敗，能夠進行一些下載引導。
2. 用戶流失率高，由於不少的app或者瀏覽器都會有一個彈窗來二次確認是否須要打開某某app，在這一步會有很高的用戶流失率。
3. 很容易被商業屏蔽，由於url scheme很容易就能被攔截，出於商業緣由，不少平臺都會限制跳轉其餘app。

url scheme的不安全性

url scheme實際上是很是很是不安全的，由於蘋果官方沒有限制app定義的scheme名稱，也就是說，任何一個app，均可以註冊一個叫taobao的scheme，並且，蘋果的原則是後來先上，就是越晚註冊的app，優先被喚起，因此若是有惡意app進行scheme劫持，就會很容易出現釣魚現象，好比模仿一個淘寶商城而後騙取用戶資金。

那麼要怎麼樣去防禦呢？其實並無很好的防禦方式，由於scheme沒有版權一說，誰均可以進行註冊，可是能夠在用戶訪問app的時候給本身發送一條消息，好比打開淘寶後向taobao://發起調用，若是能正常接收到信息就表示沒有被劫持，若是沒有收到就表明scheme已經被惡意劫持了，此時能夠友善地提醒用戶卸載衝突的app。