Question

Android有一个比iOS好的地方，就是可以随时发版，发现问题后立刻修复立刻发新版。至少很多书上都是这么说的。

但我从事无线领域这几年的经验告诉我，实际情况并非如此。频繁发版会导致用户要频繁更新，他们会认为这家公司是不是要倒闭了？怎么一周内接二连三发hotfix版本？所以每次发现线上bug，我们都会很谨慎的评估，是否一定要发hotfix版本。不同行业发hotfix版本的衡量标准是不一样的：

·电商类公司，他们会很在乎订单数和订单转化率，所以一定要确保支付主流程能走通，同时，对于一切影响生意的UI展示问题都很在意，比如票券的有效期会误导用户，比如酒店的好评率如果不展示将直接影响订单的转化率。

·社交类公司，他们会很在乎各个页面的广告是否能正确投放，因为这类公司就是靠收取其他公司的广告费来盈利的。另外，他们比较关心PV和UV，因为不同页面上的广告费用是不一样的，PV和UV高的页面，广告费用也高，比如首页。

·推送，更是一个重中之重的功能。尤其是个性化推送，能在公司和用户之间建立很好的互动。如果推送功能坏了，是必须要紧急发版的。

·地图定位，对所有公司都很重要，所以使用一款好的SDK至关重要，我们最关心的是地图SDK的稳定性和性能，还有准确性。我一天到晚接到全国各地销售部门的投诉，说某某定位错了，导致客人找不到具体地方，直接影响生意。

每次紧急发版都会把所有200多个渠道包全都打一遍，就算是自动化批量打包，每个包需要5分钟，也要等服务器运行将近一天时间 ^[1] 。然后由推广人员执行以下操作：

·一部分apk包手动上传到各大市场，有些是立即生效，有些则需要Android市场那边审核，如果是周末对方不上班，还要打电话请人家帮忙加速审核。

·一部分apk分发给Android市场的市场人员，由他们帮忙上传。

·一部分apk放到公司的服务器，然后更新所有HTML5短链的地址。

每次Hotfix发版，都会这么折腾一遍，所有涉及的人都苦不堪言。经历了几次Hotfix后，我就开始在想如何提前发现App的这些严重问题。

我们先尝试使用Google Play，每次发版前一两天都提前发布到Google Play的灰度环境，设置为50%，也就是说每两个用户就有一个用户能使用到新版本。我们原本以为这样就能收到用户的反馈了，但是我们试了几次后，发现这种方法不可行，因为在中国，Google Play的用户很少，每天100多用户，所以收不到任何反馈，也看不到新版本发生Crash发送到后台服务器的异常日志。

既然Google Play行不通，因为用户少，那我们就在想，能否在用户量比较大的渠道上提前几天发布我们的测试版本？

我们发现，网站首页上的主渠道，用户量比较大，每天大约有1000的新用户激活，所以我们尝试将主渠道上的包提前一周替换为测试版本，我们称这个测试版本为小流量包。

小流量包的版本号仍然是当前线上的版本号。比如说，线上版本是6.0，过几天要发新版本6.1，在这期间我要在主渠道发布一个小流量包，版本号只能是6.0，而不能是6.1，否则第二天你就会发现各个渠道上的App都升级为6.1版本了，渠道商之间的竞争很激烈，他们会尽量保证每个App都是最新的版本，从而获得更多的下载量。但这样一来，小流量包就失去了原先的意义，相当于提前发版上线了，所以版本号一定不能变，仍然是6.0，就不会被抓包了。

那么如何区分线上版本和小流量包呢？比如说激活数、下单数、转化率，甚至是线上Crash数据，因为版本号一样，都会混在一起。我的经验是申请一个新的渠道号，比如我今天要发布小流量包，那么我就找财务申请20140802这个新渠道，这样在后台就能看到渠道号为20140802的Crash信息了。到时候只要在计算每日激活量时，把这个渠道产生的激活划归到主渠道就是了。

小流量包的版本号不变，使得只有新用户才能下载到小流量包，老版本的用户，因为版本号一致，所以不会进行更新。这样就避免了频繁升级App版本对用户造成的麻烦。

[1] 有一种超快速打渠道包的机制，请参见本书9.9.3节。