阅读 3831
浏览器中唤起native app || 跳转到应用商城下载(二) 之universal links

浏览器中唤起native app || 跳转到应用商城下载(二) 之universal links

上一篇文章

在ios9出来以后,我们发现越来越多的应用能够直接绕过微信的屏蔽,从其内置浏览器中直接唤起app。相比于通过弹窗提示让用户到浏览器中操作的方式,这无疑是极大的提高了用户体验与流量导入。因此,在ios上实现直接从微信中唤起app变得非常必要。

而其中的关键,就在于通用链接universal links:一种能够方便通过传统HTTP链接来启动app的方式,可以通过相同的网址打开网站和app。

对于ios开发者来说,可以很轻松在网上找到非常多给自己的app配置universal links的教程文章,这里推荐 www.cocoachina.com/ios/2015090…

这篇文章的主要目的,就是从前端角度来聊一聊universal links的运用。

无论是Android还是ios应用,都能够通过一定的方式捕获浏览器正在进行的url跳转。我们知道在页面中通常有如下三种方式能够访问别的链接

  • 通过html中的a标签
    <a href="universal links">action</a>复制代码
  • 通过js的location方法

    window.location = 'universal links';复制代码
  • 通过iframe标签,一般情况下我们会通过js创建一个iframe标签,并通过设置iframe的src属性实现跳转

    var iframe = document.createElement('iframe');
    iframe.style.cssText = 'width: 0; height: 0';
    document.body.appendChild(iframe);
    iframe.src = 'universal links';复制代码

为了能够在js中控制跳转行为,我们基本不会通过a标签的方式,而选择2,3种。不过比较头疼的是,并不是所有手机版本的浏览器都能够毫无顾忌的使用这两种方式,比如在ios8中,据说他们ios开发通过通常使用的方式,无法捕获window.location的跳转,因此我们得采用iframe的方式来实现唤起。而在Android上浏览器的表现就更加杂乱不一,因此如果想要兼顾所有的浏览器,从测试角度来说,这是一个比较大的工作量。

而universal links如果能够实现从微信中直接唤起app,那么微信以外的浏览器的复杂场景我们都不需要考虑了。因此这简直就是一件利国利民的好事,从开发到测试的工作量都大大降低。

读过上一篇文章的同学应该知道,单单从浏览器层面,我们无法精准的判断本地是否安装了app。这给我们实现这一需求造成了非常多的困扰。而从ios9.2开始,针对universal links,有一个非常重要的改动,通俗来说,就是必须通过访问不同的url链接,我们才能在微信中唤起本地app

在上面我们介绍过,universal links能够使用和访问普通网页一样的http链接,唤起我们自己的app。比如我们访问一个页面http://www.test.com/gold能够在浏览器中打开一个页面,而当我们在手机浏览器中,通过上面的三种方式尝试访问同样的地址http://www.test.com/gold,只要本地安装了指定的app,就可以打开app中的对应页面。但是9.2的改动之后就不行了,在9.2之后,我们必须使用2个不同的域名,并且这2个域名指向同一个页面,我们才能够在微信中唤起app。

如果我们仅仅只是配置了一个域名,那么当我们在微信中打开这个网页,并且在页面中访问自身时,页面仅仅相当于一次刷新,而app并不会被唤起。而点击在浏览器中打开时,会唤起app。

对于不了解的人来说,这是一个深坑,而当我们了解了其中的细节,那么我们就能够利用这一点,完美的实现有则唤起,无则下载的需求。

假如我们有一个app,demoAPP。我们的ios同事已经配置好了universal links,2个域名分别为a.com, b.com。另外我们有一个宣传页面,在浏览器中,a.com/activityb.com/activity都能够访问该宣传页面。

为了规范统一,我们规定将该宣传页面从demoAPP分享出来时,页面地址使用a.com/activity,而在当我们想要唤起demoAPP时,使用b.com/activity.

另外,在实践中我发现如下特性,如果本地安装了demoAPP,那么a.com/activity中唤起app之后,不会发生任何变化。而如果本地没有安装demoAPP,页面会跳转到b.com/activity,当到了这个页面,我们已经知道无法唤起,因此直接下载即可。

因此根据这个特性,我们有了如下的实践方案

var openURL = {
    open: 'b.com/activity',
    down: 'downloadurl'
},
// 打开app的按钮
btn = document.querySelector('.open-app'),
curURL = window.location.href;
if (/b.com/ig.test(curURL)) {
    window.location = openURL.down;
    return;
}

btn.onclick(function() {
    window.location = 'b.com/activity';
})复制代码

是不是很简单!

当然在具体实现上,还有许多繁琐的细枝末节需要我们一步一步去完善。这里只是提供了一个思路。从整体来说,这个需求并不是一个简单的任务,我们需要后端同学配置2套域名,需要ios同事配合,甚至还需要和产品不停的沟通,因为有一些确实无法实现的东西需要他们理解。

第三方

老实说,如果自己劳心劳力想要比较完善的实现这么个需求,真的吃力不讨好,需要配合的部门太多,耗时太多,最后的效果还并不是很好,很多用户还对这种弹窗下载提示真的深恶痛绝。因此,通过第三方的解决方案无疑是最好的办法。

这里推荐2个第三方方案,具体的优势,实现与配置方式在他们网站中都有详细的讲解,如果真的有接到这个需求的同学,强烈建议参考。当然,如果有数据隐私这方面的考虑的话,就还是自己老老实实的做兼容吧,反正方案就是这2篇文章说的这些。

磨窗 www.magicwindow.cn/

deepshare deepshare.io/redirect-on…

我知道有的同学会想吐槽,说了这么多,原来还是第三方才是最佳方案,干嘛不直接说得了!那么我只能说,这么想的同学,肯定不知道经验这个东西,在撕b上到底有多重要!!

最后!公众号求一波关注!!!!搜索isreact可以找到我

文章分类
前端
文章标签