一、需求描述
写这篇文章，也是缘于运营的一个需求：在 App 运营过程中，会有大量的推广短信，里面附有链接，目的是引导用户参与活动。如果用户手机没有安装我们的 App 就引导其去下载页，如果用户已经安装了我们的 App 就直接在 App 中打开对应的活动。
二、方案讨论
对需求进行分析，归纳起来实际上就是一个问题，如何从短信唤起App？
这里有两种方案。
第一种，也是最理想的直接从短信唤起，也就是点击短信中的链接后如果安装了 App 就跳转到 App，如果没有安装就在浏览器打开对应页面，如下图：
第二种，经浏览器中转唤起，也就是点击短信链接后先用浏览器打开对应页面，在页面中进行“判断”（实际上不是真正的判断，而是发一个scheme给系统）如果安装了 App 就跳转到 App，否则就停留在当前页。
下面将对这两种方案分别进行分析、实施。
三、从短信直接唤起 App
通常，App 监听私有短域名strange.com（不要问我为什么是短域名，因为短信就是按字算钱的，能省一分是一分）地址：
<intent-filter>
<action android:name="android.intent.action.VIEW"/>
<category android:name="android.intent.category.DEFAULT"/>
<category android:name="android.intent.category.BROWSABLE"/>
<data
android:host="strange.com"
android:pathPattern=".*"
android:scheme="https"/>
<data
android:host="strange.com"
android:pathPattern=".*"
android:scheme="http"/>
</intent-filter>
3.1、Android 系统
当点击短信中的链接后，系统会自行判断，如果安装了 App 就会出一个弹框让用户选择在 App 中打开还是在浏览器中打开，如图。
对用户来说要多做一次选择，这绝对不是好的体验。
为了解决这个问题，Android 6.0 开始支持 Deep Links，让用户点击链接直达 App。
首先，在 intent-filter 中添加 android:autoVerify="true"。
<intent-filter android:autoVerify="true">
<action android:name="android.intent.action.VIEW"/>
<category android:name="android.intent.category.DEFAULT"/>
<category android:name="android.intent.category.BROWSABLE"/>
<data
android:host="strange.com"
android:scheme="https"/>
</intent-filter>
其次，在私有域下上传一个 json 文件：
https://strange.com/.well-known/assetlinks.json
文件内容：
[
{
"relation": ["delegate_permission/common.handle_all_urls"],
"target": {
"namespace": "android_app",
"package_name": "应用ID",
"sha256_cert_fingerprints":["签名证书指纹"]
}
}
]
系统在安装应用后会自动访问 json 文件进行检验，如果检验通过，用户访问 strange.com 域名下的链接会直接跳转到应用。
3.2、iOS 系统
必须采用 Universal Links，否则点击还是直接跳转到浏览器。
从短信直接唤起 App 总结：
要实现短信直接唤起 App，Android 可以用 intent-filter 对域名进行监听，但是会出弹框让用户进行选择，为了更好的体验，建议采用 Deep Links 技术方案，只支持 6.0 以上系统；iOS 只能采用 Universal Links 技术方案，只支持 9.0 以上系统。
| 系统 | 首选方案 | 备选方案 |
|---|---|---|
| Android | Deep Links（Android 6.0+） | intent-filter |
| iOS | Universal Links（iOS 9.0+） | 无，只能跳浏览器 |
四、经浏览器中转唤起 App
上表所示，如果只能用备选方案，那么用户就有可能会首先跳转到浏览器（对应的是下载页面），经过浏览器中转，唤起 App。
通常的做法是，App 中监听 scheme strange：
<intent-filter>
<category android:name="android.intent.category.DEFAULT"/>
<category android:name="android.intent.category.BROWSABLE"/>
<action android:name="android.intent.action.VIEW"/>
<data android:scheme="strange"/>
</intent-filter>
H5 页面中内嵌：
<iframe src="strange://login" style="display: none;"></iframe>
或者执行脚本：
window.location.href="strange://login"
因为浏览器只会处理http、https协议，当浏览器打开我们的 H5 下载页面遇到不能处理的私有协议 strange，就会发 intent 给系统，如果有 App 可以处理这个协议会出弹框询问用户是否用该 App 打开，否则什么都不做，具体效果：
虽然弹框体验欠缺，不过也是目前比较好的方案了。
兼容性问题
可是，重点来了，我们在实际测试过程中发现了一堆兼容性问题，在说明这些兼容性问题前，我们先解释一个概念：intent:// 协议。
Android Chrome 25+ 后已经不支持自定义 scheme 的方式，只支持 intent:// 协议（Android Intents with Chrome），最终要的是需要用户手动进行 点击 才能跳转，举个例子：
<a href="intent://scan/#Intent;scheme=zxing;package=com.google.zxing.client.android;S.browser_fallback_url=http%3A%2F%2Fzxing.org;end"> Take a QR code </a>
<iframe href="intent://xxx" style="display: none;">></iframe>// 失效
<iframe href="strange://xxx" style="display: none;">></iframe>// 失效
intent:// 协议格式说明：
intent:
//scan/
#Intent;
package=com.google.zxing.client.android;
scheme=zxing;
end;
目前市面上大多第三方浏览器都是基于 Chrome 开发，这就带来了兼容性问题（没有条件覆盖所有的系统浏览器，这里只是有限测试的结果）：
1、部分浏览器，只支持
intent:// 协议 手动 唤起，如chrome、锤子。
2、部分浏览器只支持 scheme 唤起，如 UC 浏览器。
3、大部分浏览器，同时支持 scheme 私有协议和intent:// 协议 自动 唤起。但，都没有按标准的 intent:// 协议来实现（除了 360 浏览器，给 360 点个赞）：
- 有的浏览器在 App 没安装时并没有执行
S.browser_fallback_url，而是跳转到应用市场如猎豹浏览器 4.46.3、乐视浏览器 1.2.1.29。 - 有的浏览器不支持
S.browser_fallback_url如搜狗浏览器、欧朋浏览器、猎豹浏览器。 - 有的浏览器无论应用有无安装
S.browser_fallback_url一直都会执行如 QQ 浏览器。
所以对这部分浏览器，不能使用 intent:// 协议。
4、更奇葩者，二者都不支持，如百度浏览器。
兼容性问题解决方案
针对上述三个兼容性问题，第 4 种情况无解我们直接忽略，第 2 第 3 种情况只能用自定义 scheme 的方式。
问题出在第 1 种情况，因为只能手动唤起，我们需要对浏览器类型进行判断（浏览器没有提供是否支持自定义 scheme、intent://的 API 只能通过 UA 判断），结合我们有限的测试结果，如果是锤子、Chrome 原生浏览器，需在页面中内置一个“下载应用”的按钮引导用户点击。
// 如果安装了 App 就跳转 strange://login，否则就访问 S.browser_fallback_url 的值 http://strange.com
<a href="intent://login#Intent;scheme=strange;package=com.strange;S.browser_fallback_url=http%3A%2F%2Fstrange.com;end">跳转到活动页/下载</a>
我们来分析一下浏览器的 UA ，举几个例子：
//小米系统浏览器
User-Agent:Mozilla/5.0 (Linux; U; Android 6.0.1; zh-cn; MI 3W Build/MMB29M) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/53.0.2785.146 Mobile Safari/537.36 XiaoMi/MiuiBrowser/8.9.5
// 小米 Chrome 原生浏览器
User-Agent:Mozilla/5.0 (Linux; Android 6.0.1; MI 3W Build/MMB29M) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.108 Mobile Safari/537.36
// 锤子系统浏览器
User-Agent:Mozilla/5.0 (Linux; Android 5.1.1; YQ603 Build/LMY47V) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.11 Mobile Safari/537.36
// 锤子 Chrome 原生浏览器
User-Agent:Mozilla/5.0 (Linux; Android 5.1.1; YQ603 Build/LMY47V) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.89 Mobile Safari/537.36
可以看出小米浏览器是在 Chrome 原生浏览器的 UA 上增加了 XiaoMi/MiuiBrowser/8.9.5 这部分特征码。类似的，很多第三方浏览器都是在 Chrome 基础上增加自己的特征码，换句话说 Chrome 原生浏览器 UA 没有自己的特征。
而锤子系统浏览器和 Chrome 原生浏览器 UA 几乎一样，这就使得判断是否锤子系统浏览器、 Chrome 原生浏览器 变得异常困难，要想尽可能完美解决问题只能使用排除法。
排除法由于不可能排除所有非 Chrome 原生浏览器，可能会存在误伤的可能。
经浏览器中转唤起 App 总结：
要实现经浏览器中转 自动 唤起 App，Android 和 iOS 都可以通过 自定义 scheme 的方式，但 Android 的情况稍显复杂，因为部分浏览器并不支持，必须换成 intent:// 协议的方式 手动 唤起。
考虑到浏览器判断的难度，结合浏览器市场占有率的情况，我们最终的方案是暂时忽略 锤子系统浏览器、 Chrome 原生浏览器 这部分不支持 自定义 scheme 自动唤起 �App 的用户。
五、从短信唤起 App 最终方案
综合起来就是：
- 通过 Deep Links（iOS 则是Universal Links），可以实现点击短信链接直接唤起 App；
- 如果系统因为各种原因不支持 Deep Links，备选方案是
intent filter，不过会出弹框让用户选择用哪个 App 打开链接； - 如果用户没有选择我们的 App 而是选择了浏览器打开，则通过
自定义 scheme尝试唤起 App； - 由于技术和成本问题，我们忽略不支持
自定义 scheme的浏览器。
如下图所示：
引用
[1] Handling App Links
[2] Support Universal Links
[3] 手机 User-Agent 大全
[4] 手机浏览器 User-Agent
