前言

在我们做社区app的时候，是需要区分Android与iOS端的，相应的我们会开发两个app，最终生成两个下载地址供用户使用。

那么问题就来了，产品会提到可不可以简化操作，用一个下载地址去解决呢？

这就是今天我要写的东西。

方案

在产品提出这个需求之后，我就对其进行了调研及测试。

这个方案是其它同类产品所使用的。

其基本原理就是通过url请求头里面的User-Agent去判断当前访问设备的机型。

Mozilla/5.0 (Linux; Android 11; Pixel 5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.91 Mobile Safari/537.36

Mozilla/5.0 (iPhone; CPU iPhone OS 13_2_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.3 Mobile/15E148 Safari/604.1

上面两个User-Agent分别是安卓与苹果的，服务端在接收到网页请求的时候可以轻松判断出请求设备机型。

在响应的时候Status Code返回302，告知浏览器需要重定向,并且在响应头的location附带上新的url，而这个新的url就是服务端通过用户设备类型给予的不同下载地址，这样就可以实现上述需求了。

到此为止，我们的基本需求是实现了：一个二维码兼容两种下载

但其实这套方案不是很完美，那就是无法保证已安装的用户直接唤醒app，而是会二次下载，这个体验非常差。

为了更进一步完善步骤，我尝试了以下方案；

把下载地址指向universal link；
如果是ios，那么访问这个地址就会直接打开app store，并且已安装的用户可以直接唤醒app；
如果是Android，访问这个地址后universal link并不会生效，那么我们可以直接通过url scheme去唤醒安卓app，并且后续通过相关函数去判断是否唤醒成功，如果唤醒失败代表用户没有安装app，那么我们接下来就可以自动调用函数打开安卓app的下载地址；

在经过实践后，发现方案走不通，问题出在安卓本身机制。

在安卓环境下面，网页无法静默唤醒app，必须要用户交互去触发，所以安卓打开我的网页后需要多一步手动操作。

但相应的也有优点，那就是安卓用户点击下载的时候会去判断他是否安装，如果已经安装会直接打开应用。

并且这个方案可以修改一下：做成安卓打开后自动触发下载，页面保留一个唤醒app的入口。

相对于iOS封闭的环境，Android开源的环境导致了方案不统一。

如果只是为了统一下载二维码，那么上面的方案就可以见到解决。

至于后面的方案，仁者见仁智者见智。