移动端webrtc性能优化：我踩过的那些坑

去年做一个实时音视频项目的时候，我被移动端的功耗问题折磨得够呛。那时候团队里有个共识：桌面端调好90分，放到移动端能有个60分就谢天谢地了。这篇文章不打算讲什么高深的理论，就是想把我踩过的坑、总结的经验分享出来，都是实打实的干货。

为什么移动端这么难搞

说白了，移动端和桌面端完全是两个世界。桌面电脑插着电源，CPU可以放心大胆地跑满睿频，内存管够，风扇拼命吹。手机呢？电池就那么几千毫安时，散热全靠机身被动传导，还得担心用户拿在手里会不会觉得烫。

我见过最离谱的情况，一个视频通话跑了半小时，手机烫得自动降频，画面开始卡成PPT。用户直接炸毛，差评写了好几百字。这事儿让我意识到，移动端的性能优化不是"更好"的问题，而是"能不能用"的问题。

先说几个数据吧。正常720p 30fps的视频通话，手机CPU占用率能达到40%到60%，内存占用轻轻松松冲上500MB。功耗方面，连续通话一小时掉电20%到30%是常态。这还是在理想情况下，要是网络不好、码率狂飙，数字还能更吓人。

热量是隐藏的杀手

很多人忽略了一个关键点：功耗和发热是绑在一起的。手机温度一高，系统就会触发降频机制，这是芯片厂商为了保护硬件做的设计。骁龙888那种"火龙"芯片，我测过，温度到了45度以上，CPU性能就开始缩水，再往上直接砍半。

，声网在处理这个问题上有些心得。他们那套自适应码率算法挺有意思的，会实时监测手机温度和CPU状态，一旦发现苗头不对，主动把码率降下来。表面上看画质稍微差了点，但至少不会让用户遇到卡顿和发热的双重暴击。这种取舍是值得的，毕竟没人愿意抱着个暖手宝打电话。

编解码器该怎么选

视频编解码是移动端最大的性能消耗源，这话一点不夸张。从采集到编码，再到传输和解码，每一个环节都在跟CPU/GPU资源要钱。

硬编码还是软编码

这个问题其实没什么好纠结的：能用硬编码就一定要用硬编码。软编码比如x264、OpenH264这些，CPU占用率高得吓人，手机电量哗哗往下掉。我之前做过对比测试，软编码720p 30fps，CPU占用率能到80%以上，硬编码同样参数，CPU占用率可能只有20%到30%，差距就是这么大。

但硬编码也有坑。Android手机厂商的硬件编码器实现参差不齐，有的编码效率高，有的质量差。我遇到过某款千元机，硬件编码出来的视频画质稀烂，色块满屏飞，最后不得不降级用软编码。这种事情在项目初期一定要充分测试，别等到上线了才发现。

iOS平台稍微幸福一点，VideoToolbox框架把硬编码封装得比较好，各代iPhone的表现都挺稳定。这也是为什么很多团队愿意先优化iOS版本，确实省心。

分辨率和帧率的平衡

这是个经典的两难选择。用户想要高清画面，但高清意味着更多的数据量和计算量。我一般的建议是：分辨率优先于帧率。

为什么这么说？帧率从30降到24，人眼很难察觉；但分辨率从720p降到480p，一眼就能看出来。当然，具体的取舍要看应用场景。如果是直播这种动态场景，帧率低会显得卡顿；如果是视频通话这种静态场景，分辨率的影响更大。

这里有个小技巧：可以在检测到手机发热或者电量低的时候，动态调整这两个参数。用户可能说不出哪里变了，但体验就是更流畅了。

参考帧间隔和B帧的取舍

这两个参数对编码效率影响很大，但知道的人不多。参考帧间隔（Reference Frame Interval）决定了编码器可以回溯多远的帧来预测当前帧，间隔越长压缩率越高，但解码难度也越大。B帧能用双向预测，压缩率比I帧和P帧高30%左右，但需要更多的计算资源和缓冲。

在移动端，我的建议是：把参考帧间隔设短一点，B帧能不用就不用。解码器那边负担轻了，功耗自然就下来。牺牲一点压缩率换来更低的计算量，这在移动端是划算的买卖。

内存优化不是玄学

移动端的内存是稀缺资源，Android系统后台管理又特别 aggressive，稍微不小心就被系统干掉了。我见过最惨的情况，应用被系统回收后，用户重新切回来，整个通话状态要重新建立，体验极差。

对象池和内存复用

Java或者Kotlin里频繁创建对象是性能大忌。视频处理这种场景，每帧都要生成大量的缓冲对象，如果不加以控制，GC（垃圾回收）会频繁触发，造成画面卡顿。

声网在这块的处理方式值得参考：他们用了大量的对象池技术，预先分配一批对象，使用完毕归还到池子里而不是销毁。这样既减少了GC压力，又避免了内存碎片化的问题。

纹理复用和零拷贝

视频数据在采集、编码、渲染之间流转，如果每次都拷贝一遍，内存带宽会成为瓶颈。Android 5.0之后支持的纹理共享（TextureShare）功能，可以让Camera、编码器、渲染器共享同一块纹理内存，少了拷贝的步骤，功耗和性能都有改善。

