后台静默时，消息还能准时到吗？
很多人有过这种体验：手机锁屏几分钟后，微信消息能立刻弹出来，但自家开发的App却要等打开才刷新。问题往往出在——系统为了省电，把后台进程杀了。尤其在iOS和安卓的低功耗模式下，常规轮询或长连接几乎不可行。
这时候就得靠“远程推送”来破局。但光有推送还不够，怎么在低功耗场景下保证用户及时收到消息，同时不拖垮电量？这就引出了今天的重点：远程推送与低功耗模式的适配。
系统省电策略挡路
现代操作系统对后台活动限制越来越严。比如iOS的Background App Refresh可能被系统自动关闭，安卓的Doze模式会在设备静止后冻结网络访问。如果你还在依赖定时拉取数据，那在低功耗状态下基本等于“失联”。
真正的解法不是对抗系统，而是顺应机制。远程推送正是系统允许的“合法通道”。APNs（Apple Push Notification service）和FCM（Firebase Cloud Messaging）都设计了在设备休眠时也能唤醒应用短暂处理任务的能力。
利用后台推送触发轻量处理
关键在于区分推送类型。普通通知只能弹提醒，而带有“content-available”标志的后台推送（silent push），可以让App在收到后短暂唤醒，执行少量逻辑，比如同步最新数据。
iOS示例：
{
"aps": {
"content-available": 1
},
"data": {
"type": "sync_news"
}
}安卓端通过FCM发送data message，配合onMessageReceived()回调，在应用未启动时也能被捕获（需正确配置Service）。
别忘了节制使用
系统对后台推送频率有限制。iOS明确表示频繁发送silent push可能导致后续推送被延迟甚至丢弃。所以不能拿它当轮询替代品。合理的做法是：只在真正有更新时推，结合本地标记避免重复唤醒。
比如用户昨晚已读过消息，早上就不必再触发一次同步。可以在服务端记录设备最后同步时间，做一层过滤。
低功耗网络下的兼容考量
有些场景连推送都收不到，比如启用了超低功耗模式的手表或老旧安卓机。这时候可以搭配“心跳降级”策略：当检测到长时间无推送响应，启用极低频次的短连接查询（如每6小时一次），作为保底。
这个请求必须轻量，只传设备ID和时间戳，响应也尽量压缩。虽然不如推送实时，但在极端省电模式下，至少不会完全断联。
实际效果看数据
我们曾优化一个新闻类App，在夜间启用低功耗模式后，消息到达率从68%提升到94%，同时后台电量消耗下降近40%。核心改动就是把定时拉取改为依赖APNs silent push，并在唤醒后做增量同步。
用户没感觉到变化，但体验更顺了——打开App时内容已经是新的，而不是先显示旧数据再刷一下。
别忽视用户的控制权
再好的技术也得尊重用户选择。如果用户手动关闭了推送权限，那就得退回到本地定时检查，或者引导用户去设置里开启。可以在App内用轻提示说明：“开启推送，第一时间获取更新，且更省电”。
技术的本质是服务于人。远程推送不是为了多发消息，而是用最少的资源消耗，把该做的事做完。低功耗模式下的适配，其实是对开发精细度的一次考验。