产品日常——动手写个App下载浮层

http://www.mindtheproduct.com/2011/10/what-exactly-is-a-product-manager/

我不生产代码，我只是代码的搬运工。

为了增强工具型App的运营能力，我们在上个版本加强了产品的内容功能。由运营的同学每天筛选、编辑一些高质量的用车文章或交通信息推送给用户。上线运营一段时间后发现，虽然文章List的整体位置处于首页中下屏，部分小屏机型（如iPhone4s、iPhone5）甚至需要滑屏才能看到，但PV还是很可观的。页面的分享率(分享次数/PV)，在1%~2%左右。虽然不是很高，但是考虑到近期App的推广预算缩水，我想在分享的文章页上加一个推广浮层，顺便带一点下载。

由于这个想法不算正式需求，而且效果无法评估（其实是没啥底气，1%的分享率再去带下载效果不会很好，但聊胜于无啊），所以就准备自己来搞了。

实现逻辑很简单，对用户浏览的文章页面判断：

1. 是否在App的Web View中
2. 如果是，则不显示下载浮层
3. 如果不是，则在顶部显示一个下载浮层
4. 用户点击浮层，下载安装包

第一步，首先判断用户是在App中浏览文章，还是通过分享的链接打开的。方法就是对当前浏览器（广义）的UA（[User Agent](User Agent)）做标识符匹配。因为，为了便于后台的统计分析，开发者一般会修改默认的UA，添加一些自定义的标记（比如，比如UA+版本号、项目名称等）。我们通过正则表达式来匹配这些特殊标记，就可以判断出来是不是自己人。

Talk is cheap show me the code.

第一段HTML代码在文章页中插入了一张浮层图片，点击时触发event执行第二段的JS去下载安装包；第三段的JS来完成判断——是否是在App中打开文章页，并且控制浮层图片置顶显示。

最后，测试效果如下图。

iOS上显示效果：上图为App中浏览，下图为微信中浏览

本来到这里就应该结束了，我可以满怀期待地等待后台统计结果。谁知道打开Android测试机一看，App中的文章居然也带着下载浮层 ！天了噜，为什么第2个JS中的判断代码在Android机上失效了？

一问Android的工程湿才知道，他当初并没有单独为这个Web View设置自定义UA！当我默默地把这条"bug"提交jira后，陷入了沉思···

由于没有HotFix，下次发版之前这个bug是解决不了了。那么现在，我只能增加一项判断来屏蔽掉所有的Android用户了。想到我们的Android用户要比iOS用户多几倍，我眼泪就流下来···

在网上搜了下如何通过UA来判断苹果系统，将上面的第二个JS修改如下：

好了，现在Android用户不会在App中看到奇怪的下载提示了（通过isiOS判断后，只有iOS的用户可以看到这条下载浮层）。但是，一下子减少了70%的用户，求心理阴影面积。

注：以上代码的部分变量名和url做了替换，仅作参考示例。