预览延迟优化：SurfaceView vs TextureView、预览流配置、BufferQueue机制、GPU合成与显示管线
预览延迟，说白了就是相机从捕捉到画面到显示在屏幕上的时间差。这个差值如果超过100ms，用户就会明显感觉到「卡顿」或「拖影」。我做过一个项目，客户反馈预览画面总是慢半拍，拿手机晃一下，画面要过一会儿才跟上。后来一查，问题出在预览流配置上——用了TextureView，而且没处理好BufferQueue的背压。
这一章，我们就来拆解预览延迟的各个环节。我会从SurfaceView和TextureView的选择讲起，再到预览流配置、BufferQueue机制，最后聊GPU合成与显示管线。每个环节都可能成为瓶颈。
SurfaceView vs TextureView：谁更适合预览？
很多开发者上来就问：「SurfaceView和TextureView到底选哪个？」我的回答是：看场景。但如果你追求低延迟，SurfaceView是更稳妥的选择。
核心区别：SurfaceView拥有独立的Surface，直接在系统层面合成；TextureView则是在View层级内绘制，需要经过GPU合成。
为什么会这样？SurfaceView的Surface是独立于应用窗口的。它由SurfaceFlinger直接管理，合成时不需要经过应用层的View绘制流程。而TextureView本质是一个View，它把Surface的内容作为纹理，通过OpenGL ES绘制到View上。这中间多了一层纹理上传和GPU绘制。
我记得有一次，在某个低端设备上测试预览延迟。用TextureView时，延迟稳定在120ms左右；换成SurfaceView后，降到了60ms。差距就是这么明显。
| 特性 | SurfaceView | TextureView |
|---|---|---|
| 独立Surface | 是 | 否 |
| 合成方式 | SurfaceFlinger直接合成 | GPU纹理绘制 |
| 延迟表现 | 低（约40-80ms） | 较高（约80-150ms） |
| 动画/变换支持 | 差（需额外处理） | 好（原生支持） |
| 适用场景 | 相机预览、视频播放 | 需要动画效果的预览 |
我的建议：如果只是做普通相机预览，没有复杂的缩放、旋转动画，直接用SurfaceView。延迟低，省电，还省GPU资源。
预览流配置：别让配置成为瓶颈
预览流配置，很多人觉得不就是setPreviewSize吗？其实没那么简单。你想想看，预览流从Camera HAL到应用层，再到显示层，中间经过了多少个缓冲区？每个缓冲区的大小、格式、帧率，都会影响延迟。
我个人习惯，配置预览流时重点关注三个参数：
- 分辨率：不要一味追求高分辨率。1080p预览在大多数设备上已经足够，4K预览会显著增加延迟和功耗。
- 帧率：30fps是平衡点。60fps虽然流畅，但处理时间窗口只有16.7ms，很容易丢帧。
- 格式：NV21或YUV420_888是主流。有些设备对NV21有硬件加速，延迟更低。
我曾经在一个项目中，把预览分辨率从4K降到1080p，延迟直接减少了40ms。为什么？因为4K的缓冲区大小是1080p的4倍，BufferQueue的传输时间、GPU的合成时间都成倍增加。
// 推荐配置示例
CameraCharacteristics characteristics = cameraManager.getCameraCharacteristics(cameraId);
StreamConfigurationMap configMap = characteristics.get(CameraCharacteristics.SCALER_STREAM_CONFIGURATION_MAP);
// 选择1080p预览
Size previewSize = new Size(1920, 1080);
// 检查是否支持
if (configMap.getOutputSizes(SurfaceHolder.class).contains(previewSize)) {
previewRequestBuilder.set(CaptureRequest.CONTROL_AE_TARGET_FPS_RANGE, new Range<Integer>(30, 30));
// 设置预览Surface
previewRequestBuilder.addTarget(previewSurface);
}
注意：不要同时开启多个高分辨率流。比如预览用4K，拍照也用4K，录像还用4K。这会导致Camera HAL的ISP带宽不足，延迟飙升。我见过一个案例，三个4K流同时跑，预览延迟直接到了300ms。
BufferQueue机制：理解背压与丢帧
BufferQueue是Android图形系统的核心。它连接了生产者（Camera HAL）和消费者（SurfaceView/TextureView）。说白了，就是一个缓冲区队列。
流程是这样的：Camera HAL填充一个缓冲区，放入队列；SurfaceFlinger从队列取出，合成显示。如果生产者太快，消费者来不及处理，队列就会满。这时候有两种策略：
- 阻塞：生产者等待消费者处理完，再继续生产。这会导致预览帧率下降。
- 丢帧：生产者直接丢弃新帧，保持队列长度。这会导致画面跳跃。
我个人更倾向于丢帧策略。为什么？因为预览是实时场景，用户对偶尔丢一帧的感知，远低于对持续卡顿的感知。你想想看，画面突然慢下来，比偶尔跳一下更让人难受。
我曾经在调试一个设备时，发现预览帧率只有15fps。一查BufferQueue，队列长度一直是最大值。原来是消费者（SurfaceView）处理太慢，生产者被阻塞了。后来我调整了BufferQueue的容量，从默认的4个缓冲区减到2个，并启用了丢帧模式。帧率恢复到了30fps，虽然偶尔丢帧，但整体体验好多了。
// 设置BufferQueue参数（需在Surface创建时配置）
Surface surface = new Surface(surfaceTexture);
// 设置缓冲区数量为2，减少延迟
surface.setBuffersCount(2);
// 启用丢帧模式
surface.setDropBuffers(true);
关键点：BufferQueue的缓冲区数量不是越多越好。2-3个缓冲区是平衡延迟和稳定性的最佳选择。太多会增加延迟，太少容易丢帧。
GPU合成与显示管线：最后的冲刺
预览数据从BufferQueue出来后，进入显示管线。这里涉及两个关键环节：GPU合成和显示刷新。
GPU合成，就是把多个图层（比如预览画面、UI控件、状态栏）合成一帧。如果预览画面是TextureView，它需要先通过GPU把纹理绘制到View上，再参与合成。多了一步纹理上传，延迟自然增加。
显示刷新，就是屏幕从缓冲区读取数据并显示。Android的显示管线是双缓冲或三缓冲机制。双缓冲下，一个缓冲区显示，另一个缓冲区准备。三缓冲则多一个缓冲区，减少等待。
我建议在预览场景下使用三缓冲。虽然多占一个缓冲区，但能有效减少因显示刷新等待导致的延迟。特别是当预览帧率和屏幕刷新率不匹配时，三缓冲能平滑过渡。
// 在SurfaceView中启用三缓冲
SurfaceView surfaceView = new SurfaceView(context);
surfaceView.getHolder().setFormat(PixelFormat.TRANSLUCENT);
// 通过SurfaceFlinger设置三缓冲（需系统权限）
// 实际开发中，可通过SurfaceControl设置
小技巧：如果设备支持，可以尝试将预览帧率与屏幕刷新率同步。比如屏幕是60Hz，预览也设为60fps。这样每一帧都能立即显示，没有等待时间。但要注意，60fps对处理能力要求高，低端设备可能扛不住。
整体优化思路
说了这么多，我们来总结一下预览延迟优化的整体思路。我画了一张图，方便你理解各个环节的关系。
从图中可以看到，预览延迟是多个环节累积的结果。每个环节都可能成为瓶颈。我的优化思路是：先定位瓶颈，再针对性优化。
具体来说：
- 先测延迟分布：用Choreographer或dumpsys SurfaceFlinger查看各环节耗时。
- 再选对组件：SurfaceView优先，除非你需要动画效果。
- 配置要合理：分辨率、帧率、缓冲区数量，都要根据设备能力来。
- 最后调显示：三缓冲、帧率同步，这些是锦上添花。
避坑指南：我曾经在一个项目里，把所有优化手段都用上了，结果延迟还是高。最后发现是Camera HAL的ISP处理时间太长。你想想看，HAL层就占了50ms，应用层再怎么优化也没用。所以，一定要从源头开始排查。
预览延迟优化，说白了就是一场「时间赛跑」。每个环节省几毫秒，累积起来就是几十毫秒的提升。希望这一章的内容能帮你理清思路，少走弯路。
公众号:蓝海资料掘金营，微信deep3321