Chapter 186: Camera Pipeline, ISP Tuning, Computational Photography

同一颗相机传感器放到两台手机里，最终照片可能呈现完全不同的曝光、肤色、噪声、锐度、夜景亮度和人像边缘。原始设备制造商（Original Equipment Manufacturer，OEM）的影像能力差异，首先体现在这条拍摄链路里。这种差异来自一条很长的系统路径：默认相机 App 把拍摄意图变成 capture request，framework 把请求交给 CameraService，硬件抽象层（Hardware Abstraction Layer，HAL）把通用请求翻译成厂商管线控制，driver、图像信号处理器固件（Image Signal Processor firmware，ISP firmware）、sensor、lens actuator、神经网络处理单元（Neural Processing Unit，NPU）、图形处理器（Graphics Processing Unit，GPU）和算法库共同完成采集、融合、调色和输出。

本章讨论 OEM 相机差异的系统来源。读完本章后，读者应能把“这台手机拍照更亮”“第三方相机少了夜景”“视频预览和成片颜色不同”“更新后人像边缘变差”这类现象，定位到硬件模组、Camera HAL、3A、ISP tuning、计算摄影算法、默认相机私有能力、兼容性测试和系统策略中的具体责任边界。

本章的贯穿材料是一张夜景人像照片。用户打开默认相机，选择夜景人像模式，取景器先显示低噪声预览，按下快门后手机短暂停留，最终图库里出现一张背景明亮、人物脸部稳定、边缘虚化、天空噪声被压低的照片。这个结果看起来像一次拍照，系统内部实际包含多帧采集、3A 锁定、光学防抖（Optical Image Stabilization，OIS）/电子防抖（Electronic Image Stabilization，EIS）稳定、RAW/YUV 处理、高动态范围（High Dynamic Range，HDR）合成、降噪、肤色映射、景深分割和最终编码。

公开材料能确认 Android Camera HAL 将高层 camera framework API 连接到底层 camera driver 和硬件；Android Camera HAL3 把相机建模成“请求一帧、返回结果和一组 buffer”的 pipeline，并通过元数据（metadata）表达 sensor、lens、3A、处理参数和实际结果。相关边界可参考 Android Camera HAL、3A modes and state transition、Metadata and controls 与 Camera2 overview。厂商的 ISP firmware、tuning 参数、私有算法库和默认相机功能通常属于闭源实现，正文会把这些内容作为平台行为推断和工程边界分析处理。

186.1 Camera Pipeline 作为 OEM 技术差异核心

Camera Pipeline 指一次拍摄从 App 意图进入系统，到 sensor 曝光、ISP 处理、算法融合、结果 buffer 返回，再到图库保存的完整路径。它解决的问题是把硬件的光学和电信号能力包装成可授权、可调度、可测试、可兼容的系统能力。OEM 影像差异的核心在于：同一个 Android camera framework 给出相似 API 表面，厂商在 HAL、ISP tuning、算法库、默认相机和系统策略中放入自己的成像选择。

夜景人像模式可以作为观察入口。用户看到的按钮属于默认相机 App；App 选择的模式会变成一组 capture request、session 参数和私有扩展参数；CameraService 管理 camera device、权限、并发和 stream 配置；Camera HAL 将这些请求映射到具体 sensor 曝光序列、ISP pipeline、buffer 输出和 metadata；厂商算法库再对多帧结果执行配准、融合、降噪、分割和虚化。最终照片的“亮、稳、干净、讨好眼睛”来自多层共同结果。

这条路径可以按责任主体拆开：App 负责表达拍摄模式和输出目标；framework 负责公开 API、权限入口、session 与 request 抽象；CameraService 负责设备所有权、并发访问、错误回调和 framework 到 HAL 的调度；HAL 负责把通用控制项翻译成厂商设备控制；driver 和 firmware 负责 sensor、lens、OIS、ISP、flash 的底层时序；算法层负责 scene detection、多帧融合、人像分割和风格化输出。用户只看到一张照片，工程分析要把照片拆回这些边界。

