乐趣区

H5唤醒App快速直达App核心页面

jiezi

在这个流量为王的互联网背景下，移动端的 H5 页面显然在导流上承担着重要作用，在 H5 页面上，我们对引流的需求有两种：

  • 一是引导已下载用户从 H5 页面唤醒 App 并直达指定场景
  • 二是引导未下载用户从 H5 页面下载 App，首次打开 App 时直达指定场景

从运营角度来看，引导已下载用户打开 App，能提高用户粘性和活跃度，而用户在 App 内的产品体验自然也比 H5 页面要好；引导未下载用户下载 App 并进入指定页面，显然能给用户更好的产品初体验。

这里其实就解释了我们做 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 本身业务需求不高，那么低精度的方案也可以满足，但如果业务上需要一个能做到一对一精准匹配的方案，那么精准度不够高显然会影响业务的开展。

第三方服务

如果嫌精准度不够高或者实现难度太大的话，可以交给专业的第三方去做，毕竟这几项技术是基于系统平台的，Android 及 iOS 每个系统版本的迭代后，配置方式都会有新的变化，且安卓机型众多，浏览器众多等也会导致出现兼容问题，开发者自行研发的话，资源配置以及系统更新后的维护成本是比较高的，还要考虑各种各样的跳转场景问题。

直接采用第三方 SDK 的好处就是，资源配置、兼容方面的适配这些事情都可以交给它们去做，毕竟这些供应商本身就是专业做这项服务的，它们提供的服务在稳定性和精准度方面也是经受过市场检验的，至少在精准匹配方面，有些已经能在邀请分享方面做到一对一匹配，集成 SDK 也花不了多少时间，十几分钟就可以搞定。

国内外提供这项技术的第三方服务商：
国内有：openinstall
国外有：Branch

退出移动版