注: 本帖仅针对Android平台

在日常的产品运营中，友盟推送君经常能接到客户反馈“Android推送收到数变少”，一般情况下都是和之前的消息记录做对比，发现连续两条或者前后几条推送任务的统计结果有较大的变化，一般都可以从以下几个方面来分析:

1. 首先要确认消息是否已经过了有效期，如果还没有过了有效期，那么请在有效期过了之后再做对比。因为在整个消息有效期内，离线消息还是有可能不断下发的，所以统计数据是会一直增加的。 此外，我们的SDK为了保证数据的完整性，在网络不好的情况下对请求失败的日志会做缓存处理，待设备下次联网的时候再重新发送统计日志，所以日志会存在延迟发送的情况。一般情况下，等到消息过了有效期之后，数据基本已经稳定了，这个时候得到的统计数据可以认为是最终的结果。

2. 如果消息已经过了有效期，发现前后两条消息的任务在统计指标上有较大出入，那么需要确认前后两条消息的有效期设置的是否一致。这种情况比较多见，比如设置12H和24H的有效期，消息下发数以及送达App数肯定是不一样的。消息有效期越长，消息收到数会越多。

3. 在“浅谈消息推送的送达率”的帖子中，我们给大家普及过送达率的概念，当时提出过一个非常核心的点，就是消息的送达率和App自身的日活是正相关的，即App自身日活基数比较大，那么实际触达的消息也会比较多，反之亦然。 友盟推送(也是第三方推送)的作用就是利用联盟互保的优势，在App自身日活比例的基础上，进一步提升App的送达率。所以如果近一段时间内，消息的送达数有持续下降趋势的话，或者前后两次发消息间隔比较长的话，那么建议开发者需要对照自身App的日活数据看看，看是否存在App自身日活下降的趋势，如果是的话，证明活跃用户比例在减少，那么相应的，推送的送达数也会呈现一个下降的趋势。(小tip: 可以在友盟统计平台或者其它第三方统计平台来查看App自身的日活变化)。 

在实际运营中，我们碰到过不少这样的例子，举几个例子给开发者分享：

案例1: 某动漫类App反馈从9月份起，消息送达数相比8月份，逐步降低。我们协助开发者分析下来，原来是该App的群体主要是学生，7，8月份暑假期间正是该App的活跃期，9月份开学了，该App的活跃数量会有一个非常大的折损，所以消息推送收到数的趋势也跟着下来了。

案例2: 某装修类App反馈1月份起，消息送达数相比12，11月份下降了挺多。根据我们的经验，我们第一时间先让开发者查看App自身的日活是不是有明显下降，据该App反馈，过年期间，是装修市场比较冷淡的时期，用户使用频度非常低，进一步印证了消息送达率和DAU的正相关性。

案例3: 某O2O类App反馈上个月每条广播(即发送给所有人)消息的收到数一直维持在3000左右，最近一周跌倒了1000多。对照DAU趋势分析下来，原来是该电商App上个月刚上线的时候做过较大力度的推广，不过用户质量较差，基本上使用1、2次之后就不再使用了，并不是真实有效的用户。所以拉新活动一停，DAU就会出现大幅度的跌落。

4. 在case 3中提到的“送达率”文章里面，我们给大家解释过友盟推送的作用是利用App互保联盟的作用，来进一步提升App的送达率。那么联盟的作用是什么呢？ 简单地讲，假如设备上有A、B、C 3个集成了友盟推送SDK的App，那么我们可以通过技术手段，保证A、B、C这3个App中有一个打开过成为活跃App，那么就可以保证其他两个App(即使没有打开过)的消息也能借助这个打开过的App的通道做下发

但是联盟互保的技术手段目前在国内的Android厂商上(比如小米、华为)越来越受限制，厂商会基于耗电或者流量考虑，会对这种App之间的保活机制做禁用，如图例中的右图所示，这样会导致联盟的效果打折扣，进而会影响送达率以及消息收到数减少。一般来说，厂商发布新的系统，或者发布新的build号的时候，若新ROM系统或者新build号对消息互保拉活机制做了限制，那么就无法再借用联盟互保的通道来下发消息，像华为新的系统上，还会显式在系统通知栏弹出“已禁止XXX App启动XXX App”来提醒终端用户，这种情况也会导致消息的收到数变少，所以这种情况总结下来，就是厂商ROM对于消息推送SDK互保机制的限制会导致消息收到数减少，且一个不可避免的趋势是，越来越多的国内厂商采用了这种策略，所以消息的收到数以及送达率是会逐步下降的。

【延伸】: 基于case 4，我们可以把话题再延伸一下，开发者一定会问到，如果厂商ROM对这种能大幅提升消息送达率的互保机制做了限制之后，那么这些特殊机型上是否有办法保证消息的送达呢？目前在技术层面上，的确是没有办法绕过厂商的限制，并且我们作为平台服务提供商，也尊重厂商的策略。要想保证在这些特殊机型上的消息的送达率，我们建议开发者可以采用聚合的解决方案(其实已经有不少开发者采用了这个方案)，同时集成友盟SDK和厂商的SDK，服务器端在下发的时候可以做判断，如果设备机型是某个特殊厂商的，那么走厂商的通道，其它情况下，仍然走友盟的通道，这样就可以保证一个较高的整体送达率。当然友盟自身也为商业付费客户提供了这样的聚合解决方案，由友盟完全托管厂商的推送，开发者只需要对接友盟一个接入方就行，目前友盟推送提供了小米+华为的系统通道。如果开发者使用的刚好是这个聚合解决方案，消息收到数减少还有一个原因，就是可能厂商的推送系统不提供消息回执统计数据，比如华为系统目前就不提供消息回执数据，所以如果是通过华为厂商通道下发的话，这部分的消息送达量是统计不到的。

5. 最后一种情况，可能是开发者新上线的版本集成Push有问题导致的，这种情况虽然不多，但是我们的确也碰到过几次。一般表现是App的DAU看起来也正常，消息的收到数可能从App发新版本之日起，就开始逐步下降。有可能是开发者发新版的时候，集成Push SDK有问题导致的，比如把Push的初始化代码给注释掉了(可能调试阶段调试某个问题的时候注释掉的)，或者是打包的时候漏掉了推送的一些资源文件，还有一种可能性是升级Push SDK新版本的时候，没有按照新版的集成文档来升级，漏掉了一些升级点，比如混淆文件漏掉了某个类。所以如果开发者碰到的是这种情况，不妨先排查一下线上的版本推送功能是否正常，包括是否能收到推送消息，是否正常回传日志等(可以通过抓包的方法来查看)。

U-Push官网