下面的图只描述本章讨论的 Android OEM 相机主路径，省略图库、媒体扫描、相册云同步和社交 App 压缩。

图中的关键点是请求和结果分离。App 提交的是意图和参数，硬件返回的是 buffer 与 metadata。metadata 记录曝光时间、ISO、frame duration、3A 状态、色彩空间、lens shading 等结果信息。它使第三方 App 和系统调试能够知道 HAL 实际采用了哪些参数，也使 Camera CTS（Compatibility Test Suite，相机相关兼容性测试）、ITS（Image Test Suite，图像测试套件）和扩展验证工具能检查接口行为。

OEM 影像质量的讨论应先看 pipeline，而后看单点能力。大底 sensor、强 ISP、优秀镜头、稳定 OIS、精细 tuning、成熟多帧算法、默认相机交互和发热控制都能改变结果。单独比较像素数、ISP 算力或算法名称，无法解释预览延迟、成片等待、夜景运动模糊、第三方 API 缺功能和系统更新后风格变化。

186.2 Camera HAL 与 Driver / ISP / Sensor 的厂商实现边界

Camera HAL 是 framework 与厂商相机实现之间的稳定边界。Android 8.0 以后 Treble 推动 HAL 接口稳定化；Treble 是 Android 把 framework 与 vendor implementation 分离的系统架构约束。Android 13 以后 camera HAL interface development 使用 Android 接口定义语言（Android Interface Definition Language，AIDL），旧设备和迁移设备仍可能保留 HAL 接口定义语言（HAL Interface Definition Language，HIDL）路径。这个版本边界影响新 camera feature 的暴露方式，也影响 vendor partition、SELinux policy、RC 文件和 VTS 测试。

HAL 的输入是 Camera2 / CameraX 经过 framework 和 CameraService 组织后的 session、stream configuration、capture request 和控制 metadata。HAL 的输出是 capture result metadata、preview buffer、still capture buffer、错误状态和可用能力描述。对于夜景人像，HAL 需要把“夜景”“人像”“HDR”“零快门延迟（Zero Shutter Lag，ZSL）”“preview stabilization”“RAW/YUV/JPEG/HEIC”等上层目标，映射到 sensor 帧序列、stream 组合、buffer 数量、ISP 模块开关和算法执行方式。

Driver、ISP firmware 和 sensor tuning 位于更底层。Driver 管理设备节点、中断、DMA、I2C/SPI 控制、MIPI CSI 数据接收和电源时序。ISP firmware 控制 RAW 处理、统计信息生成、降噪、去马赛克、色彩校正、tone mapping、sharpening 等模块。Sensor tuning 包含曝光线性、gain 范围、黑电平、坏点修正、lens shading、色彩矩阵和不同光源下的参数表。HAL 对 framework 给出稳定接口，对底层则调用厂商私有协议和库。

厂商标签（Vendor tag）是厂商扩展能力的重要入口。标准 metadata 覆盖通用控制项，vendor tag 允许厂商向 framework 或自家相机 App 暴露额外控制和结果，例如自定义场景模式、私有 HDR 状态、特定 fusion 状态、镜头切换策略、AI 场景标签或调试信息。它提高了厂商创新空间，同时也扩大了默认相机与第三方相机的能力差距。

判断一个问题属于 HAL 还是 driver / ISP / sensor，需要沿着可观察证据推进。若第三方 App 和默认相机都无法打开某个 camera ID，且系统层返回设备错误，责任更接近 HAL、driver、电源或硬件枚举。若默认相机夜景正常，第三方 App 只能使用普通拍照，责任更接近私有模式和 API 暴露。若所有 App 都出现固定色偏，且每次系统更新后色彩风格改变，责任更接近 ISP tuning 或算法参数。若只有特定镜头在高温时关闭，责任还要连接 thermal policy 与供电预算。

186.3 3A Algorithm：Auto Exposure、Auto Focus、Auto White Balance

