webrtc移动端耗电优化实战技巧

做过移动端音视频开发的朋友应该都有这样的体会：手机烫得能煎鸡蛋，电池以肉眼可见的速度往下掉，用户一边骂娘一边把app给卸载了。这事儿搁谁身上都头疼，特别是做实时通信的，webrtc那套东西确实香，但耗电这个事儿，真是让人操碎了心。

我自己在调WebRTC功耗的时候走了不少弯路，试过各种姿势，有效果好的也有踩坑的。今天就把这些实战经验整理一下，给正在折腾这个问题的朋友一些参考。声明一下，这里说的都是一些通用性的优化思路，具体效果还得结合你们的业务场景去调。

先搞清楚电都耗哪儿了

在动手优化之前，咱们得先明白钱花哪儿了，不然就是瞎忙活。移动端WebRTC的耗电大头主要这么几个地方：

• 摄像头采集： sensor一直工作，这个不用多说
• CPU编码解码： 视频编解码有多烧CPU，做过的人都懂
• 网络传输： 频繁的无线信号收发，基带和射频模块都在加班
• 屏幕渲染： 如果是本地预览一直在亮屏，那屏幕就是用电大户
• 内存和存储： 频繁的内存读写和缓存操作

这里我要特别提一下，很多同学容易忽略一个点：CPU频率动态调整。手机CPU会根据负载自动调频，当你代码里有高负荷操作时，CPU会直接跳到最高频率，那电量哗哗的。所以我们优化的核心思路其实就是两个——要么让做的事情变少，要么让做的事情变轻。

采集端的优化：够用就行

分辨率和帧率的动态调整

这是我最先动刀的地方，也是效果最明显的地方。很多同学一上来就把采集分辨率设成720P甚至1080P，帧率30帧跑满，心想画质好用户肯定满意。结果呢？手机烫得握不住，电池撑不过两小时。

其实这里有个思维误区：分辨率和帧率并不是越高越好。WebRTC传的是实时画面，又不是拍电影。用户真正在意的是能不能看清、卡不卡顿，而不是你用了多高的分辨率。声网在这些年的实践中发现，在移动端场景下，480P到540P的分辨率其实已经能满足大多数场景的需求了。

那具体怎么调？我建议做一个动态调整的策略。网络好的时候可以适当调高，网络差或者检测到设备发热的时候主动降下来。有个简单的做法：定时检测CPU温度或者电池温度，超过阈值就自动降一档分辨率或帧率。比如从30帧降到20帧，从540P降到360P，效果立竿见影。

还有一个点可能很多人没想到：采集端可以适当降低帧率，但编码端可以保持较高的帧率输出。这怎么理解呢？比如你采集端15帧，但通过插值或者其他算法，让编码端以为是30帧的输入，这样编码出来的视频质量看起来还不错，但采集的功耗降下来了。当然这个要看具体场景，不是所有场景都适用。

摄像头硬件层面的优化

摄像头的功耗其实差异挺大的。后置摄像头一般比前置功耗高，因为后置sensor普遍更大、像素更高。如果你只是做视频通话，前置摄像头完全够用，那就没必要开后置。

另外，有些手机支持低功耗的预览模式，这个要利用起来。正常采集预览需要CPU不断处理数据，但有些硬件支持低功耗预览，就是sensor自己处理好了再传给CPU，CPU的负载就下来了。具体实现要看不同芯片平台的API，建议去看一下对应平台的文档。

编解码环节：轻装上阵

编码参数调优

视频编码是CPU杀手第一名，这个应该没悬念。H.264、VP8、VP9这些 codec 都是用算法换压缩率，CPU算力要求自然低不了。

首先要说的就是编码preset的选择。以x264/openh264为例，ultrafast、superfast这种预设虽然画质差一些，但编码速度极快，CPU占用低。在移动端，如果不是特别追求画质，我建议用偏快的preset。虽然压缩率低一些会导致码率升高，但省下来的CPU和电费可能更划算——毕竟网络传输的功耗相比CPU来说，有时候反而是小头。

然后是关键帧间隔（I-frame interval）的设置。默认一般是多少？有的库是2秒出一个I帧，有的是4秒。I帧因为是全量编码，体积大、编码耗时长。如果你的场景允许适当增加I帧间隔，比如改成6到10秒，编码次数少了，功耗自然就降下来了。当然这个会影响seek响应时间和丢包恢复，视情况调整。

还有一点很多人会忽视：编码器的参考帧数量。减少参考帧数量可以降低编码复杂度，虽然会影响压缩效率，但在某些场景下是划算的买卖。建议去读一下你们所用编码器的文档，看看有没有这类可调参数。

硬件编码器的使用

能上硬编就上硬编，这个结论应该是没什么争议的。手机芯片都有硬件视频编码器，功耗比软编码低一个量级。Android平台用MediaCodec，iOS平台用VideoToolbox。

