第27章性能优化

课程目录第27章性能优化

27、性能优化：帧率控制、分辨率降级、内存管理技巧

说实话，做WebRTC音视频采集，最怕什么？不是功能实现不了，而是跑起来之后手机发烫、画面卡顿、内存暴涨。我早期做的一个项目，上线第一天就被用户投诉“视频越聊越卡，最后直接闪退”。嗯，那会儿我才真正意识到——性能优化不是锦上添花，而是生死存亡。

这一章，我就把我在帧率控制、分辨率降级、内存管理这三个方向上踩过的坑、总结的经验，一次性讲清楚。

27.1 帧率控制：别让摄像头“拼命干活”

很多人觉得帧率越高越好，30fps不够，非要60fps。其实你想想看，在弱网环境下，高帧率只会让编码器疲于奔命，丢包率飙升，最终用户看到的反而是“幻灯片”。

核心原则：帧率要动态调整，而不是固定死。

我个人习惯的做法是，先根据场景设定一个目标帧率范围：

场景	推荐帧率	说明
普通视频通话	15-24 fps	人眼感知差异不大，节省带宽
屏幕共享（静态内容）	5-10 fps	PPT、文档，没必要高帧率
屏幕共享（动画/视频）	24-30 fps	保证流畅度
弱网环境	8-12 fps	优先保证画面不中断

代码实现上，我通常用 setInterval 或者 requestAnimationFrame 来控制采集循环：

// 帧率控制示例
const targetFps = 20;
const frameInterval = 1000 / targetFps;
let lastCaptureTime = 0;

function captureFrame(timestamp) {
    if (timestamp - lastCaptureTime >= frameInterval) {
        // 执行采集逻辑
        processVideoFrame();
        lastCaptureTime = timestamp;
    }
    requestAnimationFrame(captureFrame);
}
requestAnimationFrame(captureFrame);

我的小技巧： 在移动端，如果检测到设备温度过高，我会主动把帧率降到12fps以下。用户宁愿看到稍微“顿挫”的画面，也不希望手机直接关机。

27.2 分辨率降级：从4K到360p的“逃生通道”

分辨率降级，说白了就是“保命机制”。我在项目中遇到过这样的情况：用户拿着旗舰机，默认开了4K采集，结果网络一波动，整个视频流直接断了。为什么？因为4K的数据量太大，编码器来不及处理，缓冲区溢出。

正确的做法：建立多级分辨率降级策略。

我一般会预设3-4个档位：

最高档： 720p（除非特殊场景，否则不建议上1080p以上）
中间档： 480p（网络轻度波动时切换）
保底档： 360p（网络严重恶化时使用）
极限档： 180p（仅保留音频+极低画质）

触发降级的条件，我建议用这两个指标：

丢包率 > 5%：降一档
编码耗时 > 40ms：降一档

代码实现时，可以利用 MediaStreamTrack.applyConstraints() 动态切换：

// 分辨率降级示例
const resolutions = [
    { width: 1280, height: 720, label: '720p' },
    { width: 854,  height: 480, label: '480p' },
    { width: 640,  height: 360, label: '360p' },
    { width: 320,  height: 180, label: '180p' }
];

let currentLevel = 0;

function downgradeResolution() {
    if (currentLevel < resolutions.length - 1) {
        currentLevel++;
        const next = resolutions[currentLevel];
        videoTrack.applyConstraints({
            width: { exact: next.width },
            height: { exact: next.height }
        }).then(() => {
            console.log(`降级到: ${next.label}`);
        }).catch(err => {
            console.error('降级失败:', err);
        });
    }
}

注意： 不要频繁切换分辨率！每次切换都会触发编码器重建，反而造成卡顿。我一般会设置一个“冷却时间”，至少间隔3秒才能再次降级。

27.3 内存管理：那些年我们泄漏过的ArrayBuffer

内存泄漏是WebRTC开发中最隐蔽的坑。我曾经排查过一个线上问题：用户视频通话30分钟后，内存占用从80MB涨到800MB，最后浏览器直接崩溃。查了两天才发现，是每一帧的 ArrayBuffer 没有被正确释放。

几个最容易踩的内存陷阱：

Canvas帧缓存不释放： 用 canvas.toDataURL() 或 canvas.toBlob() 后，记得手动释放 ImageData 对象。
MediaStream引用未关闭： 停止采集时，一定要调用 track.stop() 并释放所有 MediaStream 引用。
定时器/动画帧未清理： setInterval 和 requestAnimationFrame 在组件卸载时一定要取消。

我总结了一套“内存管理三板斧”：

// 内存管理最佳实践
class VideoProcessor {
    constructor() {
        this.canvas = document.createElement('canvas');
        this.ctx = this.canvas.getContext('2d');
        this.animationId = null;
        this.intervalId = null;
    }

    // 处理每一帧
    processFrame(videoFrame) {
        // 1. 使用完立即释放
        const imageData = this.ctx.getImageData(0, 0, width, height);
        // ... 处理逻辑 ...
        imageData.data = null; // 手动释放

        // 2. 避免创建大量临时对象
        // 坏做法：每次new一个对象
        // 好做法：复用对象池
    }

    // 3. 清理资源
    dispose() {
        if (this.animationId) {
            cancelAnimationFrame(this.animationId);
            this.animationId = null;
        }
        if (this.intervalId) {
            clearInterval(this.intervalId);
            this.intervalId = null;
        }
        // 释放canvas
        this.canvas.width = 0;
        this.canvas.height = 0;
        this.ctx = null;
        this.canvas = null;
    }
}

    核心原则： 谁创建，谁释放。每一帧的临时数据，在下一帧到来之前必须清理干净。

27.4 知识体系总览

下面这张图，是我自己梳理的“WebRTC采集性能优化”核心逻辑。你可以把它当作一个检查清单：

你看，这三个方面其实是联动的。帧率降了，编码压力小了，内存占用自然就降了；分辨率降了，每帧数据量小了，内存分配也少了。我习惯在代码里加一个“健康度评分”，综合这三个指标，自动决策。

避坑指南： 我曾经在降级策略里只考虑了分辨率，没考虑帧率。结果分辨率降到360p了，帧率还跑30fps，CPU占用依然很高。后来改成“先降帧率，再降分辨率”的顺序，效果好了很多。

最后说一句：性能优化没有银弹。你需要在真实设备上反复测试，尤其是那些千元机、老机型。我每次发布前，都会拿一台3年前的手机跑一遍全流程——嗯，那才是真正的“性能试金石”。

📚 课程目录

27、性能优化：帧率控制、分辨率降级、内存管理技巧

27.1 帧率控制：别让摄像头“拼命干活”

27.2 分辨率降级：从4K到360p的“逃生通道”

27.3 内存管理：那些年我们泄漏过的ArrayBuffer

27.4 知识体系总览