3A Algorithm 指自动曝光（Auto Exposure，AE）、自动对焦（Auto Focus，AF）和自动白平衡（Auto White Balance，AWB）的闭环控制。它解决的问题是把当前场景的亮度、距离、光源和主体位置，转成 sensor 曝光时间、analog/digital gain、lens actuator 位置、色温估计和色彩增益。3A 的输出直接决定预览稳定性、快门时机、连拍一致性和多帧融合质量。

Android HAL3 将 3A 表达为 request control 与 result state。framework 可以通过 metadata 设置 AF/AE/AWB 模式和 trigger；HAL 负责具体算法和状态迁移，并通过 result metadata 回报 searching、converged、locked 等状态。公开文档将这套接口定义为高层状态机，具体算法由 HAL 实现。夜景人像里，默认相机通常会在按下快门前让 AE 和 AWB 收敛，在拍摄序列开始时锁定关键参数，再按计划采集短曝光、长曝光或不同 gain 的帧。

AE 负责决定画面总体亮度和运动风险。夜景场景中，AE 不能单纯拉长曝光时间，因为人物和手持抖动会产生拖影；它需要在曝光时间、ISO、frame duration、OIS 能力、运动检测和多帧数量之间取舍。默认相机可以利用私有运动估计和历史帧决定快门序列，第三方 App 通常只能看到标准 exposure control、AE compensation、AE lock 和可用范围。

AF 负责让主体落入清晰焦平面。手机相机的 AF 常结合 phase detection、contrast detection、laser/ToF、face detection 和 lens actuator 反馈。夜景人像的对焦更容易受低照度、低对比、人物移动和近距离景深影响。默认相机可以优先识别人脸或眼部区域，控制 lens 扫描范围，并在多帧融合前锁定焦点；第三方 App 使用标准 API 时，可以触发 AF、设置 metering region、读取 AF state，但通常拿不到厂商完整的人脸优先策略和私有深度估计。

AWB 负责把不同光源下的灰白物体映射到稳定色彩。夜景人像常出现霓虹灯、暖色路灯、屏幕光和混合光源。AWB 若过度追求中性，会削弱环境氛围；若保留过多色彩，又可能导致肤色偏黄、偏绿或偏红。OEM tuning 的风格差异在这里非常明显：有的厂商保留夜景氛围，有的厂商优先肤色稳定，有的厂商用场景识别给天空、绿植、肤色和灯光分配不同色彩策略。

3A 的工程判断顺序是先看状态，再看控制，再看结果。状态说明算法是否收敛，控制说明 App 或模式给了什么目标，结果 metadata 说明 HAL 实际采用了哪些曝光、gain、frame duration 和白平衡参数。若照片忽明忽暗，先检查 AE 是否在拍摄序列中反复 searching；若连续照片肤色跳变，检查 AWB 是否在场景切换中重新估计；若按快门后延迟明显，检查 AF 扫描、AE 收敛、多帧等待和夜景合成是否叠加。

186.4 ISP Tuning、Noise Reduction、HDR、Tone Mapping、Sharpening

ISP Tuning 是厂商把 sensor 原始数据转成可观看图像时设定的一组硬件和软件参数。它覆盖黑电平、坏点修正、lens shading、demosaic、noise reduction、color correction、gamma、HDR、tone mapping、local contrast、sharpening 和压缩前处理。它解决的问题是让同一套硬件在不同光线、不同镜头、不同温度和不同拍摄模式下输出稳定画质。

Noise Reduction 控制噪声、细节和纹理之间的取舍。夜景照片若降噪过强，天空会干净但头发、织物和树叶会糊；降噪较弱时细节保留更多，但暗部彩噪和亮度噪声更明显。厂商会按 ISO、曝光时间、sensor 温度、镜头、场景和输出尺寸选择不同强度的空间降噪、时域降噪和多帧降噪。用户看到的“油画感”常来自强降噪与强锐化叠加。

HDR 负责压缩高动态范围场景。手机 sensor 单帧动态范围有限，逆光人像和夜景灯牌会同时包含暗部人脸和高亮灯源。HDR 可以通过不同曝光帧融合、sensor staggered HDR、dual conversion gain 或 ISP 内部 tone mapping 保留更多亮部和暗部。OEM 差异体现在取舍目标：保灯牌文字、提亮人脸、压住天空、高对比电影感、低对比柔和感，这些目标会改变 fusion 权重和 tone curve。

