H5唤醒App并直达指定页面

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

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

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

这里其实就解释了咱们作H5唤醒App并直达指定页面的必要性。

 

涉及哪些要素？

唤醒App这件事，在不一样平台要采用不一样的方法，主要是这三个：

• URL Scheme
• Universal Link
• Android App Links

一、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。

二、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的限制，同时也能被搜索引擎索引。

三、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