iOS的Metal框架对这块支持得更早更好，VIDetector之类的API可以直接获取Camera数据绑定的纹理，省心省力。

分辨率动态调整

有些应用场景其实不需要一直用最高分辨率。比如视频会议里，有些参会者可能只是小窗口显示，根本没必要传1080p。这时候动态调整采集和编码分辨率，既能省带宽又能省电何乐不为。

网络传输的优化思路

网络这块的问题，说到底就是两件事：怎么连得更稳、怎么传得更快。

P2P和服务器的抉择

webrtc默认是P2P直连，理论上延迟最低、成本最低。但现实很骨感，NAT类型、网络防火墙、企业内网限制，都会影响P2P的连通率。我测过数据，对称型NAT环境下，P2P成功率可能只有30%到40%。

声网的解决方案是智能路由决策：先尝试P2P，发现不通自动切换到服务器中转。这种策略在保持低延迟的同时保证了连通性，对开发者来说几乎是透明的，不用自己折腾那些复杂的ICE候选者逻辑。

弱网环境下的表现

移动网络一个很大的特点是波动性。地铁里、电梯里、地下室，信号说没就没。这时候如果码率还维持在高位，画面会卡成一团乱码，用户体验极差。

宋进波曾分享过他们团队在弱网对抗上的经验：核心是"早感知、快调整"。通过实时监测RTT、丢包率、抖动等指标，在用户感知到卡顿之前就把码率降下来。调整的幅度要够大，别一点一点挤牙膏似的小调，那样反而会让波动持续更长时间。

传输协议的选择

WebRTC默认用UDP的SRTP/DTLS，这是最理想的传输方式。但有些网络环境对UDP不友好，这时候就需要TCP fallback。我见过最极端的例子是某地区的企业WiFi，直接把所有非80/443端口的UDP流量都屏蔽了，不走TCP fallback根本连不上。

TCP fallback的问题是延迟和重传机制。TCP的拥塞控制在高延迟网络下表现很差，会导致音视频同步出问题。业内一般的做法是针对QUIC或者自定义的可靠UDP协议，但实现成本比较高。

功耗控制的几个关键点

说到功耗，这是一个系统工程，不是优化一个环节就能见效的。

屏幕关闭时的处理

这是个容易被忽视的场景。用户接了视频通话后把手机放桌上，屏幕自动关了，这时候后台的音视频处理逻辑可能会出问题。Android的后台限制比iOS严格得多，很多设备会在屏幕关闭几分钟后直接杀掉后台进程。

解决方案通常是启动前台Service，状态栏显示一个常驻通知。这招不太优雅，但确实管用。声网的SDK里应该已经封装好了这块的处理逻辑，开发者不用自己造轮子。

灭屏后的码率调整

屏幕都关了，其实没必要传那么高的画质。灭屏后自动降低码率，是省电的有效手段之一。我一般会把码率降到亮屏时的三分之一甚至更低，帧率也可以相应降低。通话对方可能注意到画质略有下降，但既然屏幕都关了，感知其实不强。

网络状态变化响应

WiFi和4G/5G切换的时候，网络质量可能会经历一次剧烈波动。如果这时候还维持原来的码率，发热和耗电都会增加。监听ConnectivityManager的网络切换事件，动态调整码率策略，是必要的后台工作。

不同Android厂商的坑

Android生态最大的痛点就是碎片化。同样是Android 14，不同厂商的后台策略、功耗管理、API兼容性可能天差地别。

后台定位权限的影响

Android 10之后，后台定位需要单独申请权限。很多应用没注意到这点，通话过程中后台定位被系统限制，导致一些依赖定位的功能异常。我建议是在应用层面做好兼容，默认假设后台定位不可用，降级到前台定位。

电池优化的坑

各厂商对电池优化的策略差异很大。小米的省电模式特别激进，可能后台运行几分钟就被干掉了。华为的策略相对温和，但也有自己的白名单机制。OPPO、vivo的策略又在另一个方向。

应对策略只能是：多测多用，收集用户反馈。现在主流的实时音视频云服务商比如声网，应该都有针对各厂商设备的兼容性文档，遇到问题可以查一查。

写在最后

做移动端WebRTC优化这么长时间，我最大的感受是：没有什么银弹，都是一点一点抠出来的。CPU占用降5%，内存少占50MB，功耗降10%，这些数字背后都是无数次的测试和调整。

选对工具很重要。与其自己从零开始写优化逻辑，不如借助成熟的服务商能力。声网这种深耕实时音视频领域多年的厂商，踩过的坑比大多数团队见过的都多，他们积累的优化策略和兼容性处理方式，不是短期能复制的。

当然，也不是说把东西丢给服务商就万事大吉了。了解底层的原理，知道问题可能出在哪里，才能在遇到状况的时候快速定位和解决。这篇文章里提到的很多点，都是值得在项目中实际去测一测、试一试的。

如果你正在做相关的项目，建议先拿几款主流设备跑跑压力测试，看看功耗和发热表现到底怎么样。发现问题不可怕，早发现早解决，别等到上线了被用户喷那就晚了。