一、Camera新硬件技术全景概览

各位同学，今天我们来聊聊Camera领域最前沿的几个硬件技术。说实话，这几年手机摄像头的发展速度，比我刚入行那会儿快了不止一个量级。从屏下摄像头到折叠屏，从潜望式长焦到ToF深度感知，每一个技术背后都藏着驱动工程师的血泪史。

我个人习惯把新硬件技术分成三类：结构创新（UDC、折叠屏）、光学创新（潜望式）、感知创新（ToF/Depth）。这三类技术对驱动层的挑战完全不同，但有一个共同点——它们都在挑战传统Camera HAL的架构边界。

二、Under Display Camera（UDC）驱动适配

2.1 UDC的技术本质

UDC说白了就是把摄像头藏在屏幕下面。听起来简单，但做起来坑特别多。屏幕像素本身是不透明的，要让光线穿过屏幕到达Sensor，需要在屏幕对应区域降低像素密度，或者改变像素排列方式。

我记得第一次拿到UDC模组时，第一反应是「这画面怎么跟蒙了一层纱似的？」后来才明白，屏幕像素的衍射效应是绕不开的物理限制。

2.2 UDC驱动关键点

• 像素补偿表（LUT）：屏幕每个像素位置对光线的衰减系数不同，需要预先生成补偿查找表。我建议在Sensor的otp中存储这个表，而不是放在文件系统里——你想想看，万一用户刷机把文件弄丢了怎么办？
• 衍射校正：在ISP pipeline中增加一个专门的校正模块。说白了就是做一个空间可变的高通滤波器，但系数要根据屏幕像素排列动态计算。
• 亮度同步：屏幕亮度变化时，Sensor的增益和曝光时间需要联动调整。这个逻辑我建议放在HAL的Stream配置阶段，而不是在3A算法里——否则会有明显的延迟。

三、折叠屏Camera适配

3.1 屏幕比例变化的挑战

折叠屏最头疼的问题是什么？屏幕比例变了！展开是4:3，折叠是16:9，甚至有些设备还有1:1的副屏模式。传统Camera HAL假设预览窗口比例是固定的，但折叠屏把这个假设打破了。

我个人习惯的做法是：在HAL层维护一个「显示模式状态机」。每次屏幕比例变化时，HAL需要重新协商Stream配置——包括分辨率、裁剪区域、以及最重要的，Sensor的binning模式。

3.2 适配策略

嗯，这里要注意：切换分辨率时不能直接关闭Camera再重新打开，那样会有黑屏闪烁。我建议的做法是使用HAL的configureStreams接口做动态切换，配合flush操作清空buffer队列。

// 伪代码：折叠屏模式切换
status_t CameraHAL::onDisplayModeChanged(display_mode_t mode) {
    // 1. 暂停预览流
    mPreviewStream->flush();
    
    // 2. 根据新模式重新计算分辨率
    stream_config_t newConfig;
    newConfig.width = getWidthForMode(mode);
    newConfig.height = getHeightForMode(mode);
    newConfig.format = HAL_PIXEL_FORMAT_YCbCr_420_SP;
    
    // 3. 重新配置Stream
    mStreamPipeline->configure(&newConfig);
    
    // 4. 重启预览
    mPreviewStream->start();
    
    return OK;
}

四、潜望式长焦马达驱动

4.1 潜望式结构的特殊性

潜望式长焦和普通VCM马达最大的区别在于：光路是折返的。光线经过棱镜反射后进入Sensor，这意味着马达不仅要控制对焦，还要控制棱镜的角度——也就是OIS防抖。

我记得第一次调试潜望式马达时，发现AF和OIS是耦合的。对焦时棱镜位置变化会影响OIS的零位，反过来OIS动作也会改变对焦行程。说白了，这就是一个两轴联动的控制问题。

4.2 驱动适配要点

• 马达类型识别：潜望式常用步进马达或SMA（形状记忆合金）。步进马达需要脉冲控制，SMA需要电压控制。我建议在驱动层做一层抽象，把马达控制接口统一成moveTo(position, speed)。
• 校准数据管理：每个模组都有独特的校准参数——包括AF行程、OIS灵敏度、棱镜零位偏移。这些数据我习惯放在Sensor的EEPROM里，驱动初始化时一次性读取。
• 联动控制算法：AF和OIS的联动解耦，建议在HAL层的算法模块中实现，而不是在驱动层。驱动层只负责发指令，算法层负责计算补偿量。

五、ToF/Depth Camera驱动

5.1 ToF的工作原理

ToF（Time of Flight）说白了就是「发射光→接收反射光→计算时间差→得到距离」。但实际实现比这复杂得多。ToF Sensor通常包含一个VCSEL激光发射器和一个SPAD或CMOS接收器。

驱动ToF Sensor和普通RGB Sensor最大的区别在于：你需要控制激光的发射时序，并且要精确同步接收器的曝光窗口。这个时序控制如果做不好，深度图就会出现严重的噪声。

5.2 驱动适配关键点

六、实战：适配屏下摄像头Sensor

6.1 实战背景

好了，前面讲了那么多理论，我们来动真格的。假设你拿到了一颗屏下摄像头Sensor，型号是OV16E1Q（虚构），屏幕是三星的E6 OLED。你的任务是把这颗Sensor适配到Android HAL中，让Camera App能正常预览和拍照。

6.2 适配步骤

1. 第一步：读取Sensor ID

   通过I2C读取Sensor的CHIP_ID寄存器，确认模组通信正常。我习惯在驱动初始化时打印这个ID，方便调试。

   // 读取Sensor ID示例
   uint16_t chip_id = i2c_read_word(sensor_addr, 0x0000);
   if (chip_id != 0x16E1) {
       ALOGE("Sensor ID mismatch: expected 0x16E1, got 0x%04x", chip_id);
       return -ENODEV;
   }

2. 第二步：配置屏幕像素补偿表

   从Sensor的OTP中读取补偿LUT，加载到ISP的校正模块。注意：补偿表是屏幕相关的，换屏幕型号必须重新校准。

3. 第三步：设置衍射校正参数

   在ISP pipeline中插入一个空间可变滤波器。滤波器的系数根据屏幕像素排列和当前亮度动态计算。我建议把这个计算放在HAL的processCaptureRequest中，而不是在驱动层——因为驱动层没有足够的计算资源。

4. 第四步：亮度同步调试

   监听屏幕亮度变化事件，同步调整Sensor的曝光参数。这里有个技巧：不要直接修改AE的目标亮度，而是修改Sensor的模拟增益范围——这样响应更快。

5. 第五步：验证和调优

   拍摄标准测试图卡，检查MTF（调制传递函数）和色彩还原度。UDC的MTF通常比普通摄像头低20-30%，这是正常的。但如果色彩偏差超过5%，就需要调整白平衡的参考光源。

6.3 常见问题排查

• 预览画面偏暗：检查屏幕像素补偿表是否正确加载。我曾经遇到OTP读取时序不对，导致补偿表全零，画面自然暗得没法看。
• 画面有网格纹：屏幕像素的衍射效应没校正到位。试试调整空间滤波器的截止频率，或者增加一个去马赛克后处理步骤。
• 拍照和预览亮度不一致：拍照时屏幕亮度可能变化（比如闪光灯预闪），导致Sensor曝光参数和预览时不同。解决方案是在拍照前锁定屏幕亮度。

公众号:蓝海资料掘金营，微信deep3321