APP推送为什么经常收不到？APNs、Android后台限制和设备Token怎么排查

很多APP在开发阶段测试推送完全正常，上线以后却开始出现“这个用户能收到、那个用户收不到”“后台时有时无”“接口已经成功但手机没提示”。

原因是推送并不是服务器直接把一条消息送进用户通知栏，中间至少经过业务服务器、推送服务、操作系统和设备当前状态。

接口返回成功不等于用户已经看到

服务端把消息成功提交给APNs或Android推送平台，只代表平台接受了本次请求。

设备可能离线、Token已经失效、用户关闭通知、系统限制后台活动，或者消息后来被平台丢弃。

因此后台不要把“第三方返回200”直接记录成“用户已读”甚至“用户已收到”。

提交、送达、展示、点击应该是不同概念。

设备Token不是永久身份证

iOS和Android推送通常都依赖设备或应用实例对应的Token。

用户重装APP、迁移设备、系统状态变化或推送服务更新后，Token可能发生变化或失效。

APP启动和登录时应能够把当前有效Token重新同步给服务器。

服务端收到明确的无效Token反馈后，也应停止继续向旧Token发送，避免数据库长期堆积大量无效设备。

通知权限必须单独检查

APP具有联网权限，不代表就拥有通知展示权限。

用户可能在第一次弹窗时拒绝，也可能后来在系统设置里关闭通知。

客户端应该能够识别当前授权状态，并在合理业务场景解释为什么需要通知，而不是每次启动都反复骚扰用户授权。

如果用户已经明确拒绝，服务端继续发送再多消息也无法解决通知栏不展示的问题。

Android后台限制更复杂

不同Android版本和设备厂商对后台进程、电量优化、自启动和消息通道存在不同策略。

如果APP完全依赖自己的长连接保持在线，进程一旦被系统回收，消息就可能中断。

生产项目通常需要根据目标市场和设备分布选择合适的系统或厂商推送能力，并对不同通道做统一封装，而不是把所有设备假设成同一种运行环境。

iOS还要区分通知和后台更新

有些消息目标是直接显示通知，有些只是希望在后台唤醒应用处理数据。

两种场景的系统策略并不完全一样。

特别是后台更新不能被当成“系统保证每次立即执行”的任务调度器。

设计业务时必须接受操作系统会根据电量、网络和应用状态决定执行机会。

真正必须实时到达的关键业务，不能只靠一个不受控制的后台唤醒假设。

重复推送和乱序也需要业务处理

订单状态、聊天消息和系统提醒经常经过异步队列。

同一事件可能因为重试被发送多次，旧事件也可能比新事件晚到。

客户端最好能够根据message_id或业务版本去重；状态类消息还要检查新旧版本，避免“已完成”订单因为迟到的一条“处理中”消息又显示回旧状态。

服务端需要完整推送日志

至少记录用户、设备、Token版本、消息ID、推送平台、发送时间、平台响应和业务场景。

出现“某个用户没收到”时，应该能够查出到底是根本没有生成消息、队列没有消费、平台拒绝、Token失效，还是设备端没有展示。

没有这些数据，只能让开发人员不断在测试手机上反复点按钮碰运气。

到达率要按设备和版本拆开看

如果总到达率下降，应进一步按iOS/Android、APP版本、系统版本和主要设备类型分析。

某次APP升级后只有新版本下降，往往意味着客户端集成问题；某类系统版本集中异常，则更可能与权限或后台机制有关。

这样比只看一个全局百分比更容易定位问题。

资料依据

Apple官方UserNotifications与APNs文档说明了设备Token、通知授权、Provider到APNs的发送链路和系统通知行为。

Android官方关于通知权限、后台执行和电量管理的文档说明，应用后台能力会受到系统版本和设备状态限制。

结论

推送问题不能只问“接口有没有调用成功”。真正稳定的APP推送需要同时管理Token生命周期、用户权限、系统后台规则、不同推送通道、消息幂等和可观测性，才能把一次服务端请求变成可追踪的用户触达链路。