背景
對於APP來說，迴流分享頁是最好的最便宜的也是最病毒式的拉新方式。讓新用戶去下載APP是重要的。對老用戶來說，可以直接調起APP也是提升用戶體驗和讓用戶有侵入式體驗的重要手段。所以我們一起來看看有哪些方式可以喚起APP的
概念敘述
調起APP在不同平臺用不同的方式，主要就分3個 * URI Scheme * universal Link * Android App Links 現在還是有很多第三方來協助你處理這個事情，通過接入他們的SDK和客戶端代碼來處理，但是萬變不離其宗，所有的第三方也離不開這3種方式。
- URI Scheme:
- URI Scheme 是iOS，Android平臺都支持，只需要原生APP開發時註冊 scheme ， 用戶點擊到此類鏈接時，會自動喚醒APP，藉助於 URL Router 機制，則還可以跳轉至指定頁面。
- <scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]
- ：是scheme的名稱，代表着協議名稱。
- ：它包含 authority 和 path。
- ：可選項目，隔開或&隔開的鍵值對=
- ：可選項目包，其它額外的標識信息 例如： git://github.com/user/project-name.git ftp://user1:1234@地址 musically://musical?id=xxxx&key=xxxx
- universal Link:
- iOS9 後推出的一項功能，通用鏈接，對於前端即訪問一個https的url,如果這個url帶有你提交給開發平臺的配置文件中匹配規則的內容，iOS系統會去嘗試打開你的app，如果打不開，系統就會在瀏覽器中轉向你要訪問的鏈接。
- universal Link 工作方式如下：
- 訪問web link
- iOS訪問 https://xxxxxxx/apple-app-site-association 並解析，獲取文件中的信息(App的Team ID和Bundle ID)
- 通過Bundle ID 檢查本地是否存在對應app，和檢查PATH信息等，如果有app打開app，如果沒有則跳轉對應web link(可通過代碼實現跳去app Stroe)
- Android App Links:
- 在2015年的Google I/O大會上，Android M宣佈了一個新特性：App Links讓用戶在點擊一個普通web鏈接的時候可以打開指定APP的指定頁面，前提是這個APP已經安裝並且經過了驗證，否則會顯示一個打開確認選項的彈出框，只支持Android M以上系統。
- 簡單的說就是建立APP和某個鏈接的關聯，避免系統在處理該類型鏈接時彈出選擇框。彈框最常見的就是瀏覽器打開時的選擇框。彈出選擇框是應用註冊了相應scheme，applinks的作用是避免在打開自己域名的鏈接時彈出選擇（前提是註冊了相應scheme），可以實現直接打開自己關聯的app。
對比/優劣
- URI Scheme: 根據圖片可以看到URI Scheme的兼容性是最高，在使用的過程中，會發現有很多限制:
- 當要被喚起的app沒有安裝時，這個鏈接就會出錯。在國內非常雜亂的瀏覽器中，會出錯的現象會很多種類型。
- 當註冊有多個scheme相同的時候，目前沒有辦法區分。
- 不支持從其他app中的UIWebView中跳轉到目標app 也就因爲會有這些原因，apple和android都出現了自己第二套解決方案。
- universal Link 從鏈接上看來，是一個web link，所以也就解決了當沒有app時，跳轉也不會出現報錯，所以相對Scheme優勢就提現出來了.
- 當已經安裝app，不需要加載任何web頁面，app就會立即啓動；app沒有安裝，就會跳去對應的web link。
- universal Link 是從服務器上查詢是哪個app需要被打開，所以不會存在衝突問題
- universal Link 支持從其他app中的UIWebView中跳轉到目標app
- 隱私性，提供universal Link給別的app進行app間的交流，然而對方並不能夠用這個方法去檢測你的app是否被安裝。 當然universal Link也不是十全十美的,缺陷也是存在的:
- 會記住用戶的選擇：在用戶點擊了Universal link之後，iOS會去檢測用戶最近一次是選擇了直接打開app還是打開網站。一旦用戶點擊了這個選項，他就會通過safiri打開你的網站。並且在之後的操作中，默認一直延續這個選擇，除非用戶從你的webpage上通過點擊Smart App Banner上的OPEN按鈕來打開。
- app link 和 universal Link 差異不大。也是爲了更好的提供調起app出現的google的方案。優點與 universal Link 差不多，缺點主要如下：
- 國內的支持相對較差，在有的瀏覽器或者手機ROM中並不能鏈接至APP，而是在瀏覽器中打開了對應的鏈接。
- 在詢問是否用APP打開對應的鏈接時，如果選擇了“取消”並且“記住選擇”被勾上，那麼下次你再次想鏈接至APP時就不會有任何反應
無論哪一種方式目前都沒有解決幾個問題： * 如果設備上沒有安裝這個app的時候，安裝完畢後，無法保留住此時用戶停留的上下文。 * 因爲web沒有辦法監聽到APP是否安裝，所以都需要通過一些手段來兼容調起app或者是去下載頁
使用 & 需要注意的內容
- URI Scheme：
- 使用: 這種方式是當期使用最廣泛，也是最簡單的，但是需要手機，APP支持 URI Scheme 。
- 需要注意的內容 & 遇到的問題： 其實使用URI Scheme 部分前端沒有太多可以排查的問題，會遇到的問題主要是兩個部分。1. 在android的兼容性處理（國內的瀏覽器無力吐槽ing），2. 當沒有安裝app的情況，URI Scheme 會有各種報錯，也需要處理…
<!-- 喚醒APP並跳轉至指定的path頁面 -->
<a href="<scheme>://<path>?<params>=<value>">打開APP</a>
<!-- JS設置iframe src跳轉至指定的path頁面 -->
//創建一個隱藏的iframe
var ifr = document.createElement('iframe');
ifr.src = '<scheme>://<path>?<params>=<value>';
ifr.style.display = 'none';
document.body.appendChild(ifr);
//記錄喚醒時間
var openTime = +new Date();
window.setTimeout(function(){
document.body.removeChild(ifr);
//如果setTimeout 回調超過2500ms，則彈出下載
if( (+new Date()) - openTime > 2500 ){
window.location = '指定的下載頁面';
}
},2000)
- universal Link & app Links
- 使用：對於有app的用戶，只是打開一個連接，但是需要注意的是需要考慮到沒有APP的用戶。(個人的解決方案：針對域名來判斷，當域名爲特定的universal Link 的域名，則跳轉去下載頁面）
- 需要注意的內容 & 遇到的問題：
- apple-app-site-association 和 assetlinks.json 的配置
- 需要保證使用的鏈接跨域(universal Link)
- 直接將universal Link 貼入瀏覽器的url中不會生效
- window.onload 或者用戶沒有任何事件觸發的情況下，universal Link也不會生效
兩大平臺的特殊處理(facebook & twitter)
facebook 和 twitter 作爲國外的兩大信息聚合平臺，對於在他們app中調起app也有自己的一套方式。 根據要求通過添加META頭來處理打開APP facebook:
<meta property="fb:app_id" content="xxxxxx" />
<meta property="og:type" content="xxxx"/>
<meta property="og:title" content="xxx" />
<meta property="al:ios:url" content="{{ uri scheme }}" />
<meta property="al:android:url" content="{{ uri scheme }}" />
<meta property="al:ios:app_store_id" content="{{app_store_id}}" />
<meta property="al:ios:app_name" content="{{xxx}}" />
<meta property="al:android:app_name" content="{{xxx}}" />
<meta property="al:android:package" content="{{android:package}}" />
twitter:
<meta name="twitter:card" content="app" />
<meta name="twitter:site" content="xxxxx" />
<meta name="twitter:title" content="xxxxx" />
<meta name="twitter:description" content="xxxxxxx" />
<meta name="twitter:image" content="xxxx" />
<meta name="twitter:app:name:iphone" content="xxx">
<meta name="twitter:app:id:iphone" content="xxx">
<meta name="twitter:app:url:iphone" content="{{Scheme}}">
<meta name="twitter:app:name:ipad" content="xxx">
<meta name="twitter:app:id:ipad" content="xxx">
<meta name="twitter:app:url:ipad" content="{{Scheme}}">
<meta name="twitter:app:name:googleplay" content="xxx">
<meta name="twitter:app:id:googleplay" content="xxx">
<meta name="twitter:app:url:googleplay" content="{{Scheme}}">
使用 checkList(前端)
-
scheme
- iOS 和 android 是否已經支持 此scheme
- js處理兼容代碼
-
universal Link (apple-app-site-association 官方文檔)
- HTTPS的域名
- iOS9 以上
- universal Link 是否跨域
- universal Link的落地頁是否是下載頁面
- apple-app-site-association 配置在 host的根目錄和.well-known下
- apple-app-site-association會在第一次打開app或者更新app時候會去拉去,所以確認是否更新了apple-app-site-association後沒有更新過app
- 檢查apple-app-site-association paths 大小寫敏感 支持通配符
- 該設備的用戶選擇了直接打開app還是打開網站，如果選擇打開網站，需要通過smart banner 重新啓用
- 跳轉處理是否是在用戶事件中觸發，而不是進入頁面後直接觸發
-
app links (android app links官方文檔)
- HTTPS的域名
- 跳轉後的落地頁是否是下載頁面
- assetlinks.json 配置在 host的.well-known下
- 官方生成/檢測: android app links檢測
-
facebook (facebook app link官方文檔)
- 將需要的meta頭信息填充完畢
- 檢測鏈接 分享調試器 - Facebook for Developers , 確認分享鏈接中獲取到了所需要的meta頭
- 分享過的鏈接會有緩存，在檢測中清楚緩存
- 如果web和wap鏈接一致，確認在web中也添加了相同的meta頭，facebook會默認從web中獲取
-
twitter (Twitter app card官方文檔)
- 將需要的meta頭信息填充完畢
- 檢測鏈接 Twitter app card 檢測
- 如果web和wap鏈接一致，確認在web中也添加了相同的meta頭，facebook會默認從web中獲取
鏈接
- webview如何屏蔽universal Link
- apple-app-site-association 官方文檔
- apple-app-site-association 檢測
- android app links官方文檔
- android app links檢測
- facebook app link官方文檔
- 分享調試器 - Facebook for Developers
- Twitter app card官方文檔
- Twitter app card 檢測