从前端的角度出发 - web调起APP的

日常上图.png

日常安利自己的Github,如果有错误或者理解不正确的地方,麻烦告知我会及时更正。同时也非常欢迎大家一起讨论。鞠躬。 Github地址:https://github.com/bsxz0604/RemarkForYouDontKnowJs (不定期更新...

背景

对于APP来说,回流分享页是最好的最便宜的也是最病毒式的拉新方式。让新用户去下载APP是重要的。对老用户来说,可以直接调起APP也是提升用户体验和让用户有侵入式体验的重要手段。所以我们一起来看看有哪些方式可以唤起APP的

概念叙述

调起APP在不同平台用不同的方式,主要就分3个
* URI Scheme
* universal Link
* Android App Links
现在还是有很多第三方来协助你处理这个事情,通过接入他们的SDK和客户端代码来处理,但是万变不离其宗,所有的第三方也离不开这3种方式。

  1. URI Scheme:
    • URI Scheme 是iOS,Android平台都支持,只需要原生APP开发时注册 scheme , 用户点击到此类链接时,会自动唤醒APP,借助于 URL Router 机制,则还可以跳转至指定页面。
    • <scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]
  2. universal Link:
    • iOS9 后推出的一项功能,通用链接,对于前端即访问一个https的url,如果这个url带有你提交给开发平台的配置文件中匹配规则的内容,iOS系统会去尝试打开你的app,如果打不开,系统就会在浏览器中转向你要访问的链接。
    • universal Link 工作方式如下:
      1. 访问web link
      2. iOS访问 https://xxxxxxx/apple-app-site-association 并解析,获取文件中的信息(App的Team ID和Bundle ID)
      3. 通过Bundle ID 检查本地是否存在对应app,和检查PATH信息等,如果有app打开app,如果没有则跳转对应web link(可通过代码实现跳去app Stroe)
  3. Android App Links:
    • 在2015年的Google I/O大会上,Android M宣布了一个新特性:App Links让用户在点击一个普通web链接的时候可以打开指定APP的指定页面,前提是这个APP已经安装并且经过了验证,否则会显示一个打开确认选项的弹出框,只支持Android M以上系统。
    • 简单的说就是建立APP和某个链接的关联,避免系统在处理该类型链接时弹出选择框。弹框最常见的就是浏览器打开时的选择框。弹出选择框是应用注册了相应scheme,applinks的作用是避免在打开自己域名的链接时弹出选择(前提是注册了相应scheme),可以实现直接打开自己关联的app。

对比/优劣

vs.png
  1. URI Scheme:
    根据图片可以看到URI Scheme的兼容性是最高,在使用的过程中,会发现有很多限制:
    • 当要被唤起的app没有安装时,这个链接就会出错。在国内非常杂乱的浏览器中,会出错的现象会很多种类型。
    • 当注册有多个scheme相同的时候,目前没有办法区分。
    • 不支持从其他app中的UIWebView中跳转到目标app
      也就因为会有这些原因,apple和android都出现了自己第二套解决方案。
  2. universal Link 从链接上看来,是一个web link,所以也就解决了当没有app时,跳转也不会出现报错,所以相对Scheme优势就提现出来了.
    • 当已经安装app,不需要加载任何web页面,app就会立即启动;app没有安装,就会跳去对应的web link。
    • universal Link 是从服务器上查询是哪个app需要被打开,所以不会存在冲突问题
    • universal Link 支持从其他app中的UIWebView中跳转到目标app
    • 隐私性,提供universal Link给别的app进行app间的交流,然而对方并不能够用这个方法去检测你的app是否被安装。
      当然universal Link也不是十全十美的,缺陷也是存在的:
    • 会记住用户的选择:在用户点击了Universal link之后,iOS会去检测用户最近一次是选择了直接打开app还是打开网站。一旦用户点击了这个选项,他就会通过safiri打开你的网站。并且在之后的操作中,默认一直延续这个选择,除非用户从你的webpage上通过点击Smart App Banner上的OPEN按钮来打开。


      记住用户的选择.png
  3. app link 和 universal Link 差异不大。也是为了更好的提供调起app出现的google的方案。优点与 universal Link 差不多,缺点主要如下:
    • 国内的支持相对较差,在有的浏览器或者手机ROM中并不能链接至APP,而是在浏览器中打开了对应的链接。
    • 在询问是否用APP打开对应的链接时,如果选择了“取消”并且“记住选择”被勾上,那么下次你再次想链接至APP时就不会有任何反应
app_link记住用户的选择.png

无论哪一种方式目前都没有解决几个问题:

  • 如果设备上没有安装这个app的时候,安装完毕后,无法保留住此时用户停留的上下文。
  • 因为web没有办法监听到APP是否安装,所以都需要通过一些手段来兼容调起app或者是去下载页

使用 & 需要注意的内容

  1. URI Scheme:
    • 使用: 这种方式是当期使用最广泛,也是最简单的,但是需要手机,APP支持 URI Scheme 。
    • 需要注意的内容 & 遇到的问题:
      其实使用URI Scheme 部分前端没有太多可以排查的问题,会遇到的问题主要是两个部分。1. 在android的兼容性处理(国内的浏览器无力吐槽ing),2. 当没有安装app的情况,URI Scheme 会有各种报错,也需要处理…
