嘿，这个问题问到点子上了，刚好我之前做过移动应用后台推送与刷新相关的调研，来给你拆解清楚：

其实Messenger这类即时通讯应用的后台刷新逻辑，核心不是“自己主动定时刷”，而是靠系统级推送通道+后台唤醒机制+长连接三者配合实现的：

• 首先，它会和系统官方的推送服务深度绑定——比如iOS用APNs，Android用FCM。当服务器有新消息时，直接通过这些通道推送信号到设备，系统会立刻唤醒Messenger的后台进程，让它拉取完整的消息内容，这是最主要的刷新触发方式。
• 对于一些非实时但需要定期同步的内容（比如联系人在线状态、未读消息计数），它会利用系统提供的后台任务调度API，比如Android的WorkManager或者iOS的BGAppRefreshTask，在系统允许的“空闲窗口”（比如设备充电、联网且锁屏时）触发少量的刷新操作。不过这种频率被系统严格限制，不会频繁启动，避免耗电。
• 另外，在系统允许的前提下，Messenger会维持一个长连接和服务器保持通信，一旦有新数据产生，服务器直接通过这个连接推送给客户端，能做到近乎实时的更新，比定时轮询高效太多。

先给明确结论：绝大多数场景下，是服务器主动推送信号触发刷新，而非应用定期自我刷新；只有少数非实时场景会用定时刷新补位。具体细节如下：

• 通知展示的核心逻辑：当服务器有新事件（比如好友发消息、群聊@你），会立刻通过APNs/FCM这类系统推送通道，发送一条包含关键信息的推送消息到设备。系统收到后，先展示系统级的通知，同时唤醒对应应用的后台进程，让应用去拉取详细数据并更新本地状态（比如标记消息为已读、更新聊天列表）。
• 那什么时候会用到定期后台刷新？比如资讯类应用更新订阅内容、社交应用同步动态广场，这类非实时的内容，应用会向系统申请后台刷新权限，在系统判定的空闲时段（电量充足、网络稳定），定期触发一次拉取，更新本地缓存。但这种刷新频率极低，iOS可能几小时才允许一次，Android也会根据电池优化策略动态调整。
• 为什么不推荐应用自我定时刷新？因为如果每个应用都在后台定时轮询，会严重消耗设备电量和网络资源，所以现在的移动系统都严格限制了这种行为，反而鼓励服务器主动推送的模式——这也是Messenger这类即时通讯应用的标准做法，毕竟实时性要求高，服务器主动推比客户端盲目轮询靠谱得多。
• 补充个小细节：有些应用会用静默推送——就是推送不展示通知，但会触发应用后台刷新数据，比如同步未读消息数、更新联系人状态，这种同样是服务器主动触发的。

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