这里其实就解释了我们做H5唤醒App并直达指定页面的必要性。
涉及哪些要素？
唤醒App这件事，在不同平台要采用不同的方法，主要是这三个：
URL Scheme
Universal Link
Android App Links
1、URL Scheme
URL Scheme是iOS、Android都兼容的机制，只需要原生App开发时注册Scheme即可，用户点击此类链接时，会自动唤醒App，并借助URL Router机制跳转到指定页面。
<scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]
<scheme name>：是scheme的名称，代表着协议名称。
<hierarchical part>：它包含 authority 和 path。
<query>：可选项目，隔开或&隔开的键值对<key>=<value>
<fragmentg> ：可选项目包，其它额外的标识信息
尽管URL Scheme兼容性高，但却存在许多限制，比如：
国内各个厂商浏览器差异很大，当要被唤醒的目标App未安装时，这个链接很容易出错。
当注册有多个Scheme相同的时候，目前是没有办法区分的。
不支持从其他App中的UIWebView中跳转到目标App。
被部分主流平台禁止，微信、微博、QQ浏览器、手机百度中都已经被禁止使用。
正是由于这些限制的存在，苹果和安卓都不约而同发布了自己的第二套方案：iOS的Universal Link、Android的App Links。
2、Universal Link
Universal Link是iOS9后苹果推出的通用链接技术，能够方便的通过一个https链接来打开App指定页面，不需要额外的判断，如果没有安装App，可以跳转到自定义地址。
相对Scheme的优势在于，Universal Link是一个Web Link，因此少了很多麻烦：
当用户已安装该App时，不需要加载任何页面，能够立即唤醒App，用户未安装App，则跳去对应的web link（自定义页面）。
Universal Links支持从其他App中的UIWebView中跳转到目标app。
提供Universal Link给别的App进行App间的交流，然而对方并不能够用这个方法去检测你的App是否被安装，具有比较好的隐私性。
绝大多数平台都支持Universal Link，微信7.0.5版本也解除了对Universal Link的限制，同时也能被搜索引擎索引。
3、App Links
Android M以上版本可以通过App Links，让用户在点击一个链接时跳转到App的指定页面，前提是这个App已经安装并经过验证。App Links的最大的作用，就是可以避免从页面唤醒App时出现的选择浏览器选项框，前提是必须注册相应的Scheme，就可以实现直接打开关联的App。
实际上App Links和Universal Links差异不大，但相对来说有不同的限制：
App links在国内的支持还不够，部分安卓浏览器并不支持跳转至App，而是直接在浏览器上打开对应页面。
系统询问是否打开对应App时，假如用户选择“取消”并且选中了“记住此操作”，那么用户以后就无法再跳转App。
几个方案的缺陷
这几种方式无论哪种都无法解决这几个问题：
当用户未安装目标App时，无法保留用户停留的上下文，也就是说，用户下载完App后，无法在首次打开App时还原指定页面。
Web目前无法监听App是否已安装，因此这几个方案都需要一些其他方法兼容唤醒App，或者跳转下载页面。
那么怎样实现用户安装App后进入指定页面呢？
众所周知，苹果出于用户隐私的保护，设置了名为沙盒的机制：应用只能访问它声明可以访问的资源，但沙盒也阻碍了应用间合理的信息共享。
但也不是完全没办法，比如使用模糊匹配，尽可能收集设备的特征，将Web和App上的信息点配合算法做一个匹配是可以做到的，但准确率和成功率就取决于算法本身。如果App本身业务需求不高，那么低精度的方案也可以满足，但如果业务上需要一个能做到一对一精准匹配的方案，那么精准度不够高显然会影响业务的开展。
