APP消息推送方案调研

1. 背景

目前行业内有多家消息推送服务供应商，且各家都宣称自家产品的核心指标行业领先。为了不被各家推送厂商忽悠，量化消息推送到达率效果，我们需要整理设计一套消息推送服务对比量化方案，一切以线上实测数据为准，通过线上到达率数据进行效果评判。

当前很多推送服务商宣称自家产品的到达率在90%以上，其实这是厂商玩了一个模糊概念的把戏。厂商所指的到达率是在线到达率，即应用在线，有长连接情况下消息送达的比率，但我们其实更关注“无论应用是否开启的情况下，App整体的消息送达率情况”。

2. 厂商选择

2.1 个推

个推目前来说算是业内市场占有率的领头羊，积累了一批标杆客户。不过实际上也并没有看上去这么美好。个推官网一直将新浪微博放在显眼位置作为标杆客户展示，但反编译微博APK发现并没有集成个推的服务。考虑到它的占有率，作为第一个评测对象。

2.1 极光推送

极光也是推送领域较早的厂商，不过从放出来的文档和社区里的口碑看似乎不是很理想，考虑到他家的占有率也比较高，作为我们的第二个测试对象。

3.3 阿里推送

阿里推送是最近看知乎发现的，主要的优点是背靠阿里这颗大树，像手淘、支付宝等一类大的App的消息转发能提升到达率，所以这里也作为评测对象.

其他的厂商如信鸽、百度云推送大家也可以纳入评测范围，而比如小米、华为这类厂商，主要是针对自己的机型提供的推送通道，不少推送厂商已经做了集成，比如阿里推送就有辅助通道的概念，可以集成小米、华为推送，这里就不作为单独的推送厂商进行评测了。

3. 对比方案

方案的核心思想虽然简单，不过怎么对比还是有讲究的，如果对比策略没有全盘考虑到各种场景以及各家SDK之间的相互影响，测试数据的真实性和客观性就会大打折扣。

所以，在踩过很多坑后，我们终于总结出了两套可行的对比策略:分时测试和分组测试。

3.1 分时测试

同时集成多家推送，在一个测试周期（如一周）内只测试一款推送产品（各家SDK为提升到达率均作了进程保活工作，另外推送会尝试唤醒进程，导致先后测试的不同厂商的推送效果数据被污染，所以不能在同一测试周期内同时测试不同推送服务），终端和服务端在不同推送周期间动态切换推送通道，测试架构可参考下图：

3.2 分组测试

同时集成多家推送产品，将线上终端进行分组（每个厂商对应一个分组，确保分组的终端总量基本一致），不同组别的终端连接不同推送服务。同一测试时间点向各个分组进行消息推送，比较各组推送到达率。测试架构可参考下图:

3.3 分时测试示例

3.3.1 制定测试周期

以个推，极光推送，阿里推送为例，可以以一周为测试周期进行测试，即第一周测试个推，第二周测试极光推送，第三周测试阿里推送。

关键点：
- 单一测试周期内终端只开启单个