3、Camera整体架构：从AP侧到Sensor的链路拆解
做Camera系统这么多年，我经常被问到同一个问题：“按下快门那一下，手机里到底发生了什么？”
说实话，这个问题看似简单，但真要讲清楚，得把整条链路拆开来看。从AP（应用处理器）发出一条指令，到Sensor真正开始曝光，中间经过的每一站，都可能成为性能瓶颈。
今天我们就来彻底走一遍这条路。
3.1 整体链路概览：一条指令的“西天取经”
先看一张我手绘的架构图。这张图我每次带新人必讲，因为它把整个Camera系统的骨架画清楚了。
你看，这条链路其实分两大段：下行控制路径（AP → Sensor）和上行数据路径（Sensor → AP）。
下行路径走的是命令，上行路径走的是图像数据。两条路的速度要求完全不同。
3.2 下行控制路径：命令怎么“下达”到Sensor
先看下行。从App按下快门，到Sensor开始曝光，这条路径上每一层都在做什么？
| 层级 | 组件 | 核心职责 | 典型延迟 |
|---|---|---|---|
| 1 | Camera App | 发起 capture request，设置参数（AE/AF/AWB） | 1-5 ms |
| 2 | Framework | 将 request 序列化，通过 Binder 传给 CameraService | 0.5-2 ms |
| 3 | Camera HAL | 解析 request，配置 stream，调用 vendor 实现 | 1-3 ms |
| 4 | Kernel Driver | 通过 I²C/SPI 写入 sensor 寄存器 | 0.1-0.5 ms |
| 5 | Sensor | 接收触发信号，开始曝光 | 0.01 ms |
我踩过的坑： 曾经有个项目，预览启动总是慢200ms。查到最后，发现是Framework层在每次request里都重新创建了CameraMetadata，导致Binder传输量暴增。后来改成复用metadata对象，延迟直接砍掉150ms。
3.3 上行数据路径：图像怎么“回来”
下行命令发出去之后，Sensor开始曝光。曝光完成后，数据要原路返回。但这条路比下行复杂得多。
为什么？因为数据量大。一张1200万像素的RAW图，12bit位深，单帧数据量接近18MB。如果以30fps跑，每秒要处理540MB的数据。
上行路径的关键节点：
- Sensor 输出：通过 MIPI CSI 接口，以 D-PHY 或 C-PHY 协议传输。我见过很多团队在这里翻车——MIPI lane 数配少了，或者时钟频率没算对，导致带宽不够。
- ISP 接收：ISP 从 MIPI 接口拿到 RAW 数据，开始做坏点校正、黑电平补偿、去马赛克等处理。
- 3A 统计：ISP 在管线中会抽取出 AE/AF/AWB 的统计信息，反馈给 HAL 的 3A 算法。
- HAL 后处理：HAL 拿到 ISP 输出的 YUV 或 RAW 数据后，可能做多帧合成、HDR、美颜等。
- Framework 接收：最终通过 Gralloc Buffer 传递给 App 显示或编码。
注意： 上行路径的瓶颈往往不在Sensor本身，而在内存带宽。我曾经遇到一个案子，ISP输出分辨率是4000x3000，但DDR带宽被GPU占满了，导致ISP的buffer一直pending，帧率直接掉到15fps。最后靠调整系统内存调度策略才解决。
3.4 关键接口：MIPI CSI 和 I²C
整条链路里，有两个接口是“兵家必争之地”。
3.4.1 MIPI CSI（数据通道）
这是Sensor往ISP传数据的通道。说白了就是一组高速差分信号线。
- D-PHY：4 lane 模式下，每 lane 最高 2.5 Gbps，总带宽 10 Gbps。
- C-PHY：3 trio 模式下，每 trio 约 5.7 Gbps，总带宽约 17 Gbps。
- 选型建议：4K60fps 以上建议用 C-PHY，否则 D-PHY 够用。
3.4.2 I²C（控制通道）
这是AP往Sensor写寄存器的通道。速度慢，但够用。
- 标准模式：100 Kbps
- 快速模式：400 Kbps
- 高速模式：3.4 Mbps
- 避坑：I²C 总线上的电容不能太大，否则波形会变形。我见过一块板子因为走线太长，I²C 信号上升沿变缓，导致Sensor寄存器写入失败，开机黑屏。
3.5 实时性关键：Pipeline 深度与延迟
讲完链路，我们聊聊实时性。很多做App的同学不理解：为什么我调了setRepeatingRequest，画面还是卡顿？
原因在于Pipeline深度。现代Camera HAL3架构里，Framework和HAL之间维护着一个request队列。HAL会提前向Sensor下发多个request，形成流水线。
举个例子：
- Pipeline深度 = 3，意味着Sensor里同时有3帧在排队。
- 好处：帧率稳定，不容易断流。
- 坏处：从App修改参数到Sensor生效，需要等3帧的时间。如果每帧33ms（30fps），那就是100ms的延迟。
实战建议： 做实时性优化时，先确认Pipeline深度。如果对延迟敏感（比如扫码、AR），把深度降到1或2。如果对帧率稳定敏感（比如录像），保持深度3或4。
3.6 链路调试：我常用的三板斧
最后分享几个实战技巧。当你发现Camera性能不对劲时，按这个顺序排查：
- 看MIPI眼图：用示波器量MIPI信号，看眼图是否张开。闭合的话，先查PCB走线阻抗。
- 打HAL log：在HAL层打时间戳，看从processCaptureRequest到notifyShutter的耗时。超过10ms就要警惕。
- 查I²C波形：用逻辑分析仪抓I²C总线，看是否有NACK或重试。重试次数多了，帧率直接掉。
我曾经遇到一个奇葩问题： 某款Sensor在低温下I²C通信偶尔失败，导致预览卡顿。查了三天，最后发现是Sensor的VDDIO电压在低温下掉到了1.75V（标准1.8V），I²C高电平阈值不够。加了一颗LDO后解决。
嗯，链路拆解就到这里。记住一句话：下行看延迟，上行看带宽，中间看Pipeline。把这三点抓住了，Camera系统的实时性问题就解决了一大半。