首先先说一下早先开发中集成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组成，其结构如下所示：
<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">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
<!--注册scheme-->
<intent-filter>
<!--必有项-->
<action android:name="android.intent.action.VIEW"/>
<!--表示该页面可以被隐式调用，必须加上该项-->
<category android:name="android.intent.category.DEFAULT"/>
<!--BROWSABLE指定该Activity能被浏览器安全调用-->
<category android:name="android.intent.category.BROWSABLE"/>
<!--协议部分-->
<!--声明自定义scheme，类似于http, https-->
<data android:scheme="urlscheme"
android:host="urldomain"/>
</intent-filter>
</activity>
- 取出数据
在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的详细分析请看：