屏幕共享为什么会卡：从 ReplayKit、TCP 退化到端到端 QoS

“服务器带宽够”不等于屏幕共享流畅

实时会议里最容易被误判的问题，是摄像头画面正常、服务器带宽也有余量，于是把屏幕共享冻结归结为偶发网络波动。实际上，一条屏幕轨要经过采集、像素转换、编码、上行、SFU 转发、下行和解码，任何一个环节的短时拥塞都会表现为花屏、冻结或恢复缓慢。

屏幕内容还具有文字边缘清晰、画面静止时间长、操作时变化突然等特点。它和摄像头连续运动的画面并不相同，沿用同一套码率、帧率和统计方法，往往看不到真正的瓶颈。

先建立证据链，再调整参数

有效的排障不是先改 SFU 参数，而是把每一段链路的数据对应起来。发布端要观察实际编码帧率、输出码率、编码时间、丢包重传和关键帧请求；观看端要观察解码帧、冻结次数、抖动缓冲和接收码率；连接层还要确认候选协议、往返时延和是否从 UDP 退化到 TCP。

统计必须按屏幕轨和摄像头轨分别采集，并缩短采样窗口。只看一分钟平均值，很容易把持续 1～3 秒、但用户感知非常明显的冻结抹平。

采集层：输入尺寸、实际帧率、帧是否按时送入编码器。
编码层：编码耗时、目标与实际码率、关键帧频率。
传输层：RTT、丢包、NACK/PLI、UDP/TCP 候选协议。
观看层：解码帧率、冻结、抖动缓冲和渲染延迟。

ReplayKit 管线可能比网络更早到达上限

iOS 屏幕共享通常由 ReplayKit Broadcast Extension 采集。如果扩展先把原始帧做软件 JPEG 编码，再经 IPC 传给主 App 解码，最后交给 WebRTC 再编码，CPU、内存复制和温控压力会在网络发送前就累积。此时提高服务器带宽没有效果，甚至可能因为更高目标码率进一步放大终端负载。

更稳妥的方向是减少不必要的重复编解码和跨进程拷贝，持续记录采集时间戳与编码耗时，并在温控或 CPU 压力升高时主动降低分辨率与帧率。

TCP 退化为何会产生“卡住再追帧”

实时媒体在高 RTT 或跨境链路上退化到 TCP 后，丢失的数据包会阻塞后续数据交付，形成队头阻塞。用户看到的现象通常不是均匀变差，而是画面突然停住，随后快速追帧恢复。

因此生产部署要明确检查 UDP 可达性、ICE 候选结果和 TURN 策略，不能只验证 TCP 端口能够连接。连接成功只是最低标准，候选协议是否适合实时媒体同样重要。

一套可落地的稳定策略

移动屏幕共享先收敛到稳定的 720p、15fps 与可控码率，再逐步向上试探。
避免会议进行中频繁销毁和重建媒体轨道，优先在现有轨道上调整参数。
以真实弱网、前后台切换、温控和长时间会议进行回归，不只做理想网络冒烟测试。
把端到端指标与用户可感知事件关联，形成可以复现和比较的 QoS 记录。

结论

屏幕共享优化的核心不是找到一个“万能码率”，而是建立端到端可观测性。只有先确认问题发生在采集、编码、上行、SFU、下行还是解码阶段，参数调整才有意义，优化结果也才能被重复验证。