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

对比/优劣

会记住用户的选择：在用户点击了Universal link之后，iOS会去检测用户最近一次是选择了直接打开app还是打开网站。一旦用户点击了这个选项，他就会通过safiri打开你的网站。并且在之后的操作中，默认一直延续这个选择，除非用户从你的webpage上通过点击Smart App Banner上的OPEN按钮来打开。

在询问是否用APP打开对应的链接时，如果选择了“取消”并且“记住选择”被勾上，那么下次你再次想链接至APP时就不会有任何反应

无论哪一种方式目前都没有解决几个问题： * 如果设备上没有安装这个app的时候，安装完毕后，无法保留住此时用户停留的上下文。 * 因为web没有办法监听到APP是否安装，所以都需要通过一些手段来兼容调起app或者是去下载页

使用 & 需要注意的内容

需要注意的内容 & 遇到的问题： 其实使用URI Scheme 部分前端没有太多可以排查的问题，会遇到的问题主要是两个部分。1. 在android的兼容性处理（国内的浏览器无力吐槽ing），2. 当没有安装app的情况，URI Scheme 会有各种报错，也需要处理…

两大平台的特殊处理(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(前端)

链接

Twitter app card 检测

原文发布时间为：2018-09-9

本文来自云栖社区合作伙伴“前端大学”，了解相关信息可以关注“前端大学”。