H5如何實現喚起APP

前言

寫過hybrid的同學，想必都會遇到這樣的需求，如果使用者安裝了自己的APP，就開啟APP或跳轉到APP內某個頁面，如果沒安裝則引導使用者到對應頁面或應用商店下載。這裡就涉及到了H5與Native之間的互動，為什麼H5能夠喚起APP並且跳轉到對應的頁面？

就算你沒寫過想必也體驗過，最常見的就是抖音裡面的一些廣告，如果你點選了廣告，他判斷你手機裝了對應APP，那他就會去開啟那個APP，如果沒安裝，他會幫你跳轉到應用商店去下載，這個還算人性化一點的，有些直接後臺給你去下載，你完全無感知。

哈哈，是不是覺得這種技術很神奇，今天我們就一起來看看它是如何實現的～

如果這篇文章有幫助到你，❤️關注+點贊❤️鼓勵一下作者，文章公眾號首發，關注 前端南玖 第一時間獲取最新文章～

喚端體驗

實現之前我們先簡單體驗一下什麼是喚端

7.open_wx.gif

從上圖中，我們可以看到在瀏覽器中我們點選開啟知乎，系統會提示我們是否在知乎中開啟，當我們點選開啟時，知乎就被開啟了，這就是一個簡單的喚端體驗。

有了這項技術我們就可以實現H5喚起APP應用了，現階段的引流方式大都得益於這種技術，比如廣告投放、使用者拉新、引流等。

喚端技術

體驗過後，我們就來聊一聊它的實現技術是怎樣的，喚端技術我們也稱之為deep link技術。當然，不同平臺的實現方式有些不同，一般常見的有這幾種，分別是：

URL Scheme（通用）
Universal Link （iOS）
App Link、Chrome Intents（android）

URL Scheme（通用）

這種方式是一種比較通用的技術，各平臺的相容性也很好，它一般由協議名、路徑、引數組成。這個一般是由Native開發的同學提供，我們前端同學再拿到這個scheme之後，就可以用來開啟APP或APP內的某個頁面了。

URL Scheme 組成

