当你手机黑屏时，消息是怎么"插队"送达的？

不知道你有没有想过这个问题：手机锁屏了、甚至已经休眠黑屏了，为什么有人给你发消息，手机还是会亮？还是会响？还是会振动？

说实话，我第一次认真考虑这个问题，是因为有天晚上手机震个不停，起来一看全是些无关紧要的推送。当时我就想，同样是消息，为什么有的能把我吵醒，有的就默默躺在通知栏里纹丝不动？

这背后其实涉及到一个很关键技术点——实时消息SDK在设备休眠时的消息优先级处理机制。别看这几个字挺专业，拆开来理解还挺有意思的。

设备休眠到底意味着什么？

先说说什么叫设备休眠。你手机不用的时候，屏幕黑了，表面上看它在"休息"，但实际上它只是在省电。CPU降频、网络模块待机、后台应用被限制——这些都是休眠状态下的常规操作。

这里有个关键点：设备休眠时，系统会大幅削减非必要的后台活动。这很好理解，你总不想手机在兜里放一天，电量就没了一半吧？但问题来了，消息推送本质上就是一种"后台活动"，那它是怎么绕过这些限制，把信息送到你手机上的呢？

这就得分不同的操作系统来看了。安卓和iOS在这方面有截然不同的实现逻辑，也因此影响着实时消息SDK的设计思路。

iOS的"集中营"模式

苹果的选择比较极端，它不允许第三方应用在后台随便连服务器。所有消息必须先到苹果自己的APNs（Apple Push Notification service）服务器报到，再由APNs统一推送给设备。这样做的好处是省电——设备只需要维护一条和苹果服务器的连接就够了，不用跟成百上千个应用分别保持联络。

坏处是什么呢？延迟可能会高那么一点，毕竟多了一层中转。但换来的是更可控的功耗管理，这也是苹果设备续航表现普遍不错的原因之一。

安卓的"开放战场"

安卓则相对灵活一些。应用可以在后台保持长连接，实时消息SDK通常也是这么做的。比如声网的实时消息SDK，就采用了自建长连接配合心跳机制的方案，来保证消息的实时送达。

但安卓的开放也带来了问题：每个应用都维持长连接，电池肯定扛不住。所以安卓系统对后台连接有各种限制，什么Doze模式、Standby Bucket、应用待机分组……五花八门的省电策略。这时候，消息优先级的重要性就体现出来了——不是所有消息都值得唤醒系统，有些就让它老实等着。

消息优先级到底是怎么划分的？

这才是本文的重点部分。实时消息SDK在处理设备休眠场景时，会把消息分成三六九等。不同的优先级，对应不同的处理策略。

高优先级：必须立即送达

这类消息一般是"十万火急"的那种。比如视频通话的来电、语音通话的邀请、直播间里有人给你刷了超级贵重的礼物（对主播来说确实是急事）。

高优先级消息的处理逻辑很简单：唤醒设备、弹出通知、触发震动或铃声，务求第一时间让用户感知到。在技术实现上，SDK会通过系统提供的"高优先级推送"通道来发送这类消息，或者通过长连接发送"信令"来直接唤醒应用。

中优先级：重要但不紧急

像是一对一聊天的新消息、好友请求、群聊@你的内容，这些都属于中优先级。系统可能会延迟几秒到几分钟再推送，也可能会把好几条合并成一条通知，为的是既不打扰用户，又能保证信息及时到达。

声网的实时消息SDK在处理这类消息时，会结合具体场景做智能判断。比如判断用户当前是否在使用其他应用、是否在充电、当前的省电模式级别如何，然后动态调整推送策略。

低优先级：可以稍微等等

公众号更新、APP运营活动、新闻资讯推送……这类消息用户看到了当然好，但晚个半小时一小时也没什么关系。系统可能会把它们归入"汇总通知"，每天统一时间推一次，或者干脆等用户下次点亮屏幕再展示。

对低优先级消息的处理，主要是为了平衡用户体验和设备续航。毕竟谁也不想大半夜被一条广告推送吵醒对吧？

那不同设备厂商的策略呢？

这事儿安卓阵营特别复杂。同样是安卓，各家手机厂商（华为、小米、OPPO、vivo……）都有自己的系统定制，也就有各自的后台管理策略。比如某个品牌可能对音乐类应用开绿灯，允许它在后台跑；另一个品牌可能对社交类应用特别严格，息屏超过五分钟就给你断了连接。

这对实时消息SDK来说是个大挑战。声网的方案是在SDK层面做设备适配，识别当前设备的厂商和系统版本，然后针对不同策略做兼容处理。比如检测到某厂商的省电模式特别激进，就自动切换到更保守的连接策略，用稍微增加一点功耗来换取消息的送达率。

国内安卓生态的特殊性

国内没有谷歌服务框架，APNs的那套逻辑走不通，各家手机厂商就自己做了推送服务。华为有HMS Core推送、小米有Mi Push、OPPO有Push……这对开发者来说其实是好事，至少有个统一的出口。

