H5如何实现唤起APP

Posted 2023-04-03 前端南玖

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了H5如何实现唤起APP相关的知识，希望对你有一定的参考价值。

前言

写过hybrid的同学，想必都会遇到这样的需求，如果用户安装了自己的APP，就打开APP或跳转到APP内某个页面，如果没安装则引导用户到对应页面或应用商店下载。这里就涉及到了H5与Native之间的交互，为什么H5能够唤起APP并且跳转到对应的页面？

就算你没写过想必也体验过，最常见的就是抖音里面的一些广告，如果你点击了广告，他判断你手机装了对应APP，那他就会去打开那个APP，如果没安装，他会帮你跳转到应用商店去下载，这个还算人性化一点的，有些直接后台给你去下载，你完全无感知。

哈哈，是不是觉得这种技术很神奇，今天我们就一起来看看它是如何实现的～

如果这篇文章有帮助到你，❤️关注+点赞❤️鼓励一下作者，文章公众号首发，关注 前端南玖 第一时间获取最新文章～

唤端体验

实现之前我们先简单体验一下什么是唤端

从上图中，我们可以看到在浏览器中我们点击打开知乎，系统会提示我们是否在知乎中打开，当我们点击打开时，知乎就被打开了，这就是一个简单的唤端体验。

有了这项技术我们就可以实现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>

适用性

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
,

适用性

相对 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时就不会有任何反应

浏览器中打开

iOS/Android APP配置

这块内容其实比较简单，在网上都有很多资料可供查阅，就不再赘述。

原理说明

首先需要说明，不管iOS还是Android，浏览器都不可能预知本地是否安装了某个APP的。或者更严谨地说，我们不能通过浏览器来预知本地是否安装。因为就算浏览器可以读取本地应用的安装列表，但是目前也没任何一家浏览器提供查询的API，所以这条路是走不通的。

本质上浏览器是通过URL scheme打开APP，一个APP可以设置一个或多个打开自己的URL scheme。比如，Twitter就注册自己能被「twitter://」打开。

其实，如果是做APP间相互跳转是比较简单的。iOS就可以使用 UIApplication 的 canOpenUrl 方法来检测URL scheme 是否能打开对应的APP。比如，如果「twitter://」检测能被打开，也就说明本地安装了 Twitter 。再用 UIApplication 的 openURL 方法，就能打开Twitter了。Android 中的做法类似。

实现方案

因为iOS9和之前的iOS系统有区别，所以这里我们也要区别对待。

iOS7/iOS8

iOS中默认通过Safari打开URL scheme，方法一般如下两种：

直跳方式：点击链接、修改 window.location 等。
iframe 方式：在 body 上添加 iframe，设置src属性为跳转的URL scheme。

第一种情况：

<a href="schemeUrl">唤醒你的APP</a>

或者

window.location.href = schemeUrl;

但在第一种情况，如果APP唤醒失败，或者APP未安装的话，很多时候都会跳到错误页，这很影响用户体验，而我们的要求可能是跳转到其他页面或者下载APP。

后一种方法不会引起页面可见的变化（例如页面内容变成一个新页面），不会导致浏览器历史记录的变化，大致实现如下：

<a href="APP下载地址">下载或打开APP</a>
<script>
$(‘a‘).click(function() {
    var ifr = document.createElement(‘iframe‘);
    ifr.src = ‘自定义 URL scheme‘;
    ifr.style.display = ‘none‘;
    document.body.appendChild(ifr);
    setTimeout(function(){
        document.body.removeChild(ifr);
    }, 3000);
});
</script>

过程是这样：点击 a 标签时，首先会尝试打开URL scheme，如果成功，就唤起APP；如果失败，则跳转到 href 属性，即下载页。

Android

但这个方案在很多安卓机型上有问题，为保证可用，改用第一种方案：

