项目背景：安卓WebRTC推流系统，链路为「安卓Camera2采集 → LiveKit SFU服务 → 浏览器播放」。需要增加实时美颜，同时要兼顾低端老手机和旗舰手机，支持参数实时调节，本地预览和远端观看效果完全一致。整个过程踩过SDK底层限制、进程静默消失、帧链路卡死等诸多坑点，分享完整落地思路与实战经验。
作者：lansnow
来源：好好学习自留地
链接：https://mp.weixin.qq.com/s/cXoHcTtvTSeBJx70RiRL7Q
需求目标
兼容高低两款机型：低端Helio P35手机、旗舰骁龙8 Gen2手机；
低端设备自动降级，美颜不能造成卡顿、崩溃；
UI滑动调节美颜参数，不需要重启推流；
手机本地预览画面，要和浏览器远端看到的美颜效果一模一样。
两次方案尝试，第一种直接失败
方案一：官方VideoProcessor扩展点（不可行）
最开始想直接使用LiveKit提供的 VideoProcessor，拿到GPU纹理，写GL Shader做美颜处理，再把处理完的纹理回传给SDK。
现象：表面看CPU占用很低，只有4‑5%，但是美颜完全没有生效，甚至会直接触发进程SIGABRT崩溃。
排查后发现根源：LiveKit把WebRTC底层类做了包名重命名，Native层对 TextureBuffer 做强合法性校验。应用层手写组装出来的纹理Buffer，会直接被底层拒绝。CPU低只是帧完全没有经过美颜处理，原始画面直接透传的假象。
小技巧：做染色测试，给画面强制染成绿色，如果画面不变色，就代表处理逻辑根本没有跑起来，不要被性能数据迷惑。
方案二：自定义采集器，前移美颜处理（最终落地）
既然SDK内部纹理回注这条路被封死，那就把美颜逻辑挪到SDK的上游采集环节。
相机输出OES纹理，GL线程执行美颜Shader渲染；
通过 glReadPixels 把GPU画面读回到CPU内存；
使用WebRTC自带libyuv（ARM‑NEON硬件加速），把RGBA转换成I420；
构造SDK原生支持的 JavaI420Buffer 向下传递，绕开TextureBuffer的校验限制。
代价：多出一次GPU回读CPU的开销，但是Native完全兼容，高低机型都可以稳定运行。
整体工作流程
真实相机采集 → GL线程做美颜Shader渲染 → FBO离屏渲染
→ glReadPixels读取RGBA数据 → libyuv转I420
├─主线程：送给本地预览渲染
└─下游：交给LiveKit SDK编码、推流到SFU重点工程细节
帧引用计数必须配对异步处理帧的时候，处理前调用 frame.retain() 增加引用，处理完成必须 release()。如果忘记配对，会触发引用计数异常，直接APP崩溃。预览、推流两路可以共享同一份Buffer，各自释放。
忙时主动丢帧，防止队列积压相机持续输出24fps，如果美颜处理慢，异步Handler队列会不断堆积帧，短时间看不出问题，运行几分钟之后会出现进程”静默消失”，没有崩溃日志。 解决方案：用标记位记录GL是否繁忙，如果正在处理一帧，新来的帧直接丢弃，宁可降帧率，也不能堆积，保障实时性。
预览渲染必须切主线程不能直接在GL线程调用预览渲染组件，会触发EGL同步死锁，现象就是预览黑屏、帧率直接变成0。必须通过Handler把帧投递到主线程再渲染。
矩阵与图像翻转坑点Android的 Matrix 是3阶矩阵，不能直接当成GL的4×4矩阵数组使用，需要手动转换；同时在着色器做Y轴翻转，避免读出图像上下颠倒。
美颜算法：无AI人脸关键点，高低配双档位
为了照顾低端手机，不做人脸检测、关键点AI推理，全部效果都在片元着色器逐像素运算。轻量档（低端机自动开启）：3×3均值模糊做磨皮，采样少，GPU负载低；
旗舰档：5×5高斯模糊模拟磨皮，做细节保护，五官、边缘高频区域保留原图，只对皮肤平坦区域做模糊，不会整张脸糊掉。
自动判定低端设备：根据手机型号、硬件芯片型号、CPU核心数量自动切换档位。
开放6个可实时调节的美颜参数，滑动条拖动立刻生效，不用重启推流：磨皮、美白、亮肤、红润、饱和度、对比度。 处理顺序固定：磨皮→美白→亮肤→红润→饱和度→对比度。
实测性能表现
测试推流规格：960×540，24fps，VP8编码。
低端华为（Helio P35，轻量档）CPU占用5‑6%，受限于处理能力，稳定输出19‑20fps，无崩溃，温度34℃，预览和远端效果保持一致。
三星S23（旗舰高斯档）CPU仅5%，美颜完整效果正常，推流稳定。
补充：主要开销来自 glReadPixels GPU回读CPU，这是该方案绕不开的代价；YUV转换依靠libyuv的NEON指令，开销已经压到最小。低端机帧率下降属于主动丢帧保实时，不是bug。
踩坑问题速览
| 现象 | 根因 | 解决办法 |
|---|---|---|
| APP直接SIGABRT崩溃 | 手写TextureBuffer被底层校验拦截 | 改用JavaI420Buffer |
| 美颜完全不生效，CPU还很低 | 处理链路没执行，画面直接透传 | 染色测试验证链路是否真正执行 |
| 几分钟后APP悄无声息消失 | 帧处理慢，消息队列、纹理池积压 | GL忙标记，新来帧直接丢弃 |
| 预览黑屏，帧率直接归零 | GL线程直接调用预览组件造成死锁 | 投递到主线程渲染预览 |
| 帧引用计数崩溃 | 异步处理没有retain/release配对 | 严格配对帧生命周期 |
| 图像矩阵报错 | Android 3阶Matrix不能直接给GL使用 | 手动转换成4×4矩阵数组 |
经验总结
使用LiveKit二次开发要留意WebRTC被shade重打包，不要想当然直接手写内部TextureBuffer，I420才是安全通路。
GPU美颜后 glReadPixels 回读CPU会带来固定开销，做方案评估就要纳入性能预算，不要忽略。
异步帧处理两件大事：引用计数管理 + 队列积压丢帧保护，少一个就会出现稳定性事故。
Android预览组件有线程限制，跨EGL上下文调用很容易直接卡死整条视频链路。
老手机做美颜，不要上AI关键点算法；优先轻量GPU shader，配合主动降帧降级，换取整体稳定性。
后续可优化方向
增加前台服务，应对锁屏后台被系统杀掉；
读取设备温度、负载，过热自动降低美颜档位和分辨率。
版权声明：本文内容转自互联网，本文观点仅代表作者本人。本站仅提供信息存储空间服务，所有权归原作者所有。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至1393616908@qq.com 举报，一经查实，本站将立刻删除。
