CameraX与端侧AI：跨设备相机体验全面升级

从CameraOne到CameraX：API迁移势在必行

Android相机开发正面临一次重要的API更迭。据Google在技术分享中透露，经典的CameraOne API将被逐步禁用，从明年Android 18开始通过Play政策强制执行。这意味着仍在使用CameraOne的开发者必须迁移到CameraX或CameraTwo。

三个相机库的定位非常清晰：CameraOne已弃用；CameraTwo面向需要低层控制的复杂场景，但开发者需自行处理设备特定配置；CameraX构建在CameraTwo之上，提供一致的API并自动处理设备差异，是大多数开发者的推荐选择。

CameraX的优势体现在四个方面：支持Android 7及以上，覆盖几乎所有活跃设备；为预览、拍照、录制等常见用例提供简洁API；减少设备特定问题，例如折叠屏和平板上的预览拉伸；简化OEM高级能力（如夜景模式、人像模式）的接入。

CameraOne、CameraTwo 与 CameraX 的关系：CameraOne 指旧版 android.hardware.Camera API，自 Android 5.0（API 21）起已标记弃用，其设计难以适配多摄像头、高帧率等现代硬件。CameraTwo 即 android.hardware.camera2，是直接映射相机 HAL 的低层框架，提供逐帧控制与手动参数，但要求开发者自行处理厂商差异、会话配置和兼容性回退。CameraX 是 Jetpack 库，构建在 CameraTwo 之上，用 UseCase（Preview、ImageCapture、VideoCapture）抽象常见场景，内部封装设备兼容性逻辑，并保证跨版本一致的 API 行为。三者并非替代关系而是分层：CameraX 最终仍调用 CameraTwo，因此迁移到 CameraX 通常无需改动底层硬件适配代码。

Adaptive Viewfinder：让预览适配每一种屏幕

设备形态的多样化让相机预览变得棘手。折叠屏展开后，内屏摄像头水平安装，而后置摄像头垂直安装，如果开发者假设所有传感器都是垂直的，就会导致空间错位和画面变形。

CameraX的Adaptive Viewfinder专门解决这一复杂度，确保预览在手机、折叠屏、平板甚至笔记本上无缝工作。开发者只需声明SurfaceRequest变量、在LaunchedEffect中绑定生命周期并安装相机，然后将有效的SurfaceRequest交给CameraXViewfinder，并通过scale参数选择fit或crop模式即可。

在CameraX 1.7中，Viewfinder新增了点击对焦、双指缩放等手势，以及利用屏幕补光的Screen Flash自拍功能。实现方式很简单：启用点击对焦和缩放，并从ScreenFlash的ready回调中获取实例，将闪光模式设为ScreenFlash即可。

XR设备上的相机捕获

Android XR设备分为三类：全封闭的XR头显、透视式XR眼镜（如主题演讲中发布的XR Aura），以及轻量级的音频与显示眼镜。前两类设备像普通手机一样支持Camera2和CameraX，而音频与显示眼镜则是本次分享的重点。

在音频与显示眼镜场景下，Android手机作为宿主设备，同时可访问手机摄像头和眼镜摄像头。区分方式很直观：使用标准Context时，CameraX访问手机摄像头；使用Projected Device Context时，则访问眼镜摄像头。两者的权限也是独立的，需要分别申请。

如果使用Projected Activity（UI投射到眼镜上），规则则相反：标准Context访问眼镜摄像头，要访问手机摄像头需使用宿主Context。代码层面，先通过isProjectedDeviceConnected检查连接状态，再获取Projected Context，并用LifecycleCameraProvider替代ProcessCameraProvider以便随时切换Context，同时需禁用额外的重复流（当前眼镜仅支持单流）。

Projected Context 与宿主设备：在 Android XR 的音频与显示眼镜形态中，眼镜本身算力有限，App 实际运行在通过蓝牙或 Wi-Fi 连接的 Android 手机上，眼镜只承担显示与部分传感器输入。系统为此引入 Projected Device Context，它以虚拟设备的形式暴露眼镜的摄像头、显示等能力；与之对应的 Projected Activity 则把界面渲染到眼镜视场。普通 Context 与 Projected Context 各自对应一套独立的相机权限与设备标识，因此切换 Context 等价于切换相机来源。LifecycleCameraProvider 相比 ProcessCameraProvider 增加了对 Context 变化的感知，能在手机与眼镜之间重新绑定生命周期，这正是 XR 场景必须使用它的原因。

Feature Group API：释放硬件组合的真正潜力

现代相机支持HDR、60fps、视频防抖等众多特性，但单独检查每个特性的支持情况，并不能保证它们能组合工作。这种不确定性迫使开发者保守行事，限制了用户在高端设备上的体验。

Feature Group API提供了两种使用方式：通过Required Feature Group检查并启用受支持的组合，或通过Preferred Feature Group提供特性优先级列表，由CameraX选择设备支持的最佳组合。在演示中，同时开启HDR、60fps和视频防抖后，画面亮度、流畅度和画质都有显著提升。