Tone Mapping 将高动态范围数据映射到显示和文件格式可表达的范围。它决定中灰位置、暗部抬升、亮部 roll-off、局部对比和肤色亮度。默认相机的风格化常发生在这里：同样的 RAW 信息可以映射成明亮通透、对比浓烈、低饱和自然或高饱和讨好。视频预览和最终照片色彩不同，也常因为预览 pipeline 为实时性选择较轻处理，最终 still capture pipeline 使用更重的多帧和 tone mapping。

Sharpening 控制边缘和微结构的主观清晰度。轻度 sharpening 可以抵消镜头和去马赛克带来的软化；过强 sharpening 会产生白边、暗边和噪声增强。厂商常把 sharpening 与降噪、缩放、超分、镜头切换和人脸区域处理绑定。夜景人像里，人脸区域可能采用低锐化保护肤色，背景建筑采用更强锐化突出线条，头发边缘则受分割 mask 和景深虚化影响。

ISP tuning 的责任边界可以用“RAW 到输出”的阶段判断。若 RAW 或 DNG 已经偏色，问题更接近 sensor calibration、lens shading 或 AWB；若 RAW 正常但 JPEG 过锐，问题更接近 ISP sharpening 和后处理；若预览平滑而成片锐化重，说明 preview 和 still pipeline 使用不同配置；若同一设备更新后夜景风格变了，优先怀疑 tuning 参数、算法库版本或默认相机策略更新。

186.5 Computational Photography：Night Mode、Portrait、Multi-Frame Fusion

Computational Photography 指通过多帧采集、运动估计、语义理解、深度估计和局部图像处理来突破单帧硬件限制的成像方法。它解决的问题是手机光学体积受限、sensor 尺寸受限、镜头焦段有限和手持稳定性有限。夜景、人像、HDR、超分、去模糊、视频防抖、月亮模式、文档增强和实时翻译取景都属于计算摄影能力范围。

Night Mode 的核心路径是收集多帧、估计运动、对齐帧、选择可用信息、融合亮度与色彩、再执行降噪和 tone mapping。长曝光提供亮度，短曝光保护高光和运动主体，多帧平均降低随机噪声。系统还要判断手持稳定性、主体运动、光源闪烁、温度和剩余电量。若用户手持抖动强或人物移动明显，夜景算法会减少长曝光权重，照片亮度降低但拖影变少。

Portrait Mode 的核心路径是主体检测、深度估计、边缘分割和背景渲染。双摄、ToF、phase detection、单目深度网络和语义分割都可能参与。人像边缘质量取决于头发、眼镜、手指、透明物体、复杂背景和光照。默认相机可以使用厂商模型、私有 calibration 和多摄信息；第三方 App 能否获得同等能力，取决于平台是否通过标准 API、Camera Extensions 或 vendor library 暴露。

Multi-Frame Fusion 是夜景、HDR、超分和去噪的共同基础。它需要在多个 buffer 之间建立时间关系，记录每帧曝光、ISO、白平衡、OIS 状态、gyro 信息和时间戳，再执行配准和融合。NPU 可以运行语义分割、降噪网络或场景识别，GPU 可以承担图像处理 kernel 和实时预览效果，ISP 可以执行硬件级降噪、HDR、sharpening 和色彩处理，CPU 负责调度、控制和文件编码中的部分逻辑。

计算摄影也受系统策略约束。多帧融合需要 buffer、DRAM 带宽、ISP/NPU/GPU 时间、CPU 调度和电量预算；连续夜景、4K 视频 HDR、长时间录像和高温环境会触发降级。可见表现包括取景器帧率下降、快门等待变长、夜景模式关闭、分辨率降低、HDR 不可用、后台相机访问被拒绝或录像时镜头切换受限。