<!-- 唤醒APP并跳转至指定的path页面 -->
<a href="<scheme>://<path>?<params>=<value>">打开APP</a>

<!-- JS设置iframe src跳转至指定的path页面 -->
//创建一个隐藏的iframe
var ifr = document.createElement('iframe');
ifr.src = '<scheme>://<path>?<params>=<value>';
ifr.style.display = 'none';
document.body.appendChild(ifr);
//记录唤醒时间
var openTime = +new Date();
window.setTimeout(function(){
    document.body.removeChild(ifr);
    //如果setTimeout 回调超过2500ms,则弹出下载
    if( (+new Date()) - openTime > 2500 ){
        window.location = '指定的下载页面';
    }
},2000)
  1. universal Link & app Links
    • 使用:对于有app的用户,只是打开一个连接,但是需要注意的是需要考虑到没有APP的用户。(个人的解决方案:针对域名来判断,当域名为特定的universal Link 的域名,则跳转去下载页面)
    • 需要注意的内容 & 遇到的问题:
      1. apple-app-site-association 和 assetlinks.json 的配置
      2. 需要保证使用的链接跨域(universal Link)
      3. 直接将universal Link 贴入浏览器的url中不会生效
      4. window.onload 或者用户没有任何事件触发的情况下,universal Link也不会生效

两大平台的特殊处理(facebook & twitter)

facebook 和 twitter 作为国外的两大信息聚合平台,对于在他们app中调起app也有自己的一套方式。
根据要求通过添加META头来处理打开APP
facebook:

<meta property="fb:app_id" content="xxxxxx" />
<meta property="og:type" content="xxxx"/>
<meta property="og:title" content="xxx" />
<meta property="al:ios:url" content="{{ uri scheme }}" />
<meta property="al:android:url" content="{{ uri scheme }}" />
<meta property="al:ios:app_store_id" content="{{app_store_id}}" />
<meta property="al:ios:app_name" content="{{xxx}}" />
<meta property="al:android:app_name" content="{{xxx}}" />
<meta property="al:android:package" content="{{android:package}}" />

twitter:

<meta name="twitter:card" content="app" />
<meta name="twitter:site" content="xxxxx" />
<meta name="twitter:title" content="xxxxx" />
<meta name="twitter:description" content="xxxxxxx" />
<meta name="twitter:image" content="xxxx" />
<meta name="twitter:app:name:iphone" content="xxx">
<meta name="twitter:app:id:iphone" content="xxx">
<meta name="twitter:app:url:iphone" content="{{Scheme}}">
<meta name="twitter:app:name:ipad" content="xxx">
<meta name="twitter:app:id:ipad" content="xxx">
<meta name="twitter:app:url:ipad" content="{{Scheme}}">
<meta name="twitter:app:name:googleplay" content="xxx">
<meta name="twitter:app:id:googleplay" content="xxx">
<meta name="twitter:app:url:googleplay" content="{{Scheme}}">

使用 checkList(前端)

  1. scheme

    • iOS 和 android 是否已经支持 此scheme
    • js处理兼容代码
  2. universal Link (apple-app-site-association 官方文档)

    • HTTPS的域名
    • iOS9 以上
    • universal Link 是否跨域
    • universal Link的落地页是否是下载页面
    • apple-app-site-association 配置在 host的根目录和.well-known下
    • apple-app-site-association会在第一次打开app或者更新app时候会去拉去,所以确认是否更新了apple-app-site-association后没有更新过app
    • 检查apple-app-site-association paths 大小写敏感 支持通配符
    • 该设备的用户选择了直接打开app还是打开网站,如果选择打开网站,需要通过smart banner 重新启用
    • 跳转处理是否是在用户事件中触发,而不是进入页面后直接触发
  3. app links (android app links官方文档)

    • HTTPS的域名
    • 跳转后的落地页是否是下载页面
    • assetlinks.json 配置在 host的.well-known下
  4. facebook (facebook app link官方文档)

    • 将需要的meta头信息填充完毕
    • 检测链接 分享调试器 - Facebook for Developers , 确认分享链接中获取到了所需要的meta头
    • 分享过的链接会有缓存,在检测中清楚缓存
    • 如果web和wap链接一致,确认在web中也添加了相同的meta头,facebook会默认从web中获取
  5. twitter (Twitter app card官方文档)

    • 将需要的meta头信息填充完毕
    • 检测链接 Twitter app card 检测
    • 如果web和wap链接一致,确认在web中也添加了相同的meta头,facebook会默认从web中获取

链接

  1. webview如何屏蔽universal Link
  2. apple-app-site-association 官方文档
  3. apple-app-site-association 检测
  4. android app links官方文档
  5. android app links检测
  6. facebook app link官方文档
  7. 分享调试器 - Facebook for Developers
  8. Twitter app card官方文档
  9. Twitter app card 检测

之前写的文章大家感兴趣的话,也可以阅读了解讨论:
HTTP协议浅谈
Javascript作用域和闭包
Performance — 带你监控前端性能

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 206,214评论 6 481
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 88,307评论 2 382
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 152,543评论 0 341
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 55,221评论 1 279
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 64,224评论 5 371
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,007评论 1 284
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,313评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,956评论 0 259
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,441评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,925评论 2 323
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,018评论 1 333
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,685评论 4 322
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,234评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,240评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,464评论 1 261
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,467评论 2 352
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,762评论 2 345

推荐阅读更多精彩内容