H5 唤醒 APP 解决方案

时间  2019-11-08
标签 h5 唤醒 app 解决 方案 繁體版
原文   原文链接

参考：https://github.com/bsxz0604/R...javascript

核心代码

// dom
<a id="openApp" href="javascript:;" title="">当即打开</a>

// js
;(function (window) {
    var ue = {};

    // 客户端检测
    ue.browserInfo = function () {
        var json = {
            userAgent: navigator.userAgent.toLowerCase(),
            isAndroid: Boolean(navigator.userAgent.match(/android/ig)),
            isIos: Boolean(navigator.userAgent.match(/iphone|ipod|ipad/ig)),
            isWeChat: Boolean(navigator.userAgent.match(/MicroMessenger/ig)),
            isQQ: Boolean(navigator.userAgent.match(/ QQ/ig)),
            isQQBrowser: Boolean(navigator.userAgent.match(/MQQBrowser/ig))
        }

        return json;
    }

    // 唤醒APP
    ue.openApp = function () {
        var $btnOpenIos = $('#downloadIos');
        var browser = ue.browserInfo();
        var scheme = '';
        var iosVersion = browser.userAgent.match(/os\s*(\d+)/);
        var universalLink = 'a';

        iosVersion = iosVersion ? (iosVersion[1] || 0) : 0;

        if (browser.isAndroid) { // 安卓
            scheme = 'b';
        } else if (browser.isIos) { // ios
            scheme = 'c';
        }

        $btnOpenIos.on('click', function () {
            //客户端检测微信
            if (browser.isWeChat) {
                $('.pop-openbrowser').show();
            } else {
                if (browser.isAndroid) {
                    var ifr = document.createElement('iframe');
                    ifr.src = scheme;
                    ifr.style.display = 'none';
                    document.body.appendChild(ifr);

                    setTimeout(function () {
                        document.body.removeChild(ifr);
                    }, 2000);
                } else {
                    // ios9+
                    if (iosVersion >= 9) {
                        document.location.href = universalLink;
                    } else {
                        setTimeout(function () { // 必需要使用settimeout
                            var a = document.createElement("a"); //建立a元素
                            a.setAttribute("href", scheme), a.style.display = "none", document.body.appendChild(a);
                            var t = document.createEvent("HTMLEvents"); // 返回新建立的 Event 对象，具备指定的类型。
                            t.initEvent("click", !1, !1) // 初始化新事件对象的属性
                            a.dispatchEvent(t) // 绑定事件
                        }, 0)
                    }
                }

                var checkOpen = function (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);
                }
                checkOpen(function (opened) {
                    // APP没有打开成功  而且开启自动跳转到下载页
                    if (opened === 0) {
                        location.href = universalLink
                    }
                });
            }
            ue.trackEventDownload();
        });
    };

    ue.init = function () {
        ue.openApp();
    };
})(window);
$(function () {
    ue.init();
})

业务逻辑

概念叙述

调起APP在不一样平台用不一样的方式，主要就分3个html

* URI Scheme
* universal Link
* Android App Links

如今仍是有不少第三方（例如魔窗）来协助你处理这个事情，经过接入他们的SDK和客户端代码来处理，可是万变不离其宗，全部的第三方也离不开这3种方式。前端

  1. URI Scheme:java

    • URI Scheme 是iOS，Android平台都支持，只须要原生APP开发时注册 scheme ， 用户点击到此类连接时，会自动唤醒APP，借助于 URL Router 机制，则还能够跳转至指定页面。

    • <scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]android

      • <scheme name>：是scheme的名称，表明着协议名称。
      • <hierarchical part>：它包含 authority 和 path。
      • <query>：可选项目，隔开或&隔开的键值对<key>=<value>
      • <fragmentg> ：可选项目包，其它额外的标识信息

例如：ios

git://github.com/user/project-name.git
ftp://user1:1234@地址
musically://musical?id=xxxx&key=xxxx

  1. universal Link:git

    • iOS9 后推出的一项功能，通用连接，对于前端即访问一个https的url,若是这个url带有你提交给开发平台的配置文件中匹配规则的内容，iOS系统会去尝试打开你的app，若是打不开，系统就会在浏览器中转向你要访问的连接。

    • universal Link 工做方式以下：github

      1. 访问web link
      2. iOS访问 https://xxxxxxx/apple-app-sit... 并解析，获取文件中的信息(App的Team ID和Bundle ID)
      3. 经过Bundle ID 检查本地是否存在对应app，和检查PATH信息等，若是有app打开app，若是没有则跳转对应web link(可经过代码实现跳去app Stroe)

  2. Android App Links:web

    • 在2015年的Google I/O大会上，Android M宣布了一个新特性：App Links让用户在点击一个普通web连接的时候能够打开指定APP的指定页面，前提是这个APP已经安装而且通过了验证，不然会显示一个打开确认选项的弹出框，只支持Android M以上系统。
    • 简单的说就是创建APP和某个连接的关联，避免系统在处理该类型连接时弹出选择框。弹框最多见的就是浏览器打开时的选择框。弹出选择框是应用注册了相应scheme，applinks的做用是避免在打开本身域名的连接时弹出选择（前提是注册了相应scheme），能够实现直接打开本身关联的app。

