如何自動開啟你的 App?

語言: CN / TW / HK

相信大家在刷 某博 / 某書 / 某音 的時候,最能體會什麼叫做 條條大路通 tao bao。經常是你開啟一個 App,不小心點了下螢幕,就又打開了另一個 App 了。

那麼這種自動開啟一個 App 到底是怎麼實現的呢?

URL Scheme

首先是最原始的方式 URL Scheme。

URL Scheme 是一種特殊的 URL,用於定位到某個應用以及應用的某個功能。

它的格式一般是: [scheme:][//authority][path][?query]

scheme 代表要開啟的應用,每個上架應用商店的 App 所註冊的 scheme 都是唯一的;後面的引數代表應用下的某個功能及其引數。

在 IOS 上配置 URL Scheme

在 XCode 裡可以輕鬆配置

image.png

在 Android 上配置 URL Scheme

Android 的配置也很簡單,在 AndroidManifest.xml 檔案下新增以下配置即可

image.png

通過訪問連結自動開啟 App

配置完成後,只要訪問 URL Scheme 連結,系統便會自動開啟對應 scheme 的 App。

因此,我們可以實現一個簡單的 H5 頁面來承載這個跳轉邏輯,然後在頁面中通過呼叫 location.href=schemeUrl 或者 <a href='schemeUrl' /> 等方式來觸發訪問連結,從而自動開啟 App

優缺點分析

優點: 這個是最原始的方案,因此最大的優點就是相容性好

缺點: 1. 通過 scheme url 這種方式喚起 App,對於 H5 中間頁面是無法感知的,並不知道是否已經成功開啟 App 2. 部分瀏覽器有安全限制,自動跳轉會被攔截,必須使用者手動觸發跳轉(即 location.href 行不通,必須 a 標籤) 3. 一些 App 會限制可訪問的 scheme,你必須要在白名單內,否則也會被攔截跳轉 4. 通過 scheme url 喚起 App 時,瀏覽器會提示你是否確定要開啟該 App,會影響使用者體驗

DeepLink

通過上述缺點我們可以看出,傳統的 URL Scheme 在使用者體驗上是存在一定缺陷的。

因此,DeepLink 誕生了。

DeepLink 的宗旨就是通過傳統的 HTT P連結就可以喚醒app,而如果使用者沒有安裝APP,則會跳轉到該連結對應的頁面。

IOS Universal Link

在 IOS 上一般稱之為 Universal Link。

【配置你的 Universal Link 域名】

首先要去 Apple 的開發者平臺上配置你的 domains,假設是: mysite.com

image.png

【配置 apple-app-site-association 檔案】

在該域名根目錄下建立一個 .well-known 路徑,並在該路徑下放置 apple-app-site-association 檔案。

檔案內容包含 appID 以及 path,path如果配置 /app 則表示訪問該域名下的 /app 路徑均能喚起App

該檔案內容大致如下:

js { "applinks": { "apps": [], "details": [ { "appID": "xxx", // 你的應用的 appID "paths": [ "/app/*"] } ] } }

【系統獲取配置檔案】

上面兩步配置成功後,當用戶 首次安裝App 或者後續每次 覆蓋安裝App 時,系統都會主動去拉取域名下的配置檔案。

即系統會主動去拉取 https://mysite.com/.well-known/apple-app-site-association 這個檔案

然後根據返回的 appID 以及 path 判斷訪問哪些路徑是需要喚起哪個App

【自動喚起 App】

當系統成功獲取配置檔案後,只要使用者訪問 https://mysite.com/app/xxx 連結,系統便會自動喚起你的 App。

同時,客戶端還可以進行一些自定義邏輯處理:

客戶端會接收到 NSUserActivity 物件,其 actionType 為 NSUserActivityTypeBrowsingWeb,因此客戶端可以在接收到該物件後做一些跳轉邏輯處理。

image.png

Android DeepLink

與 IOS Universal Link 原理相似,Android系統也能夠直接通過網站地址開啟應用程式對應的內容頁面,而不需要使用者選擇使用哪個應用來處理網站地址

【配置 AndroidManifest.xml】 在 AndroidManifest 配置檔案中新增對應域名的 intent-filter:

scheme 為 https / http;

host 則是你的域名,假設是: mysite.com

image.png

【生成 assetlinks.json 檔案】

首先要去 Google https://developers.google.com/digital-asset-links/tools/generator 生成你的 assetlinks json 檔案。

image.png

【配置 assetlinks.json 檔案】

生成檔案後,同樣的需要在該域名根目錄下建立一個 .well-known 路徑,並在該路徑下放置 assetlinks.json 配置檔案,檔案內容包含應用的package name 和對應簽名的sha雜湊

【系統獲取配置檔案】

配置成功後,當用戶 首次安裝App 或者後續每次 覆蓋安裝App 時,系統會進行以下校驗: 1. 如果 intent-filter 的 autoVerify 設定為 true,那麼系統會驗證其 - Action 是否為 android.intent.action.VIEW - Category 是否為android.intent.category.BROWSABLE 和 android.intent.category.DEFAULT - Data scheme 是否為 http 或 https 2. 如果上述條件都滿足,那麼系統將會拉取該域名下的 json 配置檔案,同時將 App 設定為該域名連結的預設處理App

【自動喚起 App】

當系統成功獲取配置檔案後,只要使用者訪問 https://mysite.com/app/xxx 連結,系統便會自動喚起你的 App。

優缺點分析

【優點】 1. 使用者體驗好:可以直接開啟 App,沒有彈窗提示 2. 喚起App失敗則會跳轉連結對應的頁面

【缺點】 1. iOS 9 以後才支援 Universal Link, 2. Android 6.0 以後才支援 DeepLink 3. DeepLink 需要依賴遠端配置檔案,無法保證每次都能成功拉取到配置檔案

推薦方案: DeepLink + H5 兜底

基於前面兩種方案的優缺點,我推薦的解決方案是配置 DeepLink,同時再加上一個 H5 頁面作為兜底。

首先按照前面 DeepLink 的教程先配置好 DeepLink,其中訪問路徑配置為 https://mysite.com/app

接著,我們就可以在 https://mysite.com/app 路徑下做文章了。在該路徑下放置一個 H5 頁面,內容可以是引導使用者開啟你的 App。

當用戶訪問 DeepLink 沒有自動開啟你的 App 時,此時使用者會進入瀏覽器,並訪問 https://mysite.com/app 這個 H5 頁面。

在 H5 頁面中,你可以通過瀏覽器 ua 獲取當前的系統以及版本: 1. 如果是 Android 6.0 以下,那麼可以嘗試用 URL Scheme 去喚起 App 2. 如果是 IOS / Android 6.0 及以上,那麼此時可以判斷使用者未安裝 App。這種情況下可以做些額外的邏輯,比如重定向到應用商店引導使用者去下載之類的