Web 移动应用任重而道远

在前东家接手的最后一个项目是天猫 H5 向 Tmall App 引流, 其中涉及到 URL Scheme 技术, 以及各种入口的来源统计，结算及个性化展示等。

碰巧的是，携程国际这边接手的第一个 Page Landing 项目基本需求和早前的引流项目不谋而合。

好好的 H5 不用，为啥要导流到 App ？ 要啥自行车？？？？

可现实就是：移动端 APP 化已是大势所趋了，用户的习惯已然被培养了起来。一旦 native 开发能解决发版迭代不够灵活迅速的问题，那 Web App 真的就亚历山大。。。

不是还留有余地么？ 比如：Hybrid？ 呵呵哒～

跑题了 =,=

关于 URL Scheme

科普请戳：这里

对于一个正确的 URL Scheme，我们在网页中完全可以按照一般的超链接来使用，比如放在<a> 标签的 href 属性中，用户可以通过点击按钮或者超链接唤起 APP。

然而到了 JS 控制主动唤起 APP 这里，就出现了很多浏览器的兼容问题。。。

先来一段抄来的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
var UA = navigator.userAgent;
var IS_IPAD = UA.match(/iPad/i) != null,
    IS_IPHONE = !IS_IPAD && ((UA.match(/iPhone/i) != null) || (UA.match(/iPod/i) != null)),
    IS_IOS = IS_IPAD || IS_IPHONE,
    IS_ANDROID = !IS_IOS && UA.match(/android/i) != null,
    IS_MOBILE = IS_IOS || IS_ANDROID;
function open() {
     // If it's not an universal app, use IS_IPAD or IS_IPHONE
     if (IS_IOS) {
       window.location = "myapp://view?id=123";
       setTimeout(function() {
           // If the user is still here, open the App Store
           if (!document.webkitHidden) {
               // Replace the Apple ID following '/id'
               window.location = 'http://itunes.apple.com/app/id1234567';
           }
       }, 25);
     } else if (IS_ANDROID) {
       // Instead of using the actual URL scheme, use 'intent://' for better UX
       window.location = 'intent://view?id=123#Intent;package=my.app.id;scheme=myapp;launchFlags=268435456;end;';
     }
   }

如上所示。

这样的代码，我保证你多浏览器调试会碰一鼻子灰。

数一数踩过的坑

歪果仁踩的的坑也是满满的：传送门(可能需要翻墙)

1. Android Chrome

Chrome 不必多说，当之无愧是自动唤起失败率最高的浏览器。

Google 的官方文档如是解释：android intents。不得不说这个世界上最好的互联网公司其说词也是逼格满满的。但是好好的 URL Scheme 你不姿持，搞出来个 Intents 做啥子？

找客户端同学支持 intent 协议么？？？ 求人不如求己。

试一试无痕请求大法：

1
2
3
4
5
var ifr = document.createElement('iframe');
	ifr.style.display = 'none';
	ifr.src = "myapp://view?id=123";
document.body.appendChild(ifr);

在 Android Chrome 调试如下：

啊哈
是的，

你没看错，

被屏蔽了。。。

老生常谈的唤起方式:

window.location = 'myapp://view?id=123

同样请求状态为 ‘canceled’

打开一个新窗口怎么样？

window.open('myapp://view?id=123','_blank');

居然成功了。。。

但是紧接着就发现只能成功一次，也就是安装 Chrome 的第一次请求会成功,其后每次都只会打开一个空白页。

那就控制第一次发请求，以后都不发了吧。。。

2. IOS Chrome 一个极其隐蔽的问题

window.location = 'myapp://view?id=123

上述代码在页面进行非跨域的异步请求时千万别调用！！！！！！！！

在 IOS Chrome 下你会死得很难看。。。别问我怎么知道的～ 烦

反正同域的异步请求都完成了你再调用就没问题。

BTW，IOS Chrome 的 UA 真的亮了：

iOS / Chrome 34: Mozilla/5.0 (iPad; CPU OS 7_0_4 like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) CriOS/34.0.1847.18 Mobile/11B554a Safari/9537.53

CriOS …

3. IOS9+ safari

据说最好的打开方式是在<head>中添加：

1
<meta name="apple-itunes-app" content="app-id=1234567, app-argument=myapp://view?id=123"/>

效果：

可是宝宝要自动唤起啊。。。你让我点击我不愿意啊。。。。

T_T

亲测前文中无痕请求方式在低版本的 IOS Safari OK, but IOS9 以上不行。

And, window.location 方式，在 IOS9 以上会有一个原生的提示弹框：‘是否打开 XXX 中的链接？’，点击是则唤起正常。

Over ~