分析计算摄影问题时，先区分“采集能力”“融合能力”和“暴露能力”。采集能力由 sensor、lens、OIS、ISP 和 HAL 控制；融合能力由算法库、NPU/GPU/CPU/ISP 调度和 tuning 控制；暴露能力由默认相机、Camera2/CameraX、Camera Extensions、vendor tag 和权限策略控制。某台手机默认相机夜景强，并不能推出所有第三方 App 都能获得同等夜景结果。

186.6 OEM Camera App 与 Third-Party Camera API 暴露差异

OEM Camera App 是厂商影像能力的完整入口。它通常拥有系统签名、预装权限、私有 service 访问、vendor tag 知识、算法库初始化能力、模式 UI、场景识别和后处理链路。Third-Party Camera API 是面向普通应用的公开能力表面，主要通过 Camera2、CameraX、Camera Extensions 和标准权限暴露。两者之间的差距，是 Android OEM 影像碎片化最直观的来源之一。

Camera2 是低层 camera package，适合需要精细控制的应用；CameraX 封装常见用例，并可通过扩展接入部分厂商效果。公开文档说明 Camera2 支持 Android 5.0 API level 21 及以上，CameraX 与 Camera2 都能使用相机能力，但开发者仍要面对设备差异。厂商可以通过 Camera Extensions 向 Camera2 / CameraX 应用提供 Night、HDR、Bokeh、Face Retouch、Auto 等扩展模式，扩展是否可用由 OEM vendor library 报告。

默认相机与第三方 API 的差异可以分为五类。第一类是模式差异：默认相机有夜景人像、星空、月亮、多摄变焦、电影虚化，第三方只看到标准 still capture 或少量 extensions。第二类是质量差异：默认相机使用私有多帧、语义处理和调色，第三方输出更接近标准 pipeline。第三类是时序差异：默认相机能提前 warm up、缓存历史帧、做 ZSL，第三方按公开 session 启动。第四类是硬件差异：默认相机使用全部镜头组合，第三方只看到 logical camera 或有限 physical camera。第五类是策略差异：默认相机在高温、锁屏、后台、权限和系统模式下可能获得更高优先级。

夜景人像例子能清楚说明这个边界。默认相机 App 可以在用户取景时已经运行 scene detection 和 face detection，按下快门后从 ring buffer 取出多帧，再融合生成照片。第三方 App 若使用普通 Camera2 still capture，只能请求当前时刻的一帧或有限序列；若设备支持 Night extension，第三方可以通过扩展调用一部分厂商能力；若 vendor library 报告 extension unavailable，第三方 App 只能回到标准路径。

工程上评估第三方可用能力，应按照公开 API 查询、标准 metadata、extensions availability、stream combination 和实际输出五步走。先查询 camera characteristics 和 capabilities，再检查支持的 stream、format、resolution、logical multi-camera、RAW、manual sensor、YUV reprocessing、10-bit/HDR 等能力；随后查询 extensions 是否支持；最后用实际拍摄比较默认相机和第三方 App 的预览、延迟、成片和 metadata。这个顺序可以把“厂商没有做能力”“厂商做了但未公开”“公开了但质量低”“公开了但当前模式降级”区分开。

186.7 Camera CTS、HAL Compatibility 与厂商私有优化空间

Camera 兼容性测试套件（Compatibility Test Suite，CTS）、厂商测试套件（Vendor Test Suite，VTS）、图像测试套件（Image Test Suite，ITS）和扩展验证工具共同定义 Android 相机兼容性底线。CTS 是 Android 兼容性测试套件，用于帮助设备保持 Android compatible；它覆盖公开 API、权限、资源和功能行为。Camera 相关测试还包含 Camera ITS、Camera HAL 测试、CTS Verifier、Camera Extensions validation tool 等方向。它们约束的是公开接口、能力声明、metadata 一致性、图像质量基线和扩展接口行为。

HAL Compatibility 的核心是“声明了什么能力，就按该能力稳定返回”。如果设备声明支持某个 format、resolution、capability 或 extension，framework 和第三方 App 就会据此构建 session 和 request。HAL 需要在标准错误、buffer、metadata、state transition 和并发行为上保持可预期。Android 官方文档也要求 AIDL camera HAL 实现通过 CTS 和 VTS 测试；Camera Extensions validation tool 则包含自动和手动测试，用于验证 OEM vendor library 的接口和图像效果。

