18、屏幕共享质量自适应：带宽估计、动态分辨率调整、帧率降级策略
屏幕共享这个功能，说实话，做出来容易，做好很难。
你想想看，用户可能正在共享一个4K的PPT，也可能是一个快速滚动的代码编辑器。网络环境更是千奇百怪——有人在咖啡馆用公共WiFi，有人在高铁上靠手机热点。如果咱们的屏幕共享只用一套固定的参数，那结果就是：要么卡成幻灯片，要么画质糊成马赛克。
所以，质量自适应不是锦上添花，而是刚需。今天我就把这块的核心逻辑和实战经验掰开揉碎讲给你听。
18.1 带宽估计：自适应的基石
没有准确的带宽估计，后面的一切都是空中楼阁。WebRTC内置了带宽估计（Bandwidth Estimation）算法，但说实话，默认配置在屏幕共享场景下经常不够用。
我个人习惯的做法是：不要完全依赖WebRTC内部的估计值，而是自己维护一个“带宽状态机”。
// 伪代码：带宽状态机示例
enum BandwidthState {
HIGH, // > 5Mbps
MEDIUM, // 1-5Mbps
LOW, // 0.5-1Mbps
CRITICAL // < 0.5Mbps
}
function updateBandwidthState(estimatedBitrate) {
if (estimatedBitrate > 5_000_000) return BandwidthState.HIGH;
if (estimatedBitrate > 1_000_000) return BandwidthState.MEDIUM;
if (estimatedBitrate > 500_000) return BandwidthState.LOW;
return BandwidthState.CRITICAL;
}为什么要这么做？因为WebRTC的估计值波动很大，直接用它来调整编码参数，会导致画面频繁闪烁。我在项目中遇到过这种情况：用户共享一个静态文档，结果画面每隔几秒就模糊一下又清晰一下，体验极差。
我的解决方案是：对带宽估计值做滑动窗口平均，并且加入一个“滞回区间”。比如从HIGH降到MEDIUM，需要连续3次估计值都低于4.5Mbps才触发切换。这样能过滤掉瞬时的网络抖动。
RTCRtpReceiver.getStats() 中的 packetsLost 和 roundTripTime。如果丢包率超过5%，即使带宽估计值很高，也应该主动降级。因为高丢包意味着网络拥塞，强行推高码率只会让情况更糟。
18.2 动态分辨率调整：从4K到480p的优雅降级
分辨率调整是质量自适应中最直观的手段。但这里有个坑：不要直接修改摄像头的分辨率。屏幕共享用的是 getDisplayMedia，它的分辨率由用户选择的窗口或屏幕决定，我们改不了。
那怎么办？答案是：在编码器层面做分辨率缩放。
// 通过设置编码器的 scaleResolutionDownBy 参数
const params = sender.getParameters();
params.encoders[0].scaleResolutionDownBy = 2.0; // 缩放到原始分辨率的1/2
await sender.setParameters(params);嗯，这里要注意：scaleResolutionDownBy 的值必须是2的幂次（1.0, 2.0, 4.0...），这是由编码器的实现限制决定的。我曾经踩过这个坑，传了个1.5进去，结果编码器直接罢工了。
我个人建议的分辨率降级策略是这样的：
| 带宽状态 | 缩放系数 | 实际分辨率（以1080p源为例） | 适用场景 |
|---|---|---|---|
| HIGH | 1.0 | 1920x1080 | 有线网络、高质量WiFi |
| MEDIUM | 2.0 | 960x540 | 普通WiFi、4G |
| LOW | 4.0 | 480x270 | 弱WiFi、3G |
| CRITICAL | 8.0 | 240x135 | 极限网络、丢包严重 |
你可能会问：降到240p还能看吗？说实话，如果是共享代码编辑器，确实有点勉强。但如果是共享PPT，文字还是能辨认的。总比卡死强，对吧？
18.3 帧率降级策略：别让动画变成幻灯片
帧率降级是另一个重要手段。但这里有个关键点：屏幕共享的内容类型不同，对帧率的敏感度也不同。
举个例子：共享一个静态的Word文档，15fps和30fps几乎没有区别。但共享一个视频播放窗口或者动画演示，30fps降到15fps，用户立刻就能感觉到卡顿。
所以，我建议的做法是：根据屏幕内容的变化率动态调整帧率。
// 检测屏幕内容变化率
let lastFrameData = null;
let changeCount = 0;
function detectContentChange(frame) {
// 简化版：比较相邻帧的像素差异
const diff = computePixelDifference(frame, lastFrameData);
if (diff > THRESHOLD) {
changeCount++;
}
lastFrameData = frame;
// 如果连续10帧中超过7帧有变化，认为是动态内容
return changeCount > 7;
}
// 根据内容类型调整帧率
function adjustFrameRate(contentType, bandwidthState) {
if (contentType === 'static') {
// 静态内容：优先保分辨率，降帧率
return Math.min(15, getMaxFrameRate(bandwidthState));
} else {
// 动态内容：优先保帧率，降分辨率
return Math.min(30, getMaxFrameRate(bandwidthState));
}
}18.4 综合策略：把三件事串起来
带宽估计、分辨率调整、帧率降级，这三件事不是孤立的。它们需要协同工作。我画了一张图来说明整个决策流程：
整个流程说白了就是三步：
- 看带宽：当前网络能支持多少码率？
- 看内容：屏幕上的东西变化快不快？
- 做决策：根据前两步的结果，决定是降分辨率还是降帧率。
在实际编码中，我建议把这个逻辑封装成一个独立的模块，不要和业务代码耦合。这样方便测试，也方便后续优化。
18.5 实战中的几个坑
最后，分享几个我在实际项目中踩过的坑，希望能帮你少走弯路。
- 坑一：频繁调用 setParameters。每次调整都调用一次
setParameters，会导致编码器重建，产生短暂的黑屏。我的做法是：把调整请求合并，每500ms只执行一次最终的调整。 - 坑二：忽略屏幕共享的“静止检测”。如果用户长时间没有操作屏幕（比如在听别人讲），可以主动把帧率降到5fps甚至1fps，节省大量带宽。等检测到鼠标移动或画面变化时再恢复。
- 坑三：没有考虑多路流的情况。如果同时共享屏幕和摄像头（比如画中画），带宽需要在两路流之间分配。我一般给屏幕共享分配70%的带宽，摄像头30%。
屏幕共享的质量自适应，说难不难，说简单也不简单。核心就是：尊重网络现状，理解内容特性，做出合理的取舍。希望今天的内容对你有帮助。