H5如何實現喚起APP

前端南玖 發表於 2022-05-15

前言

寫過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 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)

在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時就不會有任何反應

推薦閱讀

原文首發地址點這裡,歡迎大家關注公眾號 「前端南玖」,如果你想進前端交流群一起學習,請點這裡

我是南玖,我們下期見!!!