[scheme:][//authority][path][?query][#fragment]

常用APP的 URL Scheme

APP	微信	支付寶	淘寶	QQ	知乎
URL Scheme	weixin://	alipay://	taobao://	mqq://	zhihu://

開啟方式

常用的有以下這幾種方式

直接通過window.location.href跳轉

window.location.href = 'zhihu://'

通過iframe跳轉

const iframe = document.createElement('iframe')
iframe.style.display = 'none'
iframe.src = 'zhihu://'
document.body.appendChild(iframe)

直接使用a標籤進行跳轉
通過js bridge來開啟

window.miduBridge.call('openAppByRouter', {url: 'zhihu://'})

判斷是否成功喚起

當使用者喚起APP失敗時，我們希望可以引導使用者去進行下載。那麼我們怎麼才能知道當前APP是否成功喚起呢？

我們可以監聽當前頁面的visibilitychange事件，如果頁面隱藏，則表示喚端成功，否則喚端失敗，跳轉到應用商店。

OK，我們嘗試來實現一下：

首先我手機上並沒有安裝騰訊微博，所以也就無法喚起，我們讓他跳到應用商店對應的應用下載頁，這裡就用淘寶的下載頁來代替一下～

<template>
  <div class="open_app">
      <div class="open_app_title">前端南玖喚端測試Demo</div>
      <div class="open_btn" @click="open">開啟騰訊微博</div>
  </div>
</template>

<script>
let timer
export default {
    name: 'openApp',
    methods: {
        watchVisibility() {
            window.addEventListener('visibilitychange', () => {
                // 監聽頁面visibility
                if(document.hidden) {
                    // 如果頁面隱藏了，則表示喚起成功，這時候需要清除下載定時器
                    clearTimeout(timer)
                }
            })
        },
        open() {
            timer = setTimeout(() => {
              // 沒找到騰訊微博的下載頁，這裡暫時以淘寶下載頁代替
                window.location.href = 'http://apps.apple.com/cn/app/id387682726'
            }, 3000)
            window.location.href = 'TencentWeibo://'
        }
    }
}
</script>

<style lang="less">
.open_app_title {
    font-size: (20/@rem);
}
.open_btn{
    margin-top:(20/@rem);
    padding:(10/@rem) 0;
    border-radius: (8/@rem);
    background: salmon;
    color: #fff;
    font-size: (16/@rem);
}
</style>

8.open_weibo.gif

適用性

URL Scheme 這種方式相容性好，無論安卓或者 iOS 都能支援，是目前最常用的方式。從上圖我們能夠看出它也有一些比較明顯的缺點：

無法準確判斷是否喚起成功，因為本質上這種方式就是開啟一個連結，並且還不是普通的 http 連結，所以如果使用者沒有安裝對應的 APP，那麼嘗試跳轉後在瀏覽器中會沒有任何反應，通過定時器來引導使用者跳到應用商店，但這個定時器的時間又沒有準確值，不同手機的喚端時間也不同，我們只能大概的估計一下它的時間來實現，一般設為3000ms左右比較合適；
從上圖中我們可以看到會有一個彈窗提示你是否在對應 APP中開啟，這就可能會導致使用者流失；
有 URL Scheme 劫持風險，比如有一個 app 也向系統註冊了 zhihu:// 這個 scheme ，喚起流量可能就會被劫持到這個 app 裡；
容易被遮蔽，app 很輕鬆就可以攔截掉通過 URL Scheme 發起的跳轉，比如微信內經常能看到一些被遮蔽的現象。

Universal Link （iOS）

Universal Link 是在iOS 9中新增的功能，使用它可以直接通過https協議的連結來開啟 APP。
它相比前一種URL Scheme的優點在於它是使用https協議，所以如果沒有喚端成功，那麼就會直接開啟這個網頁，不再需要判斷是否喚起成功了。並且使用 Universal Link，不會再彈出是否開啟的彈出，對使用者來說，喚端的效率更高了。

原理

在 APP 中註冊自己要支援的域名；
在自己域名的根目錄下配置一個 apple-app-site-association 檔案即可。（具體的配置前端同學不用關注，只需與iOS同學確認好支援的域名即可）

開啟方式

openByUniversal () {
  // 開啟知乎問題頁
  window.location.href = 'https://oia.zhihu.com/questions/64966868'
  // oia.zhihu.com
},

9.open_zhihu.gif

適用性

相對 URL Scheme，universal links 有一個較大優點是它喚端時沒有彈窗提示是否開啟，提升使用者體驗，可以減少一部分使用者流失；
無需關心使用者是否安裝對應的APP，對於沒有安裝的使用者，點選連結就會直接開啟對應的頁面，因為它也是http協議的路徑，這樣也能一定程度解決 URL Scheme 無法準確判斷喚端失敗的問題；
只能夠在iOS上使用
只能由使用者主動觸發

App Link、Chrome Intents（Android）

App Link

在2015年的Google I/O大會上，Android M宣佈了一個新特性：App Links讓使用者在點選一個普通web連結的時候可以開啟指定APP的指定頁面，前提是這個APP已經安裝並且經過了驗證，否則會顯示一個開啟確認選項的彈出框，只支援Android M以上系統。

App Links的最大的作用，就是可以避免從頁面喚醒App時出現的選擇瀏覽器選項框;

前提是必須註冊相應的Scheme，就可以實現直接開啟關聯的App。

App links在國內的支援還不夠，部分安卓瀏覽器並不支援跳轉至App，而是直接在瀏覽器上開啟對應頁面。
系統詢問是否開啟對應App時，假如使用者選擇“取消”並且選中了“記住此操作”，那麼使用者以後就無法再跳轉App。

Chrome Intents

Chrome Intent 是 Android 裝置上 Chrome 瀏覽器中 URI 方案的深層連結替代品。
如果 APP 已安裝，則通過配置的 URI SCHEME 開啟 APP。
如果 APP 未安裝，配置了 fallback url 的跳轉 fallback url，沒有配置的則跳轉應用市場。

這兩種方案在國內的應用都比較少。

方案對比

	URL Scheme	Universal Link	App Link
<ios9	支援	不支援	不支援
>=ios9	支援	支援	不支援
<android6	支援	不支援	不支援
>=android6	支援	不支援	支援
是否需要HTTPS	不需要	需要	需要
是否需要客戶端	需要	需要	需要
無對應APP時的現象	報錯/無反應	跳到對應的頁面	跳到對應的頁面

URI Scheme

URI Scheme的相容性是最高，但使用體驗相對較差:
當要被喚起的APP沒有安裝時，這個連結就會出錯，頁面無反應。
當註冊有多個scheme相同的時候，沒有辦法區分。
不支援從其他app中的UIWebView中跳轉到目標APP，所以ios和android都出現了自己的獨有解決方案。

Universal Link

已經安裝APP，直接喚起APP；APP沒有安裝，就會跳去對應的web link。
universal Link 是從伺服器上查詢是哪個APP需要被開啟，所以不會存在衝突問題
universal Link 支援從其他app中的UIWebView中跳轉到目標app
缺點在於會記住使用者的選擇：在使用者點選了Universal link之後，iOS會去檢測使用者最近一次是選擇了直接開啟app還是開啟網站。一旦使用者點選了這個選項，他就會通過safiri開啟你的網站。並且在之後的操作中，預設一直延續這個選擇，除非使用者從你的webpage上通過點選Smart App Banner上的OPEN按鈕來開啟。

App link

優點與 universal Link 類似
缺點在於國內的支援相對較差，在有的瀏覽器或者手機ROM中並不能連結至APP，而是在瀏覽器中開啟了對應的連結。
在詢問是否用APP開啟對應的連結時，如果選擇了“取消”並且“記住選擇”被勾上，那麼下次你再次想連結至APP時就不會有任何反應

H5如何實現喚起APP

前言

喚端體驗

喚端技術

URL Scheme（通用）

URL Scheme 組成

常用APP的 URL Scheme

開啟方式

判斷是否成功喚起

適用性

Universal Link （iOS）

原理

開啟方式

適用性

App Link、Chrome Intents（Android）

App Link

Chrome Intents

方案對比

推薦閱讀

相關文章