CameraX 1.6及以上版本已将4K录制和视频防抖纳入Feature Group API，许多高端设备支持两者同时开启。此外，开发者现在还能通过该API应用实时特效，这在过去是无法实现的。

Camera2 的 Stream Combination 与 Feature Group：在 CameraTwo 中，一组同时工作的流能否成立，取决于设备通过 StreamConfigurationMap 声明的 Stream Combination——它列出硬件真正支持的流尺寸、格式与帧率组合，组合数量随摄像头规格增长而爆炸，手工穷举并不现实。Feature Group API 把这一底层约束封装为面向特性的声明：开发者描述“HDR + 60fps + 防抖”这类需求，CameraX 负责在底层组合表中搜索可行解，并在不满足时回退到次优组合。Preferred Feature Group 的优先级列表机制尤其适合需要权衡画质与流畅度的场景，因为设备能力差异被吸收在库内部，应用代码无需按机型分支。

图像捕获与视频录制的进阶能力

CameraX新增了DNG RAW捕获，让开发者可以直接获取传感器输出的未处理、未压缩图像，满足专业编辑需求。夜景模式扩展也迎来升级：新的集成API可监测环境是否昏暗并适合夜景模式，同时支持Ultra HDR，带来更宽的动态范围和更鲜艳的色彩。

运动照片（Motion Photo）将于2027年第一季度登陆CameraX，开发者只需在ImageCapture.builder中设置运动照片模式即可。

高速视频录制方面，CameraX支持120或240fps捕获，提供两种编码方式：以相同帧率编码获得真正的高帧率视频，或以30fps编码生成可直接播放的慢动作视频。例如，以120fps录制1秒，按30fps播放需要4秒，从而形成慢动作效果。启用慢动作后，Google Photos会自动识别并添加慢动作徽章。

并发相机API也得到增强，现在可以在绑定生命周期并打开相机后动态更新构图，包括位置、尺寸、圆角、边框宽度和颜色等样式，以及通过setZOrder调整渲染顺序。

官方强烈建议升级到CameraX 1.6及以上版本，以避免在支持新视频格式的设备上崩溃，并确保在未来的PSO更新中继续工作。为支持迁移，Google还推出了CameraX skill、迁移指南和相机示例仓库。

端侧机器学习：让相机更智能

在图像捕获之后，端侧机器学习可以增强画质或生成描述。ML Kit主要解决视觉和自然语言领域的常见问题，如文字识别、人脸检测和翻译。去年引入的GenAI API借助Gemini Nano，实现了文本摘要、图像描述等能力。在演示中，传入图像位图和文本提示后，模型返回了准确的图像描述，整个过程完全在设备上完成。

Adobe Photoshop已使用Prompt API改善用户体验：自动重命名未整理的图层，并为图像生成说明文字和话题标签。代码流程为：创建生成模型客户端，检查Gemini Nano是否可用或可下载，组合图像与文本提示生成内容请求，最后调用generateContent执行推理。

MediaPipe与ML Kit解决相似问题，但定位不同：MediaPipe跨Android、iOS、Web和Python，支持模型定制且开源；ML Kit仅支持Android和iOS，提供开箱即用的API。MediaPipe的手势识别API可实时检测相机输入中的手势，例如在远处用手势控制录制开始或停止。

通过Google Play Services API提供的端侧图像与视频增强，可在多数高端设备上实现色调映射、去模糊和超分辨率。开发者需先检查设备支持情况并按需安装增强模块，再创建增强选项和客户端会话，最后调用process函数处理位图。视频增强API已集成到Jetpack Media 3。

低光增强（Low Light Boost）分为硬件和软件两个版本：硬件版利用OEM硬件提升暗光帧，软件版（Google Low Light Boost）则使用端侧ML模型。集成到CameraX时，只需将Google低光增强管线包装为CameraEffect，CameraX会自动处理Surface生命周期和路由。该效果将于2026年第四季度在CameraX中推出，届时创建低光增强对象并加入会话配置即可在受支持设备上生效。

Gemini Nano 与 ML Kit 的分工：Gemini Nano 是 Google 面向端侧部署的小参数模型，随 AICore 系统组件分发，不占用应用包体，但仅在部分高端设备上可用，且需要检查可用性或触发按需下载。ML Kit 则是任务导向的 SDK：文字识别、人脸检测、翻译等能力以固定模型和稳定 API 提供，覆盖设备更广。GenAI API 属于 ML Kit 中对接 Gemini Nano 的入口，把生成式能力包装成与传统视觉任务一致的调用方式（创建客户端、构造内容请求、调用 generateContent）。这种分层意味着：确定性识别任务用 ML Kit 传统 API，开放式生成任务才走 GenAI API，并对不可用设备准备降级路径。