上一篇 已经介绍了 iOS 系统层面提供的应用之间跳转的技术和实施方案,本篇会带大家更深入的了解 UniveralLinks 技术,探究其绑定运作原理,使用时的技巧。
对于 UniversalLinks 的生效和绑定原理,官方文档并未说明,通过亲自尝试整理出了其绑定原理,这有助于对于触发时机把握:
,读取 JSON 文件中的 app 绑定信息,与当前 App 内的信息做对比。
- apple-app-site-association
也就是只要 App 安装完成,就可以即刻触发 UniversalLinks 打开 App 啦!不需要像推送那样,需要打开一次。
上一篇文章也提到了,目前所有包括 UniversalLinks 技术都无法直接对 App 的安装做判断。
但我要说:非也!UniversalLinks 提供的一项特性可以让我们反向推断 App 是否安装,而且准确率相当高,不像 scheme 跳转那样,只能做延时。
UniversalLinks 在触发时,也就是链接被点击时,系统会与本地已经建立双向绑定的数据进行匹配,匹配到的话,这个网络请求就会在系统层面被拦截,系统就会转而打开绑定的 App,并把完整 URL 传给 App 的 openURL 的 Delegate 方法来处理。反之,如果 App 没有安装,那么点击链接时系统无法匹配到信息,则就将请求放行,让服务端接收到这个请求来处理。
看到这里已经很明了了吧,用户只要点击了,服务端可以通过是否接收到请求来判断 App 是否已安装。
当然这里也会不准,但概率比较小,原因如果用户是长按打开,或者打开 App 后点击了右上角的系统的返回按钮后,系统会下次触发 UniversalLinks 的时候就不会拦截请求了,导致接收到请求的设备其实已经 App,而我们无法知道。要想重新让系统拦截,用户需要点击的时候长按 link,并且选择通过 App 打开,之后才又会被拦截。
但已经比 scheme 跳转设置一个 timeout 要来的靠谱的多了。
UniversalLinks 作为一个平滑使用体验的工具类技术来说,本身不具备拉新客户的功能:比如新用户如果从站外点击 UniversalLinks,那么用户没有装 App 的话,只是会访问 m 站而已,无它;引导老用户从 H5 迁移到 App 的能力也比较弱,一直使用 m 站的用户,只有在页面顶部看到有一个入口,点击才能打开 App。原因是用户如果直接输入了 m 站的地址,在站内访问,是不会触发 UniversalLinks 的,只是会在绑定的 H5 页面顶部有一个 bar 提醒用户,点击可以跳转到 App 的相同功能,可以说是很弱的。
让我们看看怎么才能让它具备强制拉新引旧能力:
每个一级参数下的值都需要 urlencode,这边为了查看方便就不做了。
- https://app.alibaba.com/babalink?scheme=enalibaba://detail?id=123&url=https://m.alibaba.com/product?id=123
这样打开,才能跳转到目标 app,如果把链接塞到 webview 中则不会触发,请求一定会到服务端。
- [[UIApplication sharedApplication] opentURL:@"https://app.alibaba.com/babalink?scheme=enalibaba://detail?id=123&url=https://m.alibaba.com/product?id=123"]
注意这个链接的域名不是
- https://app-c.alibaba.com/babalink?scheme=enalibaba://detail?id=123&url=https://m.alibaba.com/product?id=123
,这个 h5 页面展示一个按钮,跳转链接为
- app.alibaba.com
。为什么?因为要跨域,而且点击行为在浏览器中进行是无法阻断的。
- https://app.alibaba.com/babalink?scheme=enalibaba://detail?id=123&url=https://m.alibaba.com/product?id=123
总结一下,巧用 UniversalLink 需要让服务端的这个 link 具备
来源: https://juejin.im/post/5a3678ccf265da4320035355