对比/优劣

1. URI Scheme

URI Scheme的兼容性是最高，在使用的过程当中，会发现有不少限制：json

  • 当要被唤起的app没有安装时，这个连接就会出错。在国内很是杂乱的浏览器中，会出错的现象会不少种类型。
  • 当注册有多个scheme相同的时候，目前没有办法区分。
  • 不支持从其余app中的UIWebView中跳转到目标app

也就由于会有这些缘由，apple和android都出现了本身第二套解决方案。

2. 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按钮来打开。

3. app link 和 universal Link

差别不大。也是为了更好的提供调起app出现的google的方案。优势与 universal Link 差很少，缺点主要以下：

* 国内的支持相对较差，在有的浏览器或者手机ROM中并不能连接至APP，而是在浏览器中打开了对应的连接。 
* 在询问是否用APP打开对应的连接时，若是选择了“取消”而且“记住选择”被勾上，那么下次你再次想连接至APP时就不会有任何反应

不管哪种方式目前都没有解决几个问题：

  • 若是设备上没有安装这个app的时候，安装完毕后，没法保留住此时用户停留的上下文。
  • 由于web没有办法监听到APP是否安装，因此都须要经过一些手段来兼容调起app或者是去下载页

使用 & 须要注意的内容

  1. URI Scheme：

    • 使用: 这种方式是当期使用最普遍，也是最简单的，可是须要 APP 支持 URI Scheme 。
    • 须要注意的内容 & 遇到的问题：
其实使用URI Scheme 部分前端没有太多能够排查的问题，会遇到的问题主要是两个部分。1. 在android的兼容性处理（国内的浏览器无力吐槽ing），2. 当没有安装app的状况，URI Scheme 会有各类报错，也须要处理…

  1. universal Link & app Links

    • 使用：对于有app的用户，只是打开一个链接，可是须要注意的是须要考虑到没有APP的用户。(我的的解决方案：针对域名来判断，当域名为特定的universal Link 的域名，则跳转去下载页面）

    • 须要注意的内容 & 遇到的问题：

      1. apple-app-site-association 和 assetlinks.json 的配置
      2. 须要保证使用的连接跨域(universal Link)
      3. 直接将universal Link 贴入浏览器的url中不会生效
      4. 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}}">

第三方服务

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

若是以为实现难度或者成本过高，你能够考虑使用第三方提供的服务，例如魔窗的`mLink。具体请查看官网，在此不赘述。

使用 checkList(前端)

  1. scheme

    • iOS 和 android 是否已经支持 此scheme
    • js处理兼容代码

  2. 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 从新启用
    • 跳转处理是不是在用户事件中触发，而不是进入页面后直接触发

  3. app links (android app links官方文档)

    • HTTPS的域名
    • 跳转后的落地页是不是下载页面

    • assetlinks.json 配置在 host的.well-known下

  4. facebook (facebook app link官方文档)

    • 将须要的meta头信息填充完毕
    • 检测连接 分享调试器 - Facebook for Developers , 确认分享连接中获取到了所须要的meta头
    • 分享过的连接会有缓存，在检测中清楚缓存
    • 若是web和wap连接一致，确认在web中也添加了相同的meta头，facebook会默认从web中获取

  5. twitter (Twitter app card官方文档)

    • 将须要的meta头信息填充完毕
    • 检测连接 Twitter app card 检测
    • 若是web和wap连接一致，确认在web中也添加了相同的meta头，facebook会默认从web中获取

可能出现的 bug

1. iOS 11.2 universal link 失效的 bug：

https://blog.branch.io/notice...

失效现象：
没法直接唤醒app，而是直接跳转到appStore，用户再点击【打开】。

解决方案：
iOS 开发能够配置通用连接让其【强制打开】，可是可能出现该错误提示框，这样给用户的体验反而更很差。

2. QQ浏览器、微信已屏蔽 scheme & universal link

腾讯系封杀了除本厂及白名单 app 以外的全部 app 的唤醒功能。

参考资料连接

  1. webview如何屏蔽universal Link
  2. apple-app-site-association 官方文档
  3. apple-app-site-association 检测
  4. android app links官方文档
  5. android app links检测
  6. facebook app link官方文档
  7. 分享调试器 - Facebook for Developers
  8. Twitter app card官方文档
  9. Twitter app card 检测
相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程