17、Camera性能优化：内存带宽优化、延迟分析、帧率稳定性调优
各位做车载Camera的朋友，咱们今天聊点硬核的。性能优化这事儿，说白了就是跟硬件要时间、跟内存要带宽。我做了这么多年车载，发现很多团队把精力都花在算法精度上，结果一上实车，帧率掉得亲妈都不认识。嗯，今天我就把内存带宽、延迟分析、帧率稳定性这三个坑，一个一个给你们填上。
17.1 内存带宽优化：别让数据堵在路上
车载Camera系统里，最容易被忽视的瓶颈就是内存带宽。你想想看，一路4K@60fps的RAW数据，带宽轻松超过2GB/s。如果同时处理四路输入，再加上HDR合成、ISP处理、显示输出……总线分分钟被撑爆。
核心原则：减少数据搬运次数，尽量在片上完成处理。
17.1.1 数据格式与压缩策略
我个人习惯，在HAL层就做一次格式转换。比如Sensor输出的是RAW10，我建议直接转成NV12或者P010，而不是在应用层再转。为什么？因为NV12的带宽只有RAW10的一半不到。
| 格式 | 位深 | 每像素带宽 | 适用场景 |
|---|---|---|---|
| RAW10 | 10bit | 1.25 bytes | 原始数据，HDR合成前 |
| NV12 | 8bit | 1.5 bytes | 显示、编码 |
| P010 | 10bit | 2.0 bytes | HDR显示 |
| FP16 | 16bit | 4.0 bytes | 算法处理，慎用 |
我在项目中遇到过，某Tier1坚持用FP16做中间格式，结果四路1080p@30fps就把总线带宽吃掉了80%。后来改成P010，带宽直接砍半，帧率也稳了。
17.1.2 内存池与DMA优化
别每次申请新buffer，用内存池复用。我建议在Camera启动时，就预分配好所有需要的buffer，包括HDR合成用的中间buffer。这样能避免频繁的page fault和cache miss。
// 伪代码：内存池初始化
camera_memory_pool_t *pool = memory_pool_create(4, 1920*1080*2);
// 4路输入，每路2MB的NV12 buffer
// 预分配，避免运行时malloc小技巧：用DMA做buffer搬运时，尽量用scatter-gather模式，避免大块连续内存申请。车载系统跑久了，内存碎片化很严重。
17.2 延迟分析：找到那个拖后腿的环节
延迟分析，说白了就是找到从Sensor曝光到显示输出之间，到底哪一步在磨洋工。我习惯把整个pipeline拆成三段：Sensor端、ISP端、显示端。
17.2.1 延迟拆解方法
我曾经在一个项目里，发现帧率从30fps掉到了22fps。一开始以为是ISP太慢，结果一测，是HAL层在等V4L2的buffer dequeue。嗯，这里要注意：V4L2的poll超时时间设得太长，会导致整体延迟增加。
// 延迟测量示例
struct timespec ts_start, ts_end;
clock_gettime(CLOCK_MONOTONIC, &ts_start);
// 关键操作：dequeue buffer
ioctl(fd, VIDIOC_DQBUF, &buf);
clock_gettime(CLOCK_MONOTONIC, &ts_end);
double latency = (ts_end.tv_sec - ts_start.tv_sec) * 1000.0 +
(ts_end.tv_nsec - ts_start.tv_nsec) / 1000000.0;
// 如果latency > 16ms，说明有问题17.2.2 常见延迟瓶颈
- Sensor曝光时间过长：HDR模式下，长帧曝光可能超过33ms，直接导致帧率减半。
- ISP pipeline stall：3A算法（AE/AWB/AF）计算量太大，阻塞了后续帧处理。
- Buffer queue满：消费者（显示/编码）处理速度跟不上生产者（ISP），导致dequeue等待。
避坑指南：我曾经在调试HDR时，发现长帧和短帧的曝光时间差太大，导致ISP的HDR合成模块一直在等长帧数据。后来我把长短帧的曝光比控制在1:4以内，延迟就降下来了。
17.3 帧率稳定性调优：别让帧率像过山车
帧率稳定性，比帧率绝对值更重要。用户可能感知不到30fps和29fps的区别，但一定能感知到30fps突然掉到15fps再跳回30fps的卡顿。我习惯用jitter（帧间隔抖动）来衡量稳定性。
17.3.1 帧间隔监控
在HAL层，我建议每帧都记录时间戳，然后计算帧间隔。如果帧间隔超过目标帧周期的1.5倍，就要报警。
// 帧间隔监控逻辑
static uint64_t last_timestamp = 0;
uint64_t current_timestamp = get_monotonic_ns();
uint64_t interval = current_timestamp - last_timestamp;
if (interval > 33 * 1000000) { // 30fps目标，33ms周期
// 超过1.5倍，记录异常
log_warning("Frame interval too large: %lu ms", interval / 1000000);
}
last_timestamp = current_timestamp;17.3.2 动态帧率控制
当系统负载高时，我建议不要硬扛30fps，而是主动降帧。比如降到25fps或者20fps，保持帧间隔稳定。这样用户体验反而更好。
我在项目中用过一种策略：当CPU负载超过80%时，自动将HDR模式从3帧合成降为2帧合成，帧率从30fps降到25fps。虽然帧率降了，但jitter从±5ms降到了±1ms，用户反馈反而说更流畅了。
17.3.3 优先级与CPU亲和性
Camera相关的线程，我建议绑定到特定的CPU核心上，并且设置实时优先级。别让其他后台任务抢了Camera的CPU时间。
// 设置线程优先级和CPU亲和性
struct sched_param param;
param.sched_priority = 90;
pthread_setschedparam(thread, SCHED_FIFO, ¶m);
cpu_set_t cpuset;
CPU_ZERO(&cpuset);
CPU_SET(2, &cpuset); // 绑定到CPU2
CPU_SET(3, &cpuset); // 绑定到CPU3
pthread_setaffinity_np(thread, sizeof(cpu_set_t), &cpuset);个人经验：别把所有Camera线程都绑到同一个核心上。我曾经把ISP线程和显示线程绑到CPU0，结果两个线程互相抢资源，帧率反而更不稳定。后来把ISP绑到CPU2，显示绑到CPU3，问题就解决了。
17.4 整体优化框架
下面这张图，是我总结的Camera性能优化框架。从内存带宽到延迟分析，再到帧率稳定性，每一步都有对应的优化手段。
说实话，性能优化没有银弹。每个项目都有自己的瓶颈，关键是要学会用工具去定位问题。我习惯先用systrace看整体pipeline，再用perf看热点函数，最后用GPU profiler看ISP和显示模块的负载。
最后说一句：别为了优化而优化。先跑起来，再测数据，最后动手改。我见过太多团队，一上来就改内存池、改线程优先级，结果改了半天，瓶颈其实在Sensor驱动里。
公众号:蓝海资料掘金营，微信deep3321