兼容性测试不会穷尽厂商私有优化空间。CTS 可以检查 API 签名、公开行为、camera capability、metadata、部分图像质量和扩展接口；它无法把每个厂商夜景算法、肤色风格、私有 HDR 策略、多帧 fusion 权重和美颜参数统一成同一结果。Android 平台保留这种空间，是为了让不同硬件、ISP 和厂商算法在相同 framework 下输出不同体验。

厂商私有优化空间主要位于四个位置。第一是 HAL 内部策略，例如选择 sensor mode、合并 logical camera、决定 stream 降级和返回 vendor tag。第二是 ISP tuning，例如各光线场景下的色彩、降噪、锐化和 tone mapping。第三是算法库，例如夜景融合、人像分割、超分、AI 场景和人脸处理。第四是默认相机 App，例如模式选择、UI 引导、快门等待、成片后处理和图库联动。

这种边界也解释了“通过 CTS 的设备仍有影像差异”。通过兼容性测试说明公开 Android camera contract 大体成立，不能推出默认相机风格一致、第三方 App 质量一致、夜景算法一致或系统更新不会改变画质。评估 OEM 相机时，应把兼容性作为底线，把默认相机体验、第三方 API 暴露、实际 metadata、温控降级和长期更新作为额外维度。

186.8 影像差异的系统来源：硬件、HAL、算法、App、策略

影像差异可以按五层归因：硬件、HAL、算法、App、策略。硬件决定信号输入上限，HAL 决定标准 API 到厂商实现的翻译，算法决定多帧和语义处理质量，App 决定用户可选模式和默认参数，策略决定在温度、电量、权限、后台和并发访问下的可用边界。稳定的工程判断要沿着这五层逐步缩小责任范围。

硬件层包括 sensor 尺寸、像素结构、读出速度、dual conversion gain、镜头光圈、OIS、对焦马达、闪光灯、多摄 calibration 和 ISP/NPU/GPU/DRAM 能力。它决定低照度信噪比、动态范围、运动读出变形、对焦速度和实时处理预算。硬件上限不足时，算法可以补偿一部分噪声和动态范围，但运动主体、光学虚化、镜头鬼影和高温预算仍会暴露边界。

HAL 层决定能力如何被 Android framework 看见。它声明 camera ID、logical / physical camera、stream combination、format、resolution、capability、metadata、vendor tag 和 error behavior。HAL 声明保守，第三方 App 可用能力少；HAL 声明激进但实现不稳，第三方 App 会遇到 session 创建失败、帧率异常、metadata 缺失或 buffer 错误。默认相机可能绕过一部分公开限制，因而更需要分开评估。

算法层决定主观画质和高阶模式。夜景看融合、运动估计和降噪；人像看分割、深度和渲染；HDR 看曝光序列和 tone mapping；视频看防抖、HDR、降噪和热控制；长焦看超分、多摄切换和色彩一致性。算法升级可以显著改变旧硬件表现，也可能在边缘场景产生新问题，例如鬼影、过度磨皮、边缘虚化错误和天空色带。

App 层决定用户如何进入能力。默认相机可以通过模式 UI、预取帧、私有参数和图库后处理把复杂能力包装成一个按钮。第三方 App 通过公开 API 获取能力，需要自己处理 camera characteristics、session、surface、request、lifecycle、权限、orientation、错误恢复和不同设备差异。用户说“手机相机好”，往往评价的是默认相机完整产品；开发者说“camera API 能力”，评价的是公开 contract。

策略层决定能力何时被收缩。相机是高功耗、高带宽、高温升设备，系统会根据后台状态、并发访问、隐私指示、权限、温度、电量、录像时长、屏幕状态和其他硬件占用调整行为。可见结果包括相机被其他 App 占用、后台无法开摄像头、录制时降帧、HDR 关闭、亮度降低、超广角切换失败、视频中断或拍照等待时间增加。

