允许网页打开android应用程序,Android浅谈网页打开APP(一）

首先先说一下早先开发中集成andorid App Links 遇到的问题：

华为部分手机可以直接打开app指定页面

vivo连应用选择弹框都不弹，直接交给浏览器处理跳转了

google的亲儿子nexus有应用选择弹框，选择用你的app打开才可以进入指定页面

上面的遇到的问题都是在android M系统以上机型进行的测试，而且intent-filter和assetlinks.json文件配置无误，所以姑且认定App Links 在各种机型上表现很不稳定。

撇开这些不稳定不说，由于大部分应用，如微博、微信、第三方浏览器(包括Chrome)，都不会将URL抛给系统处理，因此App Links生效的情况就更加的有限了，比如只能从记事本应用、短信应用这些进行跳转。总体来说，实属鸡肋。

关于通过H5页面唤App的介绍

背景：

目前通过H5页面唤起native App的场景十分常见，比如常见的分享功能；一方面，对于用户而言，相同的内容在native app上比H5体验更好，操作更加方便，另一方面，对于app运营来说，可以增加app的用户粘性度。

方案：

在Android端，常用的方式是URI schame + Android Intent，在Android览器中(非微信浏览器)，可以通过scheme协议的方式唤醒本地app客户端；scheme协议在App注册之后，与前端进行统一约定，通过H5页面访问某个具体的协议地址，即可打开对应的App客户端页面。

URI scheme简介

Android中的自定义的URI scheme是一种页面内跳转协议，也可以被称为URI Router，就是通过类似打开网页的方式去通过路由打开一个Activity，而非直接通过显式Intent方式去进行跳转。

一个完整的完整的URI scheme协议格式由scheme、host、port、path和query组成，其结构如下所示：

://:/?

Android Intent

intent是Android应用/组件间通信的一种方式，Android利用Intent建立对象连接和实现组件通讯，称为意图机制。通过Intent，你的程序可以向Android表达某种请求或者意愿，Android会根据意愿的内容选择适当的组件来完成请求。每个组件可以注册intent filter声明自己对什么样的intent感兴趣，其它应用发送intent时通过系统级广播传递过来，如果与预先注册的intent filter匹配，应用将收到该intent(无论应用是否正在运行，都会被“唤醒”，也就是隐式启动Activity)，取出intent携带的数据，做进一步处理。

Intent对象构成：

Action项(Action表达动作，是一个字符串，通过Intent.setAction()设定，还可以Intent.getAction()读取动作信息；Action命名同包名类似，以保持唯一性和可拓展性)；

Data项：通过Intent.setData()或Intent.setDataAndType()设置。Data数据用字符串URI存取；

Type项：通过Intent.setType()或Intent.setDataAndType()设置。Type是MIME类型数据，可以使用通配符*来表示整个类别信息。

Category项：表示条件约束。一个Intent可以有多个Category，Intent.addCategory()添加，多个Category是与关系。

Component项：目标组件的类型信息。Intent.setComponent()利用类名设定，或Intent.setClass()利用类型对象设定。

Extra项：是一个Bundle对象，以键值对存储数据，可对数据进行系列化和反序列化。

步骤：

声明自定义scheme

在manifest里静态注册intent filter声明自定义scheme：

activity android:name=".MainActivity">

android:host="urldomain"/>

取出数据

在onCreate里拿到intent，取出uri，并进行处理：

// 获取uri参数

Intent intent = getIntent();

String scheme = intent.getScheme();

Uri uri = intent.getData();

到此，客户端准备就绪，需要h5端进行调用schema:

在线页面呼起App:

浏览器先发出自定义scheme请求，系统广播收到后再分发给各应用，那么页面发送请求的方式就多了：

location.href

iframe.src

a.href

img.src

...其它能发出请求的方式

这些方式在强弱上有区别，比如location.href是强的，而img.src很弱，至少要强到浏览器决定把这个请求交给系统广播才行，比如img请求自定义scheme，浏览器认为没有必要交给系统广播。一般只用前2种最强的方式：location.href和iframe.src，隐藏iframe偷偷请求自定义scheme相对用得更多，因为不会有未知的副作用(location方式或许可能被记入历史栈或者unload当前页，但iframe绝对没有太严重的副作用)

但无论哪种方式，都无法得知App被呼起了没，可能没安装App，也可能intent没匹配成功，但页面肯定没有办法得知。所以一般呼起App的页面都会延迟自动跳转下载页，无论有没有成功呼起App，这也是迫不得已。

经过非全面测试：

经过测试，Android系统上，Chrome无法通过iframe.src 来调用schema，而通过a.href 的方式可以成功调用，而针对基于chrome内核的浏览器如猎豹，360，小米浏览器，华为浏览器， opera对于iframe.src和a.href的方式都能支持 ；对于其他浏览器，如UC，firefox,mobile QQ，sogou浏览器则采用iframe.src的方式调用schema。对于微信，qq，则直接跳转到下载页。其他未经测试的浏览器，默认采用iframe.src来调用schema。测试中发现另外一个问题，通过a.href调起app的有时会有空白页，另外考虑到我大天朝用Chrome浏览器的少之又少，所以优先考虑iframe.src的方式来调用scheme。

对于URI scheme和intentd的详细分析请看：