29、WebRTC 性能优化：CPU 与 GPU 优化、内存管理、电池消耗优化
做WebRTC开发这么多年，我见过太多团队把精力全放在网络抖动和丢包重传上，结果一上真机就翻车。为什么？因为性能没跟上。说白了，你算法再牛，CPU扛不住、内存爆了、手机发烫降频，用户体验照样归零。
这一章，咱们就聊聊WebRTC在端上的性能优化。我会从CPU、GPU、内存、电池四个维度展开，结合我踩过的坑，给你一套可落地的优化方案。
核心观点：WebRTC性能优化的本质，是在有限的计算资源和功耗预算内，最大化音视频处理吞吐量。别想着面面俱到，要懂得取舍。
CPU 优化：别让编解码吃掉所有算力
WebRTC里最吃CPU的，就是编解码。我记得有一次在低端安卓机上做测试，H.264软解直接把CPU干到90%，手机烫得能煎鸡蛋。后来换成硬解，CPU直接降到30%。
几个关键优化点：
- 优先硬件编解码：能用硬件就别用软件。Android上MediaCodec，iOS上VideoToolbox，这是底线。我见过有人为了兼容性硬上软编，结果用户全在骂卡顿。
- 动态分辨率调整：别死磕720P。网络差的时候，降到480P甚至360P，CPU负载能降一半。WebRTC的Simulcast就是干这个的。
- 帧率控制：30fps不是必须的。视频会议场景下，15fps配合好的帧间预测，观感差别不大，但CPU省了40%。
- 线程模型：别把所有处理塞到主线程。编码、解码、渲染各走各的线程，用TaskQueue来调度。我习惯把编码线程优先级调高，渲染线程次之。
我的经验：在Android上做硬编硬解时，记得处理MediaCodec的异步回调。我曾经因为同步等待导致帧率抖动，后来改成异步+BufferQueue，流畅度直接上一个台阶。
GPU 优化：渲染管线别拖后腿
GPU主要负责渲染和图像处理。很多人只盯着CPU，忽略了GPU的瓶颈。其实在美颜、背景虚化这些场景里，GPU才是主角。
优化思路：
- 减少渲染次数：不是每帧都需要重绘。画面没变化时，直接复用上一帧的纹理。WebRTC的VideoFrameBuffer里有个nativeHandle，可以直接操作GPU纹理，省掉CPU拷贝。
- 纹理共享：编码器和渲染器共用同一份纹理，别来回拷贝。OpenGL ES的EGLImage扩展就是干这个的。我在项目中用这个把内存带宽占用降了60%。
- 降低分辨率再渲染：如果只是做预览小窗，别用全分辨率渲染。缩放到320x240再渲染，GPU负载能降70%。
- 避免过度绘制：检查你的渲染层级。有些UI叠加层其实可以合并，减少overdraw。
注意：GPU优化要分平台。iOS的Metal比OpenGL ES效率高30%左右，Android上Vulkan也开始普及。如果你的目标设备支持，优先用新API。
内存管理：别让OOM毁了体验
WebRTC的内存泄漏，我见过最离谱的一次——一个视频帧缓冲区没释放，跑了两个小时，内存从200MB涨到1.2GB，然后app直接闪退。排查了半天，发现是引用计数没处理好。
内存优化的核心：
| 优化项 | 具体做法 | 效果 |
|---|---|---|
| 缓冲区池化 | 预分配固定大小的缓冲区，用完归还，避免频繁malloc/free | 减少内存碎片，分配速度提升5倍 |
| 引用计数管理 | 使用智能指针（如webrtc::scoped_refptr），避免循环引用 | 杜绝内存泄漏 |
| 帧缓存控制 | 限制解码队列长度，超过阈值直接丢帧 | 内存占用稳定在合理范围 |
| 零拷贝路径 | 从摄像头到编码器，尽量走GPU纹理或共享内存，避免CPU拷贝 | 内存带宽节省50%以上 |
我个人习惯在开发阶段就开启AddressSanitizer和LeakSanitizer，跑一遍全流程，基本能扫出90%的内存问题。别等到上线了再查，那时候成本就高了。
避坑指南：我曾经在Android上遇到一个坑——MediaCodec输出的ByteBuffer是direct buffer，如果忘记调用rewind()，下次读取就会读到脏数据。后来我统一封装了一个BufferWrapper，自动管理position和limit，再没出过问题。
电池消耗优化：别让用户骂你「电老虎」
电池优化，说白了就是「能不干活就别干活」。WebRTC的实时性要求高，但也不是每时每刻都需要全速运转。
几个实用策略：
- 自适应帧率：画面静止时，自动降到5fps甚至1fps。WebRTC的VideoSource里有个OnFrame接口，你可以根据画面变化量动态调整采集帧率。
- 休眠策略：没有音频输入时，让音频处理模块进入低功耗模式。视频同理，摄像头可以降低功耗模式。
- 网络唤醒优化：别用轮询检查网络状态。用系统提供的网络回调接口，只在状态变化时触发处理。
- 减少不必要的计算：比如回声消除，如果检测到当前没有扬声器输出，直接跳过AEC处理。我在项目中加了这个逻辑，CPU占用又降了10%。
小技巧：在iOS上，记得把音频session设置为playback模式，这样系统会优先保证音频性能，同时降低其他后台任务的CPU占用。Android上同理，用AudioManager的setParameters来优化音频路径。
总结一下
WebRTC性能优化，没有银弹。你得根据目标设备、场景、用户预期来做权衡。CPU、GPU、内存、电池，这四个维度互相影响——你压了CPU，可能GPU就吃紧了；你省了内存，可能帧率就掉了。
我的建议是：先跑一轮Profile，找到瓶颈在哪。然后针对性地优化，每次只改一个变量，对比效果。别一上来就全改，那样你根本不知道哪个改动起了作用。
嗯，这一章就聊到这儿。记住，性能优化是个持续的过程，不是一锤子买卖。
核心原则：用最少的资源，做最必要的事。别为了「可能用到的场景」提前消耗算力，动态适配才是王道。
公众号:蓝海资料掘金营，微信deep3321