如何为数千设备实现即时推送通知？解决FCM推送延迟难题

一、解决FCM推送延迟问题（用户量增长后） #

即使已设置最高优先级，3万用户量级下的延迟通常由多因素导致，对应优化方案如下：

• 补全平台适配细节

  • Android端：
    • 确认发送的是通知消息而非数据消息——数据消息需App处于活跃状态才能处理，只有高优先级的通知消息会触发系统即时唤醒。
    • 绑定高优先级通知渠道：Android 8.0+要求通知必须关联渠道，需创建IMPORTANCE_HIGH级别的渠道，并在FCM请求中指定notification.android.channel_id，否则系统会强制降低通知优先级。
  • iOS端：
    • apns-priority:10仅适用于即时性通知，批量发送非紧急消息时APNs会自动节流，建议拆分紧急与非紧急消息分别发送。
    • 校验apns-topic与App Bundle ID完全匹配，避免因参数错误导致推送被拦截。

• 优化FCM发送策略

  • 避免一次性批量发送数万条通知，FCM对高频批量请求有流量限制，建议拆分批次，控制每秒发送量（比如每秒50-100条，可根据FCM控制台配额调整）。
  • 清理无效设备令牌：定期同步FCM返回的令牌无效信息，删除失效令牌，减少无效请求占用系统资源。
  • 利用主题/设备组功能：针对用户分组发送，降低单条请求的目标数量，提升发送效率。

• 适配App端系统权限

  • Android端：引导用户将App加入后台白名单、关闭电池优化——国产厂商（小米、华为、OPPO等）的系统会严格限制后台App唤醒，即使FCM推送到达，也可能被拦截无法弹出。可在App内提供手动设置引导，必要时申请REQUEST_IGNORE_BATTERY_OPTIMIZATIONS权限（注意合规性）。
  • iOS端：确保用户开启了远程通知权限与通知显示权限，同时UIBackgroundModes配置中包含remote-notification，让App在后台能快速处理推送。

二、Telegram的实时推送实现逻辑 #

Telegram并非完全依赖系统级推送服务，而是采用双通道冗余机制：

1. 基础通道：同样使用FCM/APNs作为 fallback，确保长连接失效时能收到通知；
2. 长连接通道：Telegram在后台维持持续的TCP/WebSocket长连接，即使App被手动关闭，部分系统下它的后台服务会被允许持续运行，直接与Telegram服务器通信。当有消息时，服务器会同时通过长连接和系统推送发送，哪个先到达就触发通知，保证即时性；
3. 厂商合作特权：Telegram与主流Android厂商达成合作，获得系统级的后台运行豁免权，避免被电池优化或后台清理机制杀死，这是它能稳定维持长连接的核心前提。

三、实现类似Telegram实时性的可行方案 #

要达到接近的实时性，你需要：

1. 先把FCM推送优化做到极致，保证系统级通道的可靠性；
2. 为App添加长连接作为补充通道：在后台维持轻量级的TCP/WebSocket连接，处理即时消息推送，同时做好功耗优化（比如网络切换时自动重连、空闲时降低心跳频率）；
3. 针对Android厂商做适配：申请后台运行权限，或引导用户手动将App加入白名单，避免长连接被系统杀死。

内容的提问来源于stack exchange，提问作者Mattia Antonacci