第2章：AF系统架构——硬件与软件的协同工作流程
自动对焦这事儿，说白了就是一套「硬件干活、软件指挥」的闭环系统。我刚开始接触AF时，总觉得它就是个马达转一转的事。后来踩了不少坑才明白——硬件选型决定了下限，软件调度决定了上限。今天咱们就把这套架构拆开看看。
2.1 硬件组成：四个关键角色
AF系统的硬件，核心就四样东西：VCM马达、Driver IC、Lens、Sensor。它们各司其职，缺一不可。
2.1.1 VCM马达——执行者
VCM（Voice Coil Motor）说白了就是个电磁线圈。通电后产生磁场，推动镜头上下移动。我见过不少工程师只关注马达的行程范围，却忽略了它的线性度。嗯，这里要注意——马达的响应曲线不是完美的直线，尤其在两端。
关键参数：
- 行程范围：通常200-400μm
- 谐振频率：一般在50-200Hz之间
- 线性度：偏差应小于5%
- 迟滞效应：正反向行程的差异
我在项目中遇到过一款马达，标称行程300μm，实际跑到280μm就开始非线性了。当时排查了整整两天，最后发现是马达的磁路设计有问题。所以选型时，一定要看实测曲线，别只看规格书。
2.1.2 Driver IC——指挥官
Driver IC负责把数字信号转换成模拟电压，驱动VCM马达。它通常集成在摄像头模组里，通过I2C接口与主控通信。
常见的Driver IC有DW9714、AK7345等。它们支持的功能差异很大——有的只支持开环控制，有的支持闭环，还有的带霍尔传感器反馈。
我的建议：如果项目预算允许，尽量选带闭环控制的Driver IC。虽然贵几毛钱，但能省掉后期大量调试时间。我曾经在一个低端项目上用了开环方案，结果温度一变化，对焦位置就飘了，最后不得不加温度补偿算法，反而更麻烦。
2.1.3 Lens——光学核心
镜头本身不参与运动控制，但它的光学特性直接影响AF效果。关键参数包括：
| 参数 | 影响 |
|---|---|
| 焦距 | 决定对焦范围 |
| 光圈 | 影响景深和进光量 |
| MTF曲线 | 决定解析力随位置的变化 |
| 色差 | 不同波长光的焦点偏移 |
你想想看，如果镜头本身的MTF曲线就很平缓，那AF算法再怎么优化也找不到清晰的峰值。这就是为什么我常说——AF调试要从镜头选型开始。
2.1.4 Sensor——眼睛
Sensor负责采集图像数据，提供给AF算法做清晰度评价。它通过MIPI接口把原始RAW数据传给ISP。
这里有个容易被忽略的点：Sensor的帧率和读出速度决定了AF的响应延迟。我见过有人用30fps的Sensor做快速对焦，结果每次对焦都要等33ms才能拿到下一帧数据，用户体验很差。如果做视频追焦，建议至少60fps起步。
2.2 软件架构：三层协同
软件部分分为三层：Kernel驱动、HAL层、算法库。它们像接力赛一样，一层层传递数据和指令。
2.2.1 Kernel驱动——硬件接口
Kernel驱动负责最底层的硬件操作。它通过I2C读写Driver IC的寄存器，控制马达位置。同时通过V4L2框架向上层提供标准接口。
// 典型的VCM驱动代码片段
static int vcm_set_position(struct v4l2_subdev *sd, u16 pos)
{
struct vcm_device *vcm = to_vcm_device(sd);
u8 buf[2];
// 将位置值写入寄存器
buf[0] = (pos >> 8) & 0xFF;
buf[1] = pos & 0xFF;
return i2c_master_send(vcm->client, buf, 2);
}驱动层最头疼的问题是时序。我记得有一次，驱动写寄存器太快，Driver IC还没准备好就收到了下一个指令，导致马达乱跳。后来加了个5ms的延时才解决。
2.2.2 HAL层——承上启下
HAL层（Hardware Abstraction Layer）是Android系统里的概念，但在Linux平台上也有类似的抽象层。它负责把算法库的计算结果转换成驱动能理解的指令。
HAL层主要做三件事：
- 管理AF的状态机（空闲、对焦中、锁定等）
- 协调算法库和驱动的数据交互
- 处理不同厂商的硬件差异
避坑指南：我曾经在HAL层犯过一个低级错误——没有做状态机保护。结果算法库还在计算时，用户又触发了新的对焦请求，导致两个线程同时操作马达，直接烧了Driver IC。从那以后，我所有项目都加了互斥锁。
2.2.3 算法库——大脑
算法库是整个AF系统的核心。它接收Sensor传来的图像数据，计算清晰度评价函数（比如对比度、相位差），然后决定马达该往哪个方向走、走多少步。
常见的算法包括：
- 爬山算法：最经典，通过比较相邻帧的清晰度值来寻找峰值
- 全局搜索：遍历整个行程，找到最清晰位置
- 混合算法：先粗搜再细搜，兼顾速度和精度
算法库的调试是最磨人的。你想想看，同样的算法在不同光照、不同场景下表现天差地别。我习惯在算法库里加一个调试模式，把每一步的清晰度值、马达位置都打印出来，这样能直观看到算法在干什么。
2.3 协同工作流程
好了，硬件和软件都介绍完了。它们是怎么配合工作的？我画个流程图给你看：
- 触发对焦：用户点击屏幕或场景变化触发AF请求
- HAL层启动：HAL层收到请求，初始化状态机，通知算法库开始计算
- 采集图像：算法库通过HAL层请求Sensor输出一帧RAW数据
- 计算清晰度：算法库分析图像，得到当前清晰度值
- 决策：算法库根据当前值和历史值，决定下一步马达位置
- 下发指令：HAL层把目标位置传给Kernel驱动
- 驱动执行：Kernel驱动通过I2C写入Driver IC寄存器
- 马达移动：Driver IC输出对应电压，VCM马达推动镜头
- 等待稳定：等待马达稳定（通常需要几毫秒到十几毫秒）
- 循环：回到第3步，直到找到最清晰位置或超时
这个流程看起来简单，但实际跑起来问题很多。比如第9步的等待时间——太短了马达还没稳定，图像是模糊的；太长了又影响对焦速度。我一般会根据马达的谐振频率来算，大概取3-5个振荡周期的时间。
核心要点：整个AF系统的延迟 = 图像采集延迟 + 算法计算延迟 + 马达响应延迟。优化任何一个环节都能提升对焦速度，但瓶颈往往在最短的那块板上。
嗯，这一章的内容就到这里。硬件和软件的协同，说白了就是「快、准、稳」三个字。快——响应要迅速；准——位置要精确；稳——不能来回震荡。下一章咱们会深入讲AF算法，到时候再细聊爬山法的那些坑。