162、实时性与延迟优化：从sensor到显示的端到端流水线加速去年在车载环视项目上，客户反馈了一个让我半夜惊醒的问题：倒车影像从挂入R挡到屏幕亮起，整整花了800ms。客户的原话是“这车停得我心跳加速”。更诡异的是，同样的硬件平台，我们的延迟比竞品多了300ms。那段时间我几乎把整个pipeline的每一行代码都翻了一遍，最后发现罪魁祸首居然是一个看起来人畜无害的帧同步信号处理——一个sleep(1)被写成了sleep(1000)。别笑，这种低级错误在高压项目里太常见了。延迟到底藏在哪端到端延迟的测量，很多人上来就盯着sensor的帧率。帧率确实重要，但它是延迟的下限，不是上限。真正的延迟是sensor曝光开始到显示最后一帧像素刷到屏幕的时间。我习惯把这个路径切成四段：sensor侧延迟、ISP处理延迟、算法处理延迟、显示刷新延迟。sensor侧最容易踩坑的是曝光时间和读出时间的重叠关系。全局快门和卷帘快门的延迟特性完全不同。卷帘快门下，最后一行像素的读出时间决定了帧的完成时刻，如果你在帧完成中断后才开始处理，已经白白浪费了一行的读出时间。这里有个优化点：在最后几行还在读出时就开始处理前面已经完成的行数据。别等整帧ready，流水线要像工厂流水线一样，半成品就开始加工。ISP处理延迟是很多人忽视的重灾区。3A统计、去噪、锐化、色彩校正，每个模块都在吃时间。我见过一个团队把去噪算法放在3A统计之前，理由是“去噪后统计更准”。逻辑没错，但代价是3A统计要等去噪完成，去噪又要等整帧数据，整帧数据又要等sensor读出。这一串串下来，延迟直接翻倍。正