但硬编有个问题：不同手机的硬编表现差异很大，有的硬编质量很好，有的却各种问题。比如码率控制不稳定、关键帧位置不对、色彩空间转换问题等。声网在处理硬编兼容性问题时积累了很多经验，比如某些机型在硬编码4K时会出问题，某些机型硬编码高帧率会卡顿，这些都需要做设备适配。

我的建议是：先尝试用硬编，上线后重点监控硬编相关的异常日志，收集到足够多的崩溃和异常case后，再针对性地做黑名单处理或者降级策略。软编作为硬编的fallback，要在代码里准备好。

传输策略：少发不如巧发

码率控制的艺术

WebRTC的拥塞控制算法（GCC）本身已经挺智能了，但我们还是可以做一些事情让它更省电。核心思路是：减少网络状态的剧烈波动，让数据发送更平稳。

一个有效的做法是设置合理的码率上下限。不要让码率像过山车一样忽高忽低，平稳的码率意味着网卡和基带的工作状态更稳定，功耗自然更低。比如你预估带宽是1Mbps，与其让GCC算法在800K到1.2M之间反复横跳，不如手动把码率固定在1M左右，或者设置一个比较窄的范围比如900K到1.1M。

还有一个点：发送端的 FEC（ Forward Error Correction）冗余数据是可以调整的。FEC会增加额外的包，消耗更多带宽和电量。如果网络质量尚可，可以适当降低FEC的冗余度；网络差的时候再开高。这个可以结合网络质量评估动态调整。

减少不必要的网络交互

想想看，有多少RTCP包在飞来飞去？RR、SR、SDES、BYE这些，每隔几秒就要发一次。虽然单个包不大，但累积起来也是功耗。

一个优化思路是适当增加RTCP的发送间隔。标准里RTCP报告间隔是有最小值的，但你可以调大最大值。比如原本5秒发一次RTCP，可以改成8秒或10秒。这样CPU处理网络中断的频率也降低了，一石二鸟。

另外，STUN/TURN的保活心跳间隔也可以考虑调整。很多产品为了保险起见，把心跳间隔设得很短，比如15秒或30秒。如果你们的业务场景不需要这么敏感的保活，可以适当放宽到60秒甚至更长。

设备端的策略：因势利导

屏幕和触发的处理

这是个大头，但很多人会忽略。如果用户在视频通话时把屏幕关了，或者切到后台，按理说本地预览就没必要跑满帧了，对吧？

Android和iOS都有生命周期回调，检测到Activity/ViewController不可见或者在后台时，把预览帧率降下来，甚至关掉预览。有个细节：关预览不是简单地把预览控件隐藏，隐藏了摄像头还在工作，功耗没降。必须调用对应的API把预览停掉，摄像头sensor才会真正休息。

如果是完全切到后台，有些系统会自动降低app的CPU配额，但有些不会。我们可以主动一些，在切后台时主动降低码率和帧率，甚至暂停非关键的数据发送。这样既省电，又避免被系统强制杀死。

充电状态和电量感知

这个思路可能有点反直觉：如果用户正在充电，是不是可以稍微放开一点功耗限制？反正电是无限的，用户体验更重要。

确实如此。检测到设备在充电时，可以适当提高码率、帧率，画质优先。如果电量很低，比如低于20%，那就反过来，降级处理，优先保证不断线，电量先撑住再说。

Android有BatteryManager广播可以监听充电状态和电量，iOS也有对应的API。这个成本很低，加上去不影响正常体验，该省电的时候省电，该冲刺的时候冲刺。

一些边边角角的优化

除了上面说的这些大块，还有一些小的点可以关注一下：

• 日志输出： 线上版本记得关闭Debug日志，特别是那些频繁打印的日志，既耗CPU又耗IO
• 内存分配： 减少频繁的内存分配和释放，内存分配也是要耗电的，对象池和缓存池用起来
• 线程模型： WebRTC本身是多线程的，但如果你自己加了额外的处理线程，要考虑合并或者精简
• 传感器： 如果用到了加速度计、陀螺仪这些传感器，记得不用的时候关掉

写在最后

回头看这两年做WebRTC功耗优化的经历，最大的感受是：没有银弹。没有任何一个优化技巧能包治百病，必须结合具体场景具体分析。

我的建议是：先上一个全面的功耗监控，测出各模块的耗电占比，然后针对性地优化。测都没测就一通改，很可能做了无用功。声网在这块投入了不少资源做功耗分析和优化，有一套自己的方法论，有机会可以再详细聊聊。

另外，功耗优化是个持续的事情。系统版本在变，手机硬件在变，你的代码也在变。定期review功耗表现，及时发现新问题，这才是长久之计。