新手开发，把自己开发时候遇到的一个简单 但是比较有意义的问题分享一下。
大致问题就是，服务器使用了google的fcm推送，但是在firebase的控制台看到的图标显示Received数量很低，低到什么程度。一天推送5W条通知的话 ，只有300-400条能Received 并展示。
发现问题之后就要分析问题：按照正常的推送逻辑来理解：服务器拿用户的fcm_token发送请求到firebase服务器没有抛异常算是send成功 send+1,这个时候服务端的任务其实已经完成。
后续的话则是由firebase服务器根据fcm_token去找到对应的用户设备，并将消息推送到对应的设备，这个时候是算一次Received 。这部分则是完全由firebase去控制。
之后则是用户的设备根据系统的省电策略，保活策略，网络环境决定这个推送通知要不要进行展示如果展示了，则记为一次Impressions。
之后则是用户看到通知并点击通知记为一次Open count。
问题恰恰出现在了firebase到用户设备这条链路，因为这条链路我们不能控制 所以只能去间接分析原因，比如设置推送等级为HIGH，修改TTL为2小时。但是都没有效果。
期间也加了埋点日志去统计用户的点击率，结果发现 我们根据埋点统计到的点击率甚至比firebase控制台显示的展示率还要高。出于对google的绝对信任，当时看到这个数据的第一反应就是埋点上报或者统计是不是有问题。
不过后续排查也证实了 埋点没有问题，问题确实出现在了firebase的图表上。
转折点是biggroup功能的开启，这个开启后会记录所有fcm推送的状态。开启后在biggroup查询发现，send 5W 有3.6W条通知是MESSAGE_DELIVERED 类型 翻译一下也是送达。看到这个数据的瞬间就清醒了，推送本身没问题，是firebase的数据统计有问题，或者说是对firebase的数据指标理解有误导致的。
firebase控制台的Received 虽然可以理解为送达，但是这个送达指标的统计方式是在通知到达用户设备时，SDK能触发回调到firebase服务器，此时才统计为1此Received。但是因为大部分设备可能处在后台 或者系统策略的限制会导致这部分数据很低，并且他不是真正意义上的firebase到用户设备的送达。
这个问题本质上不是一个代码上的错误，而是对firebase控制台错误理解的乌龙，但是专门写出来一个是想给遇到同样困扰的人提个醒，因为当时因为这个问题真是折腾了好久都没找到原因，并且网上也很少相关的帖子。再一个就是想给各位开发同学提个醒，有时候google,aws这种大厂会让人有种天生的信任感，导致发现问题时总是第一个怀疑自己。
第一次写，类似于碎碎念了，可能有点乱，但还是希望能帮助到一样被这个问题困扰的人。