📚 课程目录第2章混合对焦架构

2、混合对焦架构：传感器、ISP、马达、算法模块的协同工作流程

混合对焦系统，说白了就是让手机知道“该对哪里”以及“怎么快速对上”。它不是单个模块的独角戏，而是传感器、ISP、马达和算法四个角色紧密配合的团队作战。我最早接触这个架构时，总觉得各模块各司其职就行，后来才发现——协同的节奏一旦乱了，对焦体验直接崩盘。

2.1 整体框架：四层协同模型

我个人习惯把混合对焦系统拆成四层：感知层、决策层、执行层和反馈层。每一层都有明确的职责，但又通过中断和消息队列紧密耦合。

核心原则：算法模块是大脑，ISP是眼睛，马达是手脚，传感器是神经末梢。任何一层延迟超过一帧，整个对焦链路就会“卡顿”。

2.2 传感器与ISP：数据从哪里来

传感器是混合对焦的“眼睛”。它不仅要输出图像数据，还要在像素层面嵌入对焦信息。目前主流方案有两种：

传感器类型	对焦数据来源	典型延迟	我遇到的坑
2×1 OCL（双光电二极管）	每个像素内左右PD信号	0.5~1帧	暗光下PD信号信噪比骤降
4×1 OCL（四光电二极管）	水平和垂直双方向PD	0.5~1帧	数据量翻倍，ISP带宽吃紧
全像素双核对焦	所有像素均可输出PD	0.3~0.5帧	像素串扰导致相位偏移

ISP拿到RAW数据后，会做两件事：一是提取相位检测点的偏移量，二是计算当前画面的对比度统计值。这两个数据会打包成一个对焦元数据帧，通过硬件中断送给算法模块。

我的经验：ISP输出的对焦元数据帧最好带上时间戳。我曾经遇到过一个bug——算法模块收到的PD数据和图像帧对不上号，查了两天才发现是ISP内部FIFO溢出导致数据错位。加上时间戳后，问题一目了然。

2.3 算法模块：大脑怎么决策

算法模块是整个系统的核心。它接收ISP送来的对焦元数据，然后做三件事：

置信度评估——判断当前PD数据是否可信。比如暗光下PD信号噪声大，置信度就低，这时候要切换到对比度辅助。
对焦策略选择——根据场景决定用哪种对焦模式。静止场景用PDAF快速粗对，运动场景用连续AF跟踪，微距场景用对比度精调。
目标位置计算——算出马达应该走到哪个位置，并生成驱动曲线。

这里有个关键点：算法模块不是每帧都重新计算。我习惯用一个状态机来管理对焦流程：

// 简化的对焦状态机伪代码
enum FocusState {
    FOCUS_IDLE,       // 空闲
    FOCUS_SCANNING,   // 粗扫描
    FOCUS_REFINING,   // 精调
    FOCUS_LOCKED,     // 锁定
    FOCUS_LOST        // 失焦
};

void focus_loop(FocusMetaData *meta) {
    switch (current_state) {
        case FOCUS_IDLE:
            if (meta->pd_confidence > 0.7) {
                // PDAF直接跳转到目标位置
                motor_jump_to(meta->pd_target);
                current_state = FOCUS_REFINING;
            }
            break;
        case FOCUS_SCANNING:
            // 全行程扫描，记录对比度峰值
            motor_scan_full_range();
            current_state = FOCUS_REFINING;
            break;
        case FOCUS_REFINING:
            // 小范围微调，直到对比度收敛
            if (contrast_converged()) {
                current_state = FOCUS_LOCKED;
            }
            break;
        // ...
    }
}

注意：状态切换的时机非常敏感。如果从SCANNING切到REFINING太快，可能还没找到真正的峰值点；切太慢，用户会觉得对焦“犹豫”。我一般会在SCANNING阶段记录至少3个峰值候选点，再进入REFINING阶段做二次确认。

2.4 马达驱动：手脚要听话

马达是执行层，负责把算法算出来的位置变成物理位移。目前手机主流马达有两种：

VCM（音圈马达）——成本低、响应快，但存在磁滞和温漂问题。我遇到过VCM在高温下位置偏移超过10μm的情况，直接导致对焦不准。
压电马达——精度高、功耗低，但驱动波形复杂，需要专用驱动IC。压电马达的启动波形如果没调好，会发出“滋滋”的啸叫声。

马达驱动有一个容易被忽略的环节——过冲抑制。算法模块算出的目标位置是理想值，但马达物理运动会有惯性。如果不做处理，马达会冲过头再回来，造成画面“呼吸效应”。

解决方案：在驱动曲线末端加入阻尼段。比如目标位置是500μm，先快速走到480μm，然后以1/4速度慢慢走到500μm。这样既保证了速度，又避免了过冲。

2.5 协同工作流程：一帧的生命周期

我们来看看一帧画面里，四个模块是怎么配合的。以30fps为例，一帧的时间是33ms：

时间点	传感器	ISP	算法模块	马达
T0~T5	曝光并读出RAW	等待数据	处理上一帧反馈	保持位置
T5~T12	空闲	提取PD+对比度	等待元数据	保持位置
T12~T18	空闲	发送元数据	置信度评估+策略选择	保持位置
T18~T25	空闲	空闲	计算目标位置+生成曲线	接收指令
T25~T33	开始下一帧曝光	空闲	发送驱动指令	执行移动

你看，从传感器曝光到马达移动，中间只有不到30ms。如果任何一个环节延迟超标，就会导致对焦跟不上画面变化。我曾在某个项目里发现ISP提取PD数据花了8ms，比预期多了3ms，结果对焦总是慢半拍。后来优化了ISP的DMA传输方式，才把延迟压回5ms以内。

2.6 避坑指南：我曾经踩过的三个坑

坑一：PD数据和图像帧不同步

我曾经在一个项目里发现，算法模块收到的PD数据总是比图像帧早一帧。原因是ISP内部有两个独立的处理管线——一个走图像，一个走PD。两条管线的延迟不一致，导致数据错位。解决方案是在PD元数据里带上帧序号，算法模块做帧对齐。

坑二：马达温漂导致对焦偏移

夏天室外温度40℃，手机连续录像半小时后，VCM马达的磁铁性能下降，位置偏移了15μm。算法模块以为马达在500μm，实际只有485μm。后来我们在算法里加入了温度补偿表，每5℃一个校准点，才解决了这个问题。

坑三：对比度统计值饱和

在强光场景下，画面过曝区域的对比度统计值会饱和，导致算法误判为“已经对焦清晰”。实际上画面是模糊的，只是过曝让边缘看起来锐利。后来我们在ISP里加了过曝检测标志，算法模块看到过曝区域就降低其权重。

2.7 小结：架构设计的核心原则

混合对焦架构设计，说白了就是处理好三个关系：

数据同步——PD数据、对比度数据、图像帧必须严格对齐时间轴。
延迟预算——每个模块的耗时要精确到毫秒级，超时要有降级策略。
异常处理——传感器坏点、马达卡死、ISP溢出，这些异常场景都要有兜底逻辑。