$(‘a‘).click(function() {
    location.href = ‘自定义 URL scheme‘;
    t = Date.now();
    setTimeout(function(){
        if (Date.now() - t < 1200) {
            location.href = ‘Android 下载地址‘;
        }
    }, 1000);
    return false;
}

理想过程是这样：浏览器尝试打开 URL scheme，在1秒计时后，检查当前时间，如果实际时间已过 1200 毫秒，说明唤起APP 成功（唤起 APP 会让浏览器的定时器变慢）；如果没超过 1200 毫秒，很可能是没有安装应用，就跳到下载地址。

或者换种方式：

var ifr = document.createElement(‘iframe‘);
ifr.src = ‘com.baidu.tieba://‘;
ifr.style.display = ‘none‘;
document.body.appendChild(ifr);
var openTime = +new Date();
window.setTimeout(function(){
    document.body.removeChild(ifr);
    if( (+new Date()) - openTime > 2500 ){
        window.location = ‘http://exam.com/xxxx.apk‘;
    }
},2000)

但原理都是一样，利用setTimeout。但这其实不稳定，因为Android是基于Linux的分时多任务的，setTimeout的基准偏差可能会没那么大。

但如果设置比较小的运行间隔（<30ms），在浏览器或者webview中，应用切换到后台，setInterval会被很明显的延迟执行，比如设置一个运行间隔20ms，总计运行100次的定时器，如果页面一直处于前台，则100次跑完，总耗时与 100x20=2000ms不会有太大差异，但页面在后台运行时，此时间会明显超过2000ms。可以利用这一点来实现是否成功打开APP检测及回调。

function openApp(openUrl, appUrl, action, callback) {
    //检查app是否打开
    function checkOpen(cb){
        var _clickTime = +(new Date());
        function check(elsTime) {
            if ( elsTime > 3000 || document.hidden || document.webkitHidden) {
                cb(1);
            } else {
                cb(0);
            }
        }
        //启动间隔20ms运行的定时器，并检测累计消耗时间是否超过3000ms，超过则结束
        var _count = 0, intHandle;
        intHandle = setInterval(function(){
            _count++;        
            var elsTime = +(new Date()) - _clickTime;
            if (_count>=100 || elsTime > 3000 ) {
                clearInterval(intHandle);
                check(elsTime);
            }
        }, 20);
    }
    
    //在iframe 中打开APP
    var ifr = document.createElement(‘iframe‘);
    ifr.src = openUrl;
    ifr.style.display = ‘none‘;
    if (callback) {
        checkOpen(function(opened){
            callback && callback(opened);
        });
    }
    
    document.body.appendChild(ifr);      
    setTimeout(function() {
        document.body.removeChild(ifr);
    }, 2000);  
}

另外，可以通过 document.hidden 或 document.[webkit|moz|ms]Hidden 来判断页面是否被置入后台（即应用被唤起），或visibilitychange事件，但对于Android 4.4版本一下则不支持。

iOS9

在 iOS 9 上，iframe 方案变得不可用。按不能使用之前Android的代码，因为在打开自定义 URL scheme 时，会弹出对话框，询问是否用 xx 应用来打开。往往用户还没来得及点击打开，定时器又触发了，导致跳到 App Store。

可以在尝试打开URL scheme 后，再加一个页面跳转，这样对话框会被覆盖，再刷新页面，就能无需确认唤起APP：

$(‘a‘).click(function() {
    location.href = ‘自定义 URL scheme‘;
    location.href = ‘下载页‘;
    location.reload();
}

这里，下载页延时 2 秒跳转到 App Store。

APP已安装这是没问题的，但如果APP未安装，跳 App Store 的请求会失败。这时可以使用两个定时器：

$(‘a‘).click(function() {
    location.href = ‘自定义 URL scheme‘;
    setTimeout(function() {
        location.href = ‘下载页‘;
    }, 250);
    setTimeout(function() {
        location.reload();
    }, 1000);
}

不过在iOS9中其实是支持universal link的，就是一个http域名形式，在微信中都可以唤起APP。如果未安装的话，可以直接引导用户去APP store下载。

可以参考这篇文章

http://www.magicwindow.cn/doc...

没有完美的解决方案

主要是在安卓上，总归会有各种兼容问题，知乎的解决办法是，提供两个按钮，一个下载，一个打开APP，让用户自己选。

微信中打开

因为微信将唤起本地APP的接口给禁了，所以微信中是不能直接唤起APP的，一般做法是提示用户在浏览器中打开，之后的流程还是我们上面讲的内容。

但是，在iOS9中，这个限制是可以突破的，也就是说可以直接唤起APP。方法就是使用我们上文提到的universal link。

在Android和iOS8及其以下系统中，我们可以利用腾讯的亲儿子：应用宝。简单讲，就是把你的唤起地址配置成你APP的应用宝地址，微信中跳转到这个地址后，如果用户已经安装了APP，则可直接唤起，如果没有安装，则可直接点击下载，如下图示：

技术分享

但这里有坑需要注意。

对于使用universal link来说，如下图所示用户在微信中打开APP之后，可能不小心点击右上角的链接（比方说点几分享，却不小心点击了"mlinks.cc"），导致跳到外部浏览器中，如下图所示：

技术分享

这时候再在微信中就打不开APP了，因为universal link已被关闭，这是iOS9的机制，没法改变，这时候用户再在微信中打开，就得需要一个中间页来引导用户在外部浏览器中打开APP，如下图所示：

技术分享

另外，在微信中唤醒APP默认只能到达首页，即不能到达指定页面或内容，如果想要做，则需要额外的处理。

拿来主义

从以上内容可以总结出：要做一个兼容性很好的方案，就需要考虑各种情况，在不同的情况适配不同的方案，比方说用户是在手机浏览器打开还是微信中打开，或者是在pc中打开，universal link是否被关闭等，这就使代码实现变得复杂，且容易出错，且还有安卓平台机型众多、浏览器众多等导致的兼容问题。

如果觉得实现难度或者成本太高，你可以考虑使用魔窗的mLink。只要你加了魔窗的sdk，就可以通过类似“https://s.mlinks.cc/AA01”的链接，在任何环境下打开你的APP（如果在pc机上打开，浏览器中将会出现APP下载地址的二维码），上面提到的问题都不复存在，并且魔窗已经兼容超过600台以上安卓机型的第三方主流浏览器。而且关键的是，不管是在手机浏览器中，还是在微信中打开，你可以指定唤起APP后直达APP中的某个页面或内容（某个促销商品等），就算用户没安装APP，点击下载安装之后，再打开，还是跳转到指定的页面，这就是场景还原，或者叫做Deffered Deep Linking。

以上是关于H5如何实现唤起APP的主要内容，如果未能解决你的问题，请参考以下文章

H5网页在浏览器中唤起app，怎么实现？

iOS/Android 浏览器(h5)及微信中唤起本地APP

H5如何实现唤起APP

前言

唤端体验

唤端技术

URL Scheme（通用）

URL Scheme 组成

常用APP的 URL Scheme

打开方式

判断是否成功唤起

适用性

Universal Link （iOS）

原理

打开方式

适用性

App Link、Chrome Intents（Android）

App Link

Chrome Intents

方案对比

推荐阅读

iOS/Android 浏览器(h5)及微信中唤起本地APP

浏览器中打开

iOS/Android APP配置

原理说明

实现方案

iOS7/iOS8

Android

iOS9

没有完美的解决方案

微信中打开

拿来主义