1. 首页
  2. >
  3. 编程技术
  4. >
  5. Android

H5页面一键拉起App,并直达指定页面

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

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

从运营角度来看,引导已下载用户打开App,能提高用户粘性和活跃度,而用户在App内的产品体验自然也比H5页面要好;引导未下载用户下载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> :可选项目包,其它额外的标识信息

H5页面一键拉起App,并直达指定页面

尽管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