3、客户端设备排查：CPU占用率、内存使用率、GPU编码负载、设备温度监控
推流卡顿，很多时候不是网络问题，也不是服务器问题。你猜怎么着？问题就出在用户自己的设备上。
我遇到过好几次这样的情况：用户抱怨推流卡成PPT，我远程一看，CPU占用率已经飙到95%了，风扇呼呼转。这时候你调码率、改编码参数，效果都有限。说白了，设备本身已经扛不住了。
所以这一章，咱们就聚焦在客户端设备本身。我会把CPU、内存、GPU、温度这四个维度的排查方法，一个一个拆开讲清楚。
3.1 CPU占用率：推流的第一道坎
CPU是WebRTC推流的核心计算单元。编码、采集、渲染、网络打包，全都要靠它。CPU一旦吃满，编码器就抢不到时间片，帧率直接往下掉。
怎么看CPU占用率？
我个人习惯用两个工具：
- Windows：任务管理器 + Process Explorer（微软官方工具，比任务管理器详细）
- macOS：Activity Monitor（活动监视器）
- Android/iOS：Xcode Instruments 或 Android Studio Profiler
关键看什么？不是看总占用率，而是看WebRTC进程的CPU占用率。总占用率80%但WebRTC只占10%，那问题不在CPU。反过来，总占用率60%但WebRTC占了45%，那就要警惕了。
经验阈值（我自己的判断标准）
- WebRTC进程CPU占用 < 30%：正常，可以继续推流
- 30% ~ 50%：需要关注，建议降低分辨率或帧率
- > 50%：危险，卡顿概率很高，必须优化
- > 70%：基本必卡，建议用户关闭其他应用
我在项目中遇到过一件事：一个用户用i7-1165G7的笔记本推1080p，CPU占用一直在55%左右，偶尔掉帧。我让他把分辨率降到720p，CPU占用直接降到28%，推流就稳了。你想想看，有时候不是设备不行，是配置没给对。
3.2 内存使用率：别让系统开始杀进程
内存问题比CPU隐蔽。CPU高了你能感觉到卡，内存高了系统会悄悄把后台进程杀掉，或者触发OOM（Out Of Memory）。
WebRTC内存消耗主要在哪儿？
- 视频帧缓冲区（特别是多路流场景）
- 编码器内部状态
- 网络抖动缓冲区（Jitter Buffer）
- 渲染管线
我建议重点关注两个指标：
- 物理内存占用率：超过80%就要小心了
- Swap使用量：如果系统开始大量使用交换内存，说明物理内存不够了，性能会急剧下降
避坑指南
我曾经遇到过一个案例：用户手机内存8GB，推流时内存占用只有3GB，按理说没问题。但仔细一看，系统可用内存只剩500MB了——因为后台有十几个应用没关。系统为了保持前台流畅，已经开始杀后台进程了。WebRTC的编码线程被系统降频，帧率直接腰斩。
所以排查内存时，不光要看WebRTC用了多少，还要看系统剩余可用内存。
3.3 GPU编码负载：硬件加速的真相
很多人觉得开了硬件编码就万事大吉。其实不是。GPU编码虽然比CPU编码省资源，但它有自己的瓶颈。
GPU编码负载怎么看？
| 平台 | 工具 | 关键指标 |
|---|---|---|
| Windows | GPU-Z / 任务管理器 | Video Encode 占用率 |
| macOS | Intel Power Gadget / Activity Monitor | GPU Utilization |
| Android | GPU Profiler / Systrace | GPU Frequency & Load |
| iOS | Xcode GPU Frame Capture | Encoder Utilization |
重点看Video Encode（视频编码）这个指标，不是3D渲染占用。很多工具默认显示的是3D负载，那个跟编码关系不大。
我个人的经验是：
- Video Encode 占用 < 60%：正常
- 60% ~ 80%：接近瓶颈，建议降低码率或分辨率
- > 80%：编码器已经满载，会出现编码延迟
这里有个坑：有些GPU的编码器和渲染器共享带宽和缓存。比如你在玩游戏的同时推流，GPU既要渲染游戏画面，又要编码视频流，两者会抢资源。我遇到过用户一边打《原神》一边推流，GPU编码负载只有50%，但游戏画面已经掉帧了——因为编码器占用了太多显存带宽。
小技巧
如果GPU编码负载高但CPU负载低，可以尝试切换编码器。比如从H.264硬编切换到H.265硬编，或者反过来。不同编码器对GPU资源的消耗模式不一样，有时候换个编码器就能解决问题。
3.4 设备温度监控：降频是卡顿的隐形杀手
这个维度很多人会忽略。但说实话，温度导致的降频，是移动端推流卡顿的头号元凶。
为什么会这样？
手机和笔记本都有热管理策略。当设备温度超过某个阈值（通常是70°C~80°C），系统会自动降低CPU和GPU频率来降温。这个过程叫热节流（Thermal Throttling）。
降频之后，编码器拿不到足够的算力，帧率就会掉。而且这种掉帧不是平稳的，是一阵一阵的——温度高了降频，温度低了恢复，然后又高了……形成恶性循环。
怎么监控温度？
- Windows：HWMonitor / Open Hardware Monitor
- macOS：TG Pro / iStat Menus
- Android：CPU-Z / DevCheck（可以读电池温度、CPU温度）
- iOS：Xcode Energy Log（间接看，iOS不开放直接温度读取）
我建议关注两个温度：
- CPU温度：超过85°C就要警惕
- 电池温度：超过45°C说明设备散热压力很大
我曾经踩过的坑
有一次排查一个Android手机的推流卡顿问题，CPU占用只有40%，GPU负载也不高，网络延迟正常。但推流就是每隔30秒卡一次。后来我用DevCheck一看，CPU温度已经92°C了。系统在偷偷降频，但任务管理器里看不出来，因为降频后的CPU占用率反而会下降——你以为负载低了，其实是性能被限制了。
从那以后，我排查卡顿问题必看温度。温度不正常的，先解决散热，再谈优化。
3.5 四维联动：一张图看懂排查逻辑
这四个指标不是孤立的。CPU高了会发热，发热了GPU会降频，降频了编码延迟增加，内存压力也跟着上来。所以排查的时候要联动着看。
下面这张图是我自己总结的排查流程：
3.6 实战排查清单
最后，我整理了一份排查清单。下次遇到推流卡顿，按这个顺序查一遍：
- 打开监控工具：同时看CPU、内存、GPU编码、温度四个指标
- 看CPU占用：WebRTC进程是否超过50%？是→降低分辨率或帧率
- 看内存占用：系统剩余内存是否低于20%？是→关闭后台应用
- 看GPU编码负载：Video Encode是否超过60%？是→切换编码器或降低码率
- 看设备温度：CPU温度是否超过85°C？是→改善散热或暂停推流
- 联动判断：如果多个指标同时异常，优先解决温度问题（因为温度会影响其他所有指标）
我的个人习惯
我一般在推流开始前就先跑一轮监控，记录基线数据。这样卡顿发生时，对比基线就能快速定位是哪个指标异常了。没有基线数据，排查就像大海捞针。
嗯，设备排查这块就这些。记住一句话：设备是推流的根基，根基不稳，上层优化都是白搭。下一层咱们会聊网络层面的排查，但那是建立在设备没问题的基础上的。