一、直播卡顿
卡顿是最常见的投诉，本质是帧供应不上渲染需求。定位时先区分是"网络型卡顿"还是"性能型卡顿"。
定位方法
优化手段
网络层
ABR 自适应码率：根据实时带宽动态调整推流码率（如从 2000kbps 降到 800kbps），这是最有效的手段
FEC 前向纠错：在弱网下添加冗余包，减少重传延迟
多源备份/线路切换：主备双推流，DNS 智能调度选择最优 CDN 节点
协议选择：弱网优先用 SRT/RTMP+QUIC 替代纯 RTMP
性能层
采集帧率从 30fps → 24fps，减少编码压力
关闭不必要的滤镜/美颜，或降低美颜算法复杂度
确保使用硬件编码（VideoToolbox / MediaCodec / NVENC），而非软编码
二、花屏
花屏表现为画面出现马赛克、色块或撕裂，核心原因是解码端参考帧不完整或编码参数异常。
定位方法
按以下顺序排查：
IDR 关键帧问题：IDR 间隔过大（如 >10秒），中途丢包后长时间无法恢复 → 缩短到 2-4 秒
SPS/PPS 丢失：参数集没正确传递到解码端，导致解码器配置错误 → 确保 SPS/PPS 在每个 IDR 前发送
丢包未重传：P 帧丢失后解码器用错误参考帧继续解码 → 检查 NACK/ARQ 重传机制是否生效
码率突变：场景切换时码率突增超过带宽上限 → 开启码率平滑（CBR 或 VBR+MAXCap）
SEI 信息丢失：增强信息丢包导致解码异常 → 关键 SEI 需冗余发送
优化手段
IDR 间隔设为 2-4 秒（60-120 帧 @30fps），过短浪费带宽，过长恢复慢
开启关键帧请求（PLI/FIR）：解码端检测到错误时主动请求 IDR
丢包重传 + FEC 双保险：低延迟场景用 NACK 重传，超时后用 FEC 恢复
码率控制：直播场景推荐 CBR（恒定码率）或带限制的 VBR，避免突发码率打满带宽
三、发热
发热是功耗高的物理表现，移动端尤为明显。核心矛盾是编码 + 渲染 + 网络传输三者持续高负载。
定位方法
温度监控：持续采集 CPU/GPU/电池温度，关注温升曲线斜率
组件级功耗分析：用 Xcode Energy Log / Android Battery Historian 定位耗电大户
编码耗时占比：编码耗时 > 帧间隔的 70%，说明编码器是热源
优化手段
编码侧
优先使用硬件编码器，功耗比软编码低 5-10 倍
H.265/AV1 相比 H.264 同画质省 30-50% 码率，但需评估解码端兼容性
降低编码 profile（High → Main → Baseline），牺牲画质换功耗
渲染侧
美颜/滤镜用 GPU shader 而非 CPU 计算
降低预览渲染分辨率（如采集 1080p 但预览 720p）
避免多层叠加渲染，合并滤镜链
温控自适应
温度 > 42°C 时自动降低帧率（30→24fps）
温度 > 45°C 时降低分辨率（1080p→720p）
温度 > 48°C 时暂停美颜等非核心功能
四、功耗高
功耗问题往往与发热同源，但还涉及后台进程、网络模块、屏幕等非编码因素。
定位方法
优化手段
网络模块：推流时关闭不必要的网络请求，合并心跳包，减少 TCP 连接数
后台管控：直播时暂停非关键后台任务（如同步、预加载）
屏幕策略：直播时适当降低屏幕亮度（但需兼顾用户体验）
编码器调优：设置合理的码率上限，避免编码器全速运转；使用低功耗编码预设
GPS/传感器：直播不需要高精度定位时降级或关闭
实战排查清单
遇到问题时按以下优先级快速定位：
先看网络：上行带宽是否 > 推流码率 × 1.5？RTT < 150ms？丢包 < 1%？
再看编码：是否硬编码？编码 FPS 是否达标？IDR 间隔是否合理？
然后看硬件：CPU < 70%？GPU < 80%？温度 < 42°C？
最后看电源：后台进程是否清理？温控降级策略是否生效？
四个问题往往是连锁反应：发热→系统降频→编码变慢→丢帧卡顿，丢包→花屏→重传→网络功耗升高。所以定位时要有全局视角，不能只盯一个点。
直播四大问题根因全景图
直播问题诊断决策流程图
