IOS9以上版本新增了通用链接的功能。最近在项目中正好有用到,并在开发过程中遇到了很多坑。因此对其进行总结,以供大家参考,如有疏漏,求留言指证~~

应用场景

在WAP页面中点击某个按钮。

  • 用户装了APP,直接打开APP对应页面;
  • 没有装APP,跳转到WAP下载页;

URL Scheme实现方案

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
var iframe = document.createElement('iframe');
iframe.style.display = 'none';
document.body.appendChild(iframe);

if(userAgent.match(/(iPhone|iPod|iPad);?/i)){
//抛出schemes,打开app对应页面
window.location.href = "apps custom url schemes";

//由于部分ios中打开app后,WAP页面会被挂起,定时器不会被执行。因此可以做下优化:
//WAP页重新被聚焦后,如果超过1s,认为APP被打开了,重新聚焦时就不必再跳转到APP下载页
var loadDateTime = Date.now();
window.setTimeout(function () {
var timeOutDateTime = Date.now();
if (timeOutDateTime - loadDateTime < 1000) {
window.location.href = "app下载页面";
}
}, 25);
}else{
//抛出schemes,打开app对应页面
iframe.src = "apps custom url schemes"

//跳转下载页
setTimeout(function () {
window.location.href = "app下载页面";
}, 500);
}

以上代码原理是:

  • 如果安装了APP,抛出的URL Scheme可以被app解析,则打开该APP,并由APP跳转到对应的页面;
  • 如果未安装APP,没有应用程序可以解析该协议,则在500ms以内执行定时器里的函数,打开WAP端的下载页面。

apps custom url schemes是什么

apps custom url schemes 是WAP端和APP端约定好的一个协议URL,如:web2app://。和正常的URL一样,除了protocol部分外,也可以有host、path及参数,如:web2app://openapp?type=1&id=12。具体要看各端约定,不过个人建议最好还是按照URL的组成规范来定义scheme,不然会引入由于URL不规范而导致的各种编码问题。

首先在,APP里会配置好预定好的URL Scheme协议,

1
2
3
4
5
6
<intent-filter >
<action android:name="android.intent.action.VIEW"/>
<category android:name="android.intent.category.DEFAULT"/>
<!-- scheme的Uri的协议必须跟此值相同-->
<data android:scheme="web2app"/>
</intent-filter>

每当WAP页打开协议URL,系统便会打开该APP,然后根据URL协议后面的部分,执行后续逻辑(比如打开WAP页对应的APP页面)。

URL Scheme存在的问题

  • IOS9.0以上弹确认框的问题。

    在IOS9.0以上版本中,WAP端打开协议URL,如果已安装APP,会弹出如下图所示的确认框。




    大部分情况下,用户点击“打开”APP之前,页面直接刷新跳转到WAP下载页,导致打开APP失败。这就是IOS9.0以上不能用scheme实现需求的主要原因。如果手机上未安装APP,WAP端打开协议URL,会弹出无效URL的弹窗,也会影响用户体验。

  • 跳转下载页问题。

    由于跳转到下载页由前端定时器触发,在所有的andriod机以及部分IOS机器上,打开APP后,WAP页还是会被定时跳转到下载页。

通用链接实现方案

在IOS9.0以上开始支持通用链接,接下来详细解析一下用通用链接实现该功能的方案。

apple-app-site-association文件

apple-app-site-association是IOS中一个JSON格式的“通用链接”配置文件,在其paths键中设置通用链接的具体规则。

1
2
3
4
5
6
7
8
9
10
11
{
"applinks": {
"apps": [],
"details": [
{
"appID": "...",
"paths": ["/open/*"]
}
]
}
}

IOS端,在Xcode的capabilities里添加域名(b.com,为通用链接的域名)。这样在第一次启动APP时,APP会从 https://b.com/apple-app-site-association 下载这个配置文件并交由IOS系统管理。该配置文件必须通过SSL的方式请求,所以,b.com必须支持SSL访问。



实现原理

用通用链接实现的原理如下图所示。在服务器a.com上部署WAP页以及APP下载页,在b.com上署“后端重定向服务”以及“ios通用链接的配置文件”。



当WAP页打开如下通用链接时:http://b.com/open/…, 如果已经安装了APP,且该链接和APP在apple-app-site-association中配置的规则一致,则打开该APP,并由APP进行后续处理(打开应用内的某个页面);如果ios上没有安装APP,则系统不会对该链接进行特殊处理,直接在浏览器中打开,后端的重定向服务会将该链接重定向到下载页“http://a.com/mobile/app”, 代码如下:

1
2
3
if(navigator.userAgent.match(/OS 9_\d[_\d]* like Mac OS X/i)){
location.href = "universal link";
}

几个坑

  1. WAP页面的域(a.com)和抛出的通用链接的域(b.com)必须不一样。如果同域,抛出的通用链接在很多情况下会被系统忽略,就算已安装APP,也打不开并且直接重定向到下载页。(至少在IOS9.*的版本中遇到了这个问题)。

  2. 通用链接在微信webview中的BUG。
    微信webview中打开WAP页,该WAP页通过设置loaction.href抛出通用链接打开APP。之后从APP重新返回到该webview页面,并用微信进行分享。

    • 期待结果:分享出在webview中展示的WAP页。
    • 实际结果:发现最终分享出去的是APP下载页。
    • 原因分析:虽然在装了APP的情况下,不会在webview中打开该通用链接刷新到下载页,但是location.href这个全局变量已被更改,微信的默认分享的链接是location.href所指链接。该BUG的具体原因及解决方案将在以后的文章中进行详细分析。