复盘夜景人像照片时，可以使用固定判断顺序：先确认默认相机和第三方 App 的差异，再看公开 capabilities 和 extensions，再看 metadata 与 3A 状态，再比较预览和成片 pipeline，再观察温控、电量和连续拍摄，最后回到硬件和算法边界。这样可以把“拍得好”拆成可讨论的工程来源，也可以把“拍得差”拆成可验证的失败路径。

最小自检任务

选择一台 Android 手机，假设用户在默认相机中拍摄夜景人像效果很好，但同一设备上的第三方相机 App 只能拍出普通低亮度照片。请在不读取厂商私有源码、不抓取真实设备日志的前提下，写出这件事可能经过的系统路径、责任边界、策略检查点和失败表现。要求至少覆盖 App、Framework API、CameraService、HAL、ISP/算法、Camera Extensions、CTS/兼容性和用户可见结果。

答案要点

一条合格路径应从默认相机 App 的夜景人像模式开始。默认相机可能使用系统签名、私有 vendor tag、厂商算法库和预取帧能力，把夜景、人像、HDR、多帧融合和肤色调校组合成一个模式。Framework API 只向普通 App 暴露 Camera2、CameraX 和可用 extensions；CameraService 负责权限、设备打开、session、stream 和错误回调；HAL 负责把 request 转成 sensor、ISP、driver 和算法控制；ISP 与算法库负责多帧降噪、HDR、tone mapping、人像分割和最终 buffer 输出。

责任边界应这样区分：若第三方 App 查询不到 Night 或 Bokeh extension，问题属于能力暴露边界；若 extension 可用但输出质量远低于默认相机，问题可能属于 vendor library 简化实现或默认相机私有后处理；若标准 still capture 亮度低，说明第三方 App 走的是普通 AE 与单帧/有限序列路径；若高温或低电量时默认相机也降级，策略层开始限制多帧、NPU、ISP 或高分辨率输出。CTS 与 Camera Extensions validation tool 能验证公开接口和扩展实现行为，但不会保证默认相机私有夜景结果与第三方 App 完全一致。

最终用户可见结果是：默认相机夜景人像亮、稳、低噪、有人像虚化；第三方 App 可能只有普通曝光、噪声更高、无虚化或等待时间不同。工程结论应落在“硬件能力经过 HAL、ISP tuning、算法库和默认相机产品化后形成 OEM 影像优势；公开 API 暴露范围决定第三方 App 能获得多少这条 pipeline 的结果”。

本章知识点总结

• Pipeline 边界：相机体验由 App、Framework、CameraService、HAL、driver、ISP、sensor 和算法库共同形成。
• 请求模型：HAL3 将相机建模为 capture request 到 result metadata 与 output buffer 的逐帧转换。
• HAL 职责：Camera HAL 把稳定 framework API 翻译成厂商 driver、ISP、sensor 和算法控制。
• 版本边界：Android 13 以后 camera HAL 新接口开发以 AIDL 为主，旧设备可能保留 HIDL 路径。
• Vendor Tag：vendor tag 承载厂商私有状态和控制项，是默认相机能力差异的重要入口。
• 3A 闭环：AE、AF、AWB 把场景亮度、主体距离和光源估计转成曝光、对焦和色彩控制。
• Tuning 取舍：ISP tuning 在噪声、细节、动态范围、肤色、锐度和实时性之间做工程选择。
• 夜景路径：Night Mode 依赖多帧采集、运动估计、对齐融合、降噪和 tone mapping。
• 人像路径：Portrait Mode 依赖主体检测、深度估计、边缘分割和背景渲染。
• API 差距：默认相机常拥有私有模式和系统级访问，第三方 App 受公开 API、extensions 和权限边界限制。
• 兼容底线：CTS、VTS、ITS 和扩展验证工具约束公开 contract，不统一厂商私有影像风格。
• 归因顺序：复盘影像差异应依次检查 App 差异、API 暴露、metadata、3A、pipeline、策略和硬件算法边界。