声网的实时消息SDK在国内安卓环境下，会优先走厂商推送通道。这些通道的优先级通常比普通的长连接更高，系统也会更"给面子"，不容易被后台清理掉。如果厂商通道不可用，再回退到自建长连接方案，双管齐下提高送达率。

实际开发中会遇到的几个问题

作为一个曾经踩过坑的开发者，我觉得有必要分享几个实际会遇到的问题。

问题一：心跳间隔怎么设？

长连接要维持"存活"，得定期发心跳包。发得太频繁，耗电；发得太稀疏，连接可能被系统kill掉。这个间隔在不同设备上、不同的系统版本上、最佳数值可能完全不一样。

声网的方案是采用自适应心跳策略。SDK会监控连接的稳定性，如果在某个设备上频繁出现心跳超时，就自动延长间隔；如果连接稳定，就维持在一个相对经济的水平。这种动态调整的思路，比"一刀切"要聪明得多。

问题二：断线重连怎么处理？

设备休眠时连接断了很正常，重连的时机和策略就很关键。如果每次断线都立刻重连，用户不用手机的时候电池就遭殃了。如果重连太迟，重要的消息又送不到。

常见的做法是指数退避重连：第一次断了等几秒重试，第二次等十几秒，第三次等几十秒……这样既不会频繁打扰系统，也能在合理时间内恢复连接。对高优先级的信令消息，还可以设置更激进的重连策略，甚至直接通过推送通道来唤醒。

问题三：消息丢失怎么办？

极端情况下（比如用户一觉睡醒发现手机没电关机了），消息可能确实送不到。这时候SDK需要做好消息持久化——在本地存一份，服务端也存一份。用户下次打开应用时，自动拉取未读消息，做到"消息不丢失、状态可恢复"。

不同业务场景下的优先级策略

前面说的是通用的消息分级逻辑，但具体到不同业务场景，优先级的定义可能完全不同。

1V1社交场景

在1V1视频社交场景中，"秒接通"是核心体验。用户发起视频邀请，对方如果隔了七八秒才收到通知，体验就大打折扣。这类场景下的通话信令通常会被设为最高优先级，配合全球节点布局和小于600ms的接通耗时，才能做到"还原面对面体验"。

秀场直播场景

秀场直播里，关键时刻的消息特别重要。比如主播正在PK，收到粉丝的大额礼物打赏——这种消息必须在第一时间送达，让主播能够当众感谢，从而带动气氛。这就需要对"打赏通知""弹幕通知""礼物特效触发"这些消息做特殊处理，确保它们在设备休眠时也能及时弹出。

游戏语音场景

游戏里的语音消息比较特殊。一方面，游戏的实时性要求很高，开团报点、战术沟通都是分秒必争；另一方面，游戏本身功耗就大，如果在后台语音连接再耗电，玩家肯定不爽。这里面就需要做精细的功耗和体验平衡。

怎么判断一个SDK的优先级处理做得好不好？

这里有个简单的判断标准，可以从几个维度来看：

• 消息送达率：在各种设备、各类省电模式下，消息能否稳定送达？这需要大量的设备兼容性测试。
• 延迟表现：从消息发送到用户收到通知，平均耗时多少？高优先级消息能否做到秒级触达？
• 功耗控制：消息推送带来的额外耗电是否在可接受范围内？不会说开着APP耗电快得吓人。
• 厂商适配：对国内安卓的碎片化生态是否有足够的适配？各主流手机品牌的推送通道是否都打通了？

以声网为例，他们在全球超过60%的泛娱乐APP中使用，积累了海量的设备兼容数据，能够针对不同设备型号、系统版本、省电模式做定向优化。这种在实战中磨出来的经验，不是靠实验室测试能得到的。

为什么这对开发者很重要？

说了这么多技术细节，可能有人要问了：这跟普通用户有什么关系？

其实关系大了。你有没有用过某个APP，消息总是延迟十几分钟才收到？你有没有试过明明开着APP，后台一锁屏就断联？这些都是优先级策略没做好的表现。作为开发者，如果你选的实时消息SDK在这块儿不给力，你就得自己花大量时间做兼容、做优化，成本蹭蹭往上涨。

而一个成熟的SDK，应该把这些问题都封装好，让开发者只需要关注业务逻辑本身。声网的实时消息SDK就是这种思路——帮你把设备休眠时消息怎么送达、怎么分级、怎么省电这些问题都解决了，你只管接上SDK正常收发消息就行。

写在最后

唠了这么多，其实最想表达的就是：设备休眠时的消息处理，远不是"发出去就完事儿"那么简单。它涉及到底层系统的省电策略、不同厂商的定制逻辑、消息本身的轻重缓急……方方面面都要考虑到。

下次你手机在兜里震的时候，可以想想，这条消息经历了多少道"关卡"才到你手里。也许是系统推送通道放行了它，也许是SDK的心跳机制keep住了连接，也许是某个工程师调试了无数遍的优先级策略正在发挥作用。

技术这东西，平时感觉不到最好。一感觉不到，说明它正在默默地把事情做对。