其实 H5 打开 APP 本来应该是一件很简单的事，无非是在 H5 页面上调用一个协议或者接口将 APP 打开嘛。但是因为技术方案的发展和某些流量 APP 的封锁，唤起 APP 的方案就变得复杂了起来。本文从介绍唤起 APP 的诸多方案入手，讲述各个方案的优缺，期望读者能从全局的角度对 H5 唤起 APP 有一个系统的认识。
1. 唤起 APP 的方案
如下图，当前主要有三种打开 APP 的渠道：流量 APP 封装渠道，原生的打开渠道以及一些奇技淫巧。
1.1 流量 APP 封装渠道
微信、手 Q 和微博等流量入口为了保证流量不流失，对 iOS 和 Android 原生的唤起方案做了屏蔽和封装。在这些 APP 中，使用原生唤起 APP 方案是无效的，只能用他们的方案或者位于白名单中的 APP 才能通过 H5 的唤起 APP。
1.1.1 微信
微信最初唤起 APP 方案是 WXJSBridge，后来变为了 WX JS-SDK。这时候有人可能就要说了，你瞎说，我根本没有看到 JS-SDK 上有关于唤起 APP 的相应接口。其实这些关于 APP 的接口都是有的，只不过没有写在文档中。
要使用微信的唤起 APP 方案需要两点：
明确知道唤起 APP 的接口
要唤起的 APP 本身就处于微信的白名单中
所以对于第三方 APP，即使知道了接口的名字也不能用。
而 JS-SDK 和 JSBridge 的本质实现都是一样的，但是 JS-SDK 还要求使用者在自己的后台全局缓存一个 jsapi_ticket，如果是腾讯系单纯想做唤起 APP 方面的逻辑的话，直接使用 JSBridge 无疑是个又快又好的做法。
1.1.2 手 Q
手 Q 和微信一样，也对唤起 APP 做了封装，同样又白名单的限制，所以也只有腾讯系的 APP 才能使用。
但是在微信中，唤起腾讯系 APP 使用 schema 是不行的，但是对于在手 Q 打开腾讯系 APP，可以选择使用 schema 而不是手 Q 的封装方案 MPP.
另外说一点，手 Q 的 MPP 唤起 APP 并传递参数的方法有点问题，文档写的也不完善，确实不如直接用 schema 唤起好用。
1.1.3 其他流量 APP
主要是指微博，手机百度等 APP，应该也是白名单的打开方式，平常用的不多，这里不做赘述。
2. 原生渠道
2.1 Schema
Schema 是一种页面内跳转协议，主要有以下几部分组成 [1]
行为 (应用的某个功能)
|
scheme://[path][?query]
| |
应用标识 功能需要的参数
但是在 Chrome25 之后，iOS9 以后，Android 和 iOS 原生都不再支持这种协议，转而转变为新的方案 App Link 和 Universal Link。
对比起这种方案，Schema 不能判断出是否打开 APP 成功，也就不能针对没有打开 APP 做一些处理（只能通过 hack 的手段，通过判断页面是否可见来达到这一点）。但是，Schema 现在在除原生以外各大移动端浏览器上（如 QQ 浏览器，Chrome 浏览器等）都有不错的支持，而且使用 schema 不用客户端做额外的处理，做一些简单的逻辑还是可以用的。
2.2 Universal Link
Universal Link 是 iOS 开发的一种无缝链接 APP 和 Web 的方式。当访问一个链接时，如果安装了 APP，那么直接跳转 APP 的相应页面，如果没有安装 APP，则跳转相应的 H5 页面。不过我们可以利用它的这种特性来唤起 APP。
Universal Link 有几个缺陷：
要唤起的 APP 要做相应的支持
当前的页面和唤起的域名一定要跨域才可以
必须是 Https
2.3 APP Link
APP Link 的初衷和 Universal Link 一致，都是为了给用户提供无缝的用户体验——如果安装了 APP 则跳转 APP，没有安装 APP 就跳转相应页面，因此，我们也可以用它来做唤起 APP。同样的，它也需要 APP 做相应的设置。
不过 APP Link 是 Android 上提供的方案，它和 Universal Link 不同的是：不需要使用 https 协议
3. 其他渠道
3.1 应用宝渠道
应用宝渠道是应用宝借用自己腾讯系 APP 的能力，利用自己的权限来帮助其他 APP 在微信上唤起，换取其他推广资源的行为。
不过这种方案已经被微信给封杀了。所以当前，作为一个第三方 APP，是没有办法在微信上唤起的。
4. 总结
本文泛泛的总结了市面上常见的 H5 唤起 APP 方案，罗列了它们的优缺点。受限于腾讯系本身白名单的限制，没有办法给出一个最佳实践，但是也希望能给大家对 H5 唤起 APP 提供一些帮助。