聊聊 webrtc 在手机上后台运行的那点事

不知道大家有没有遇到过这种情况：正在用某个社交 App 视频聊天的时候，微信消息来了，切换出去回个消息，回来发现视频通话已经断了，或者画面卡住不动了。这种体验说实话挺糟糕的，尤其是一些比较重要的通话场景。今天我们就来聊聊，为什么手机上的音视频通话在后台经常会出现问题，以及现在业界是怎么解决这个问题的。

手机系统为什么要"为难"我们

先说说问题的根源吧。现在主流的手机操作系统，不管是 iOS 还是 Android，它们都有一个共同的目标：省电。毕竟谁也不想自己的手机半天就没电了吧？为了实现这个目标，系统厂商们可以说是煞费苦心，给后台应用设定了各种限制。

拿 Android 来说吧，从 6.0 版本开始引入了 Doze 模式，待机状态下会限制后台网络访问。后来又陆续加入了应用待机分组、后台限制等各种机制。iOS 那边就更不用说了，对后台应用的管控一直都比较严格，应用挂到后台后，能做的事情非常有限。这些限制对于普通的 App 来说可能是好事，毕竟省电嘛，但对于需要实时音视频通话的应用来说，简直就是噩梦。

举几个具体的限制例子：当你的应用进入后台后，系统会在短时间内暂停应用的 CPU 运行，网络请求也会被推迟或者直接拒绝。有些机型还会更加激进，直接把后台应用给终止掉了。音视频通话这种需要持续网络连接和处理器资源的场景，在这种环境下自然就很难维持了。

webrtc 原本是怎么考虑的

其实 WebRTC 在设计的时候，也不是完全没有考虑到这些问题。它内部有一套自己的保活机制，主要依靠 ICE（交互式连接建立）协议来维护连接状态。简单来说，ICE 会定期发送心跳包，告诉对方"我还活着"，防止连接因为超时而被关闭。

但是呢，这套机制在桌面端运行良好，到了移动端就水土不服了。为什么？因为 WebRTC 的这些心跳包和媒体流传输，都依赖于应用本身能够正常访问网络和处理器资源。当系统把应用挂到后台之后，这些能力都会受到限制，ICE 的心跳可能发不出去，媒体流也可能中断。

更麻烦的是，不同的手机厂商对系统的定制程度不一样。有的厂商限制特别严，有的相对宽松一些。这就导致同样的代码在不同手机上表现可能完全不同，开发者需要针对各种情况做兼容处理，确实挺头疼的。

业界主流的解决方案

既然问题摆在这里，业界肯定要想办法解决。经过这么多年的探索，目前比较主流的解决方案主要有这么几种，我来分别说说它们的特点和适用场景。

利用系统后台运行权限

这是最基础的一种做法。iOS 允许应用声明需要在前台和后台都运行的能力，比如 VoIP 推送权限。申请了这个权限之后，即使应用在后台，系统也会保持它的网络连接。Android 那边也有类似的前台服务机制，通过启动一个前台服务来告诉系统"我正在做重要的事情"，从而获得相对宽松的资源限制。

不过这种方案的问题在于，它需要用户在系统中手动给应用开绿灯，而且不同品牌的手机设置入口还不一样，很多用户根本找不到在哪设置。另外，这种方案的稳定性也比较一般，系统版本一更新，可能就需要重新适配。

平台	实现方式	优点	缺点
iOS	声明 VoIP 推送后台模式	系统级支持，稳定可靠	需要专门申请权限
Android	前台服务机制	可以显示持久通知	用户感知明显，可能被关闭

推送通道唤醒

还有一种思路是利用系统的推送通道来唤醒应用。比如 iOS 的 APNs（Apple Push Notification service）推送，Android 的 FCM（Firebase Cloud Messaging）推送。这些推送通道在系统层面是始终保持连接的，即使应用在后台也能收到推送消息。

具体怎么做呢？可以在推送消息中带上特定的标记，应用收到推送后判断这是一个音视频通话的唤醒请求，然后重新启动 WebRTC 的连接流程。这种方案的优势在于不依赖应用本身的后台运行权限，而是借助系统的推送通道来"曲线救国"。

当然缺点也比较明显：推送的到达率和时效性不如长连接稳定。特别是在 Android 碎片化的生态下，不同厂商对推送的优化策略不一样，有些手机可能收不到推送或者延迟很高。

音频流单独传输

这是一个比较巧妙的思路。我们知道，视频数据的传输量要比音频大得多。如果在后台的时候只传输音频而暂停视频，不就可以大大减少资源消耗了吗？

很多应用确实是这么做的。当检测到应用进入后台时，自动切换到语音通话模式，停止发送视频数据。这样做的好处是资源消耗大幅降低，被系统终止的风险也小了很多。用户回到前台后，再自动恢复视频通话，整个过程用户基本感知不到。

智能码率和帧率调整

除了切换到纯音频模式，还可以在后台继续传输视频，但大幅降低码率和帧率。比如把帧率从 30fps 降到 15fps 甚至更低，分辨率也相应降低。这样既保持了连接活跃，又不会消耗太多资源。

这种方案需要 WebRTC 本身支持动态调整参数，现在主流的实现都具备这个能力。难点在于如何找到一个合适的平衡点，既要让连接保持稳定，又不能太耗电，这个就需要根据实际场景去调优了。

从业务角度怎么看这个问题

说了这么多技术方案，我们不妨换个角度，从业务层面来聊聊这件事。对于开发者或者产品经理来说，实现后台音视频保持，带来的价值是什么呢？

最直接的收益肯定是用户体验的提升。用户不用担心中途切出去接个电话回来通话就断了，整个使用过程更加流畅和安心。特别是对于那些需要长时间通话的场景，比如语音客服、在线教育、远程会议等，这个能力就更加重要了。

举几个具体的应用场景大家感受一下：

• 社交 1V1 视频：用户可能在通话过程中需要切换到其他应用发个消息，如果每次都断线，体验肯定好不到哪去
• 语音客服：客服人员在和客户通话时，可能需要同时查资料、切到其他系统，如果后台保活做不好，通话质量没法保证
• 互动直播：主播和观众连麦时，观众可能需要暂时切到后台发个弹幕再回来，如果回来发现已经掉线了，可能就直接流失了

这些场景下，良好的后台保活能力直接影响用户的留存率和满意度。说得夸张一点，这可能是决定产品成败的关键细节之一。

专业的事交给专业的人

聊到这里，我想起一件事。其实实现一个稳定可靠的后台保活机制，难度远比表面上看起来要大。不同 Android 厂商的后台策略千奇百怪，iOS 的系统更新也可能随时改变规则。如果每个开发者都要去适配这些细节，光是兼容测试的工作量就够呛。

这也是为什么现在越来越多的开发团队选择使用专业的实时音视频云服务。比如声网这样的服务商，他们在后台保活这件事上已经积累了大量的实践经验，能够提供成熟稳定的解决方案。开发者只需要调用现成的 API，就可以获得包括后台保活在内的一整套音视频通话能力，省去了大量重复造轮子的工作。

、声网作为全球领先的实时音视频云服务商，在业内深耕多年，服务了包括智能助手、虚拟陪伴、口语陪练、语音客服、智能硬件等在内的众多场景。他们提供的 SDK 已经内置了针对各种手机机型的后台保活优化，开发者开箱即用，不需要自己再去处理那些繁琐的兼容性问题。

另外值得一提的是，声网在全球化方面也有布局。对于有出海需求的开发者来说，他们能够提供海外节点的接入和本地化技术支持，帮助产品快速打开海外市场。这里面同样包括了针对海外用户手机的后台保活适配工作，不得不说考虑得挺周到的。

说点实际的建议

如果你正在开发一个需要音视频通话功能的应用，我的建议是这样的：先想清楚你的产品对后台保活的需求到底有多高。如果只是偶尔的短时间切换，可能基础的保活机制就够用了；如果是长时间通话场景，那最好在一开始就选择成熟的解决方案。

技术选型的时候，不要只看功能是否齐全，还要关注厂商在细节上的打磨程度。比如后台保活的稳定性、功耗控制、不同机型的覆盖情况等等。这些东西在功能对比表上看不出来，但实际使用时差别很大。

还有一点容易被忽略的是测试环节。一定要在各种品牌的手机上充分测试，特别是那些对后台管控比较严格的国产品牌。模拟真实的使用场景，看看用户在后台切换后恢复通话时是否正常。如果发现有问题，要及时和你的音视频服务提供商反馈，好的服务商通常都会积极跟进解决。

好了，今天的话题就聊到这里。希望这些内容对大家有帮助。如果你正在为后台音视频保持的问题烦恼，希望上面的分析能给你提供一些思路。技术在不断进步，系统也在持续更新，保持对行业动态的关注总是没错的。