Chapter 127: Device-Level Imaging Differences

同一场景、同一光线、同一个 App，在两台手机上可能得到完全不同的照片和视频。差异先出现在硬件采集条件中，随后被 ISP、算法、HAL、系统 API 和应用访问边界逐层放大或收束。读完本章，读者应能把“这台手机拍照更亮、噪声更少、肤色更稳定、第三方 App 画质下降”这类现象追踪到具体责任链，而非停留在品牌印象或像素数量判断。

本章的贯穿材料是一段夜间人像拍摄：用户先用系统默认相机拍一张夜景人像，再用短视频 App 内置相机拍同一角度的视频片段。系统默认相机输出的脸部亮度、背景高光、边缘虚化和防抖表现更稳定；短视频 App 内画面噪声更明显，HDR 余量更小，人像边缘更容易漂移。这个现象覆盖本章全部小节：硬件条件决定原始信号，ISP 与算法决定处理空间，HAL 与 API 决定第三方 App 可用能力，系统策略决定最终交付边界。

设备级影像差异的判断顺序应从可观察事实开始：先看传感器尺寸、镜头、防抖、对焦和多摄组合，再看 ISP、NPU、内存带宽和热预算，接着看 Android Camera HAL 或 Apple AVFoundation 暴露的 stream、metadata、depth、RAW、扩展能力，最后看默认相机应用和第三方应用是否进入同一条处理路径。这个顺序能把“照片风格不同”拆成可定位的系统问题。

下面的路径图只表达本章的分析边界。它从同一拍摄场景出发，追踪原始光学条件如何进入系统能力，再进入 App 可见结果。

图中的关键边界是 Boundary。相机硬件的能力需要经过 HAL 或系统 API 才能被 App 使用；默认相机应用、系统相机框架和第三方 App 通常获得不同的入口、参数控制面和处理结果。设备级影像差异因此同时是硬件问题、系统封装问题和平台策略问题。

127.1 Camera Module、Sensor Size、Lens Stack 与硬件差异

相机模组是手机把外部光线转换成数字图像的硬件入口。它通常由镜头组、光圈、滤光片、自动对焦机构、防抖机构、图像传感器、封装校准数据和模组接口组成。传感器尺寸决定单次曝光能接收多少光，镜头组决定光线如何落到传感器，防抖和对焦机构决定采样期间画面是否稳定，模组校准数据决定后续 ISP 能否准确修正暗角、畸变、色差和镜头阴影。

传感器尺寸是判断设备级差异的第一层证据。较大的感光面积通常能在同等曝光时间下接收更多光子，低光环境下的信噪比更有余量；较小传感器需要更高增益或更长曝光才能达到相近亮度，噪声和运动模糊压力会同时上升。像素数量只说明采样网格规模，无法单独推出夜景质量。读者应同时看物理尺寸、像素间距、满阱容量、读出速度、动态范围和是否支持分区读出、高帧率读出或多增益读出。

镜头组把硬件差异进一步具体化。光圈影响进光量和景深，焦距影响视角和透视关系，镜片材料与镀膜影响眩光、鬼影和逆光对比度，OIS 通过移动镜头或传感器补偿手抖，PDAF、全像素双核对焦、激光辅助对焦等机制影响对焦速度和弱光可靠性。夜间人像示例中，默认相机能在较长曝光下保持脸部清晰，常见原因是镜头防抖、陀螺仪数据、对焦系统和多帧融合共同工作；短视频 App 为了维持实时预览和编码帧率，通常会缩短单帧曝光或提高增益，噪声会更早进入画面。

Android 公开 API 提供了一部分可观察硬件证据。CameraCharacteristics 中的 SENSOR_INFO_PHYSICAL_SIZE、SENSOR_INFO_PIXEL_ARRAY_SIZE、LENS_INFO_AVAILABLE_FOCAL_LENGTHS、LENS_INFO_AVAILABLE_OPTICAL_STABILIZATION、REQUEST_AVAILABLE_CAPABILITIES 能帮助 App 判断传感器物理尺寸、像素阵列、焦段、OIS 模式和能力集合。它们解释的是系统公开给应用的硬件能力摘要；厂商内部的传感器读出模式、降噪模型、ISP 固件细节和默认相机私有参数仍处在厂商实现边界内。

Apple 平台也通过 AVFoundation 暴露设备、格式、帧率、深度、照片输出和视频稳定等公开能力。公开文档能支持开发者判断当前设备是否支持某类 capture format 或 output；模组内部调校、默认相机的完整多帧策略和私有 ISP 路径需要按平台行为推断，不能写成公开实现事实。这个边界对本章很关键：我们能说明软硬件一体化带来的控制面集中，却不能把不可公开验证的私有实现细节当成源码级结论。

一个可复用的硬件判断例子是夜景人像失真定位。若同一 App 在两台设备上预览亮度差异明显，先看主摄传感器尺寸、光圈、OIS 和读出速度；若亮度相近但脸部细节差异明显，再看 ISP 降噪和锐化策略；若默认相机稳定而第三方 App 波动大，再看系统 API 是否暴露同等夜景、HDR、人像和稳定能力。这个顺序把硬件差异放在最前，但不会把所有差异都归结为硬件。

127.2 ISP 能力、算法调校与图像风格

ISP 是图像信号处理器，它把传感器输出的 RAW 数据转换成可预览、可编码、可保存的图像数据。典型处理包括黑电平校正、坏点修复、镜头阴影校正、去马赛克、降噪、锐化、色彩校正、白平衡、局部对比度、HDR 合成、色调映射和输出格式转换。ISP 的职责覆盖稳定成像、实时处理和画质调校，它负责把受光学、噪声、传感器读出和实时性约束影响的原始数据变成稳定的系统输出。

算法调校决定图像风格。相同传感器和镜头在不同厂商设备上可能呈现不同的肤色、蓝天、夜景亮度、阴影对比、边缘锐度和噪声颗粒。原因在于 ISP 与上层算法会选择不同的噪声模型、曝光策略、白平衡目标、色彩矩阵、局部 tone mapping 和锐化半径。夜间人像示例中，默认相机如果选择更强的时域降噪和脸部保护策略，脸部会更干净；如果选择更强的局部对比度和边缘增强，画面会显得更锐，但头发、眼镜边缘和背景灯牌可能出现光晕。

3A 控制是 ISP 与算法调校的实时闭环。AE 负责曝光，AF 负责对焦，AWB 负责白平衡。它们依赖 sensor stats、ISP stats、场景识别、脸部检测和运动估计。夜景场景下，AE 需要在脸部亮度、高光保留、手抖风险和帧率之间取舍；AF 需要在弱光噪声和对焦置信度之间取舍；AWB 需要在真实环境色温和用户期望肤色之间取舍。设备级差异经常出现在这些取舍点上。

多帧算法把 ISP 能力从单帧处理扩展到时间维度。HDR 会组合不同曝光或不同增益的帧，夜景会积累多帧并做运动补偿，人像模式会融合 RGB、深度、语义分割和镜头模型，视频防抖会结合 OIS、EIS、陀螺仪和裁切窗口。多帧算法需要传感器读出速度、内存带宽、ISP 队列、GPU 或 NPU 计算和热预算共同支持。默认相机应用通常能更主动地使用这些资源；第三方 App 需要通过公开 API 获得可用能力，质量上限受接口暴露范围约束。

图像风格还受输出目标约束。照片保存可以接受更高延迟，允许多帧融合、语义处理和更复杂的 tone mapping；实时视频需要稳定帧率、低延迟、编码同步和音画时间戳一致，算法预算更紧。短视频 App 内置相机经常选择实时 YUV stream 或压缩后的预览路径，这条路径更重视低延迟和连续帧率，照片级夜景处理空间会被压缩。

判断 ISP 与风格差异时，读者应把“画面好看”拆成四个可观察维度：噪声是否被压低，细节是否被保留，动态范围是否覆盖高光和阴影，肤色与白平衡是否稳定。每个维度都能映射到 ISP 或算法阶段。噪声对应增益、降噪和融合帧数；细节对应去马赛克、锐化和运动补偿；动态范围对应传感器读出、HDR 合成和 tone mapping；肤色对应 AWB、色彩矩阵和语义保护策略。

127.3 Android OEM Camera HAL 与厂商影像 Pipeline

Android 的相机路径以 Camera2 API 和 Camera HAL 为核心边界。App 通过 framework 创建 capture request，CameraService 负责权限、设备打开、session 管理和请求分发，Camera provider 与 HAL 连接厂商实现，HAL 再驱动传感器、ISP、算法库和 buffer 队列。Android Camera HAL3 公开材料把相机建模为 request 到 result 的 pipeline：一次请求携带曝光、对焦、输出 surface 和处理参数，系统返回 metadata 与一个或多个图像 buffer。

这个模型给 Android OEM 留出了大量差异化空间。OEM 可以选择不同传感器、镜头和 ISP，也可以在 HAL、vendor tag、算法库、相机 daemon、默认相机应用中加入自有处理。标准 Camera2 metadata 提供通用能力查询，vendor tag 提供厂商扩展字段，默认相机应用可能与厂商私有服务共享更完整的场景识别、夜景、HDR、人像、美颜和多摄融合能力。第三方 App 若只使用标准 Camera2 或 CameraX 表面，通常只能访问标准化能力和系统允许公开的扩展能力。

Android OEM 影像 pipeline 可以分成三层观察。第一层是标准能力层，例如 RAW、YUV、JPEG、DEPTH、LOGICAL_MULTI_CAMERA、BURST_CAPTURE、MANUAL_SENSOR、视频防抖模式和可配置 stream 组合。第二层是厂商扩展层，例如 vendor tag、CameraX Extensions、特定夜景或人像效果接口、OEM 自有 metadata。第三层是默认相机私有层，例如系统相机应用和厂商算法服务之间的内部协议、私有模型、私有多帧策略和专门调校参数。多数第三方 App 的画质差距来自第二层和第三层之间的能力落差。

Android 设备之间的差异还来自 HAL 一致性和资源调度。一个设备可能公开更丰富的 stream combination，另一个设备可能在高分辨率 YUV、预览、视频编码、深度输出同时开启时失败。一个设备可能把逻辑多摄做成平滑 zoom，另一个设备可能在镜头切换时出现曝光跳变。一个设备可能在 CameraX Extensions 中暴露夜景和人像，另一个设备只给默认相机使用完整算法。App 可见结果由标准 API、HAL 能力、厂商调校和 CTS/VTS 约束共同决定。

夜间人像示例在 Android 上通常会走出两条路径。默认相机可能调用厂商私有夜景 pipeline：多帧采集、运动估计、脸部检测、语义保护、局部 tone mapping、降噪和锐化一起完成。短视频 App 可能通过 Camera2 或 CameraX 拿到实时预览流，再把 YUV 或 Surface 输入编码器和滤镜链。它能控制曝光补偿、焦点、分辨率、帧率和部分稳定模式，但它未必能进入默认相机的完整夜景融合路径。

Android 差异的排查方法应先问三个问题。第一，App 使用的是 Camera2、CameraX、OEM SDK 还是系统相机 Intent。第二，当前 camera id 的 REQUEST_AVAILABLE_CAPABILITIES、stream configuration、hardware level、vendor tag 和 extension availability 是否覆盖目标效果。第三，默认相机效果是否依赖私有服务或私有 metadata。这样可以把“App 拍得差”定位为 API 使用问题、公开能力缺口、厂商私有能力缺口或实时性能策略问题。

127.4 Apple 软硬件一体化下的影像一致性

Apple 平台的设备级影像差异来自集中控制的软硬件链路。Apple 同时控制传感器选型、镜头模组、ISP、Neural Engine、系统框架、默认相机应用、媒体编码和照片库体验。公开层面，开发者通过 AVFoundation Capture 选择 capture device、format、input、output、photo settings、video connection、depth 或 stabilization 能力；私有层面，默认相机应用可以和系统影像 pipeline 使用更深的内部协作。这里的私有层面是基于平台行为的合理边界判断，不等同于公开源码事实。

软硬件一体化带来的第一项结果是体验一致性。设备型号、传感器、镜头和 SoC 都在同一平台策略下调校，默认相机、相册处理、系统预览、媒体编码和显示 pipeline 的色彩目标更容易统一。用户从拍摄、预览、编辑到分享，看到的曝光、肤色、HDR 显示和视频稳定通常更连贯。这个连贯性来自系统控制面的集中，而非单个 API 参数。

第二项结果是公开 API 能力边界更清晰。第三方 App 可以查询设备格式、支持的分辨率、帧率、颜色空间、照片输出、深度数据和稳定模式；是否存在更高质量的私有默认相机处理，则由系统策略和设备能力决定。开发者能通过 AVFoundation 获取稳定的跨设备接口，但无法假设默认相机里的所有计算摄影能力都能以同等质量开放给第三方 App。

第三项结果是型号差异会表现为系统级功能差异。同样是 iPhone，不同代际的传感器尺寸、镜头焦段、OIS 形式、ISP 能力、Neural Engine 预算和视频编码能力不同；系统会把这些差异包装成可用格式、支持模式、照片功能、视频功能和用户界面选项。某些功能在默认相机中出现，在第三方 App 中只暴露部分能力，或需要使用特定 AVFoundation 配置才能启用。

夜间人像示例在 Apple 平台上的判断重点是公开 API 与默认相机路径的边界。若默认相机的夜景、HDR、人像边缘和视频防抖显著优于第三方 App，先检查第三方 App 是否使用了正确的 capture preset、active format、photo output、depth delivery、stabilization mode 和颜色处理；再判断差距是否来自系统未公开的默认相机多帧融合或语义处理。这个判断既承认公开 API 的稳定性，也保留对私有实现的边界约束。

Apple 影像一致性并不消除设备级差异。它把差异集中在型号能力、系统版本、公开 API 暴露和默认相机策略上。读者分析 Apple 设备时，应优先区分三类事实：公开文档说明的 API 能力，用户可观察的平台行为，无法公开验证的私有 pipeline。三者合在一起能解释体验差异，但在正文或工程文档中应分别标注证据来源。

127.5 HDR、Night Mode、Portrait、Video Stabilization 的系统实现差异

HDR、Night Mode、Portrait 和 Video Stabilization 是设备级影像差异最容易被用户感知的四类功能。它们共同依赖硬件采样、ISP 算法、系统 API 和实时资源调度，但每类功能的主约束不同。HDR 关注动态范围，Night Mode 关注弱光信噪比和运动补偿，Portrait 关注主体分割与深度边界，Video Stabilization 关注连续帧的时间稳定和裁切预算。

功能	主要输入	系统处理路径	设备差异来源	用户可见失败表现
HDR	不同曝光或不同增益的多帧数据	对齐、合成、局部 tone mapping、HDR 显示或 SDR 映射	传感器动态范围、读出速度、ISP 合成能力、显示链路	天空过曝、阴影发灰、脸部发暗、边缘光晕
Night Mode	弱光多帧、陀螺仪、场景运动估计	长曝光或多帧堆栈、运动补偿、降噪、锐化	OIS、传感器尺寸、算力、热预算、算法调校	噪声强、涂抹、运动鬼影、出片等待长
Portrait	RGB、深度、双摄视差、语义分割	主体识别、深度估计、边缘细化、背景虚化	深度硬件、镜头基线、模型质量、发丝边缘处理	抠图错误、眼镜边缘断裂、背景误虚化
Video Stabilization	视频帧、OIS、陀螺仪、裁切窗口	光学补偿、电子防抖、时域滤波、编码同步	OIS 行程、传感器读出、陀螺仪质量、裁切余量	画面抖、果冻效应、视角变窄、暗光拖影

HDR 的设备差异首先受传感器动态范围和读出方式影响。支持多增益读出或高速连续曝光的传感器能给合成算法更多输入；ISP 的局部 tone mapping 决定高光、阴影和肤色如何分配亮度。第三方 App 若只能拿到已经处理过的 SDR 预览流，就难以重建默认相机同等级别的 HDR 结果。视频 HDR 还涉及编码格式、显示能力和平台策略，实时处理压力高于静态照片。

Night Mode 的差异更依赖时间预算。系统需要在多个短曝光或较长曝光之间选择，并根据手抖、主体运动、场景亮度和热状态调整融合帧数。默认相机可以让用户等待数秒，照片 App 场景允许更高延迟；短视频 App 需要连续输出帧，通常会限制融合深度。设备若具备更好的 OIS、较大传感器、更快 ISP 和更高内存带宽，就能在低光下保留更多细节。

Portrait 的差异来自深度来源和语义边界。双摄视差、结构光、LiDAR、单目深度估计和语义分割都能参与人像虚化，但边缘质量取决于模型、镜头标定、深度分辨率和 ISP 输出。默认相机应用通常能结合厂商模型和设备校准数据；第三方 App 需要通过公开 depth data、portrait matte 或分割结果获得信息。若公开输出分辨率较低或时延较高，人像边缘会在视频或实时预览中更容易漂移。

Video Stabilization 的差异受实时性约束最强。OIS 负责采样时的物理补偿，EIS 负责后续裁切和帧间变换，陀螺仪提供高频运动轨迹，编码器要求稳定帧率和时间戳。强防抖通常需要裁切画面并消耗更多计算预算；暗光下曝光时间变长，单帧运动模糊会让 EIS 难以恢复细节。用户看到的结果可能是防抖更稳但画面更窄，也可能是亮度更高但拖影更明显。

这四类功能的共同判断方法是统一输入、处理、暴露和失败表现。先确认硬件是否能提供足够原始输入，再确认 ISP 与算法是否有实时预算，接着确认 HAL 或系统 API 是否把能力暴露给当前 App，最后观察失败表现对应哪个阶段。这个方法比单纯比较样张更可复用，因为它能解释同一设备在默认相机和第三方 App 中的差异。

127.6 Third-Party App Camera Quality 与系统 API 暴露能力

第三方 App 相机质量由公开 API 暴露能力决定上限，由 App 自身管线决定实际结果。App 通过 Camera2、CameraX、AVFoundation 或平台特定 SDK 打开设备，配置 session、surface、format、fps、resolution、photo output、video output、stabilization 和 metadata。系统服务负责权限、设备占用、stream 配置和资源调度。HAL 或平台后端决定哪些硬件与算法能力能进入 App 可见路径。

质量差距常出现在四个边界。第一，stream 边界：App 拿到的是预览流、YUV 流、RAW、JPEG、HEIF、depth 还是视频编码输入。第二，metadata 边界：App 是否能获得曝光时间、ISO、白平衡、焦距、镜头状态、深度、姿态和厂商扩展字段。第三，算法边界：夜景、HDR、人像、美颜、超分、防抖是否以公开能力形式开放。第四，资源边界：实时滤镜、编码、上传、UI 合成和相机 pipeline 是否共同竞争 CPU、GPU、NPU、ISP、内存带宽和热预算。

Android 上，第三方 App 的质量通常分三档。基础 Camera2 或 CameraX 路径能获得标准预览、拍照、视频和部分手动控制；CameraX Extensions 或 OEM SDK 可能开放夜景、人像、HDR 等厂商效果；默认相机应用可能使用更深的私有算法链。Apple 上，AVFoundation 提供稳定的 capture 抽象和能力查询，第三方 App 能获得照片、视频、深度、稳定等公开能力；默认相机应用是否使用更深的私有计算摄影路径，应按公开文档之外的平台行为谨慎表述。

短视频 App 内置相机的画质下降经常来自实时链路压力。App 需要把相机输出交给滤镜、贴纸、分割、美颜、视频编码、预览合成和网络上传准备，系统还要维持触控响应、音频同步和热控制。为了稳定帧率，App 可能选择较低分辨率、较短曝光、较低融合深度或更强压缩。默认相机拍照路径则可以延迟输出，允许更复杂的多帧融合和照片级后处理。

工程分析时，应把“第三方 App 拍照差”拆成责任链，而非直接归因给平台限制。若 App 配置了低分辨率或错误的 capture preset，责任在 App 配置。若标准 API 没有暴露默认相机的夜景 pipeline，责任在能力开放边界。若设备进入温控状态后降低帧率、分辨率或算法强度，责任在资源策略。若某台设备 vendor tag 或 extension 行为不稳定，责任在 OEM 实现与兼容性边界。

一个最小排查顺序如下：先记录 App 使用的 API、camera id、format、resolution、fps 和输出类型；再查询标准能力、stream combination、stabilization、depth、RAW、extension 和 metadata；接着比较默认相机与第三方 App 是否拥有同等处理入口；最后用失败表现定位阶段。噪声和涂抹多指向弱光采样、增益和降噪；高光过曝多指向 HDR 输入和 tone mapping；边缘虚化错误多指向深度或分割；抖动和拖影多指向 OIS/EIS、曝光时间和编码实时性。

127.7 设备级影像差异的技术来源

设备级影像差异的技术来源可以压缩成五层：硬件采样条件、ISP 与算法能力、HAL 或系统 API 暴露、默认相机与第三方 App 路径、系统策略。每一层都有独立责任，也会影响后续层。硬件提供原始信号上限，ISP 与算法决定可恢复信息，HAL 或系统 API 决定 App 可调用能力，默认相机与第三方 App 路径决定算法入口，系统策略决定功耗、温控、权限和实时性边界。

硬件层解释“原始条件为何不同”。传感器尺寸、光圈、OIS、焦段、读出速度、自动对焦、镜头标定和模组一致性决定采集质量。它回答同一场景下为什么一台设备有更好的低光输入、更少运动模糊或更稳定对焦。硬件层的证据来自规格、公开 API characteristics、样张 EXIF、视频帧率和可观察失败表现。

ISP 与算法层解释“原始数据如何变成图像”。同样的光学输入经过不同降噪、锐化、HDR、白平衡、色彩、夜景、人像和防抖策略，会变成不同风格。它回答为什么两台手机都能拍亮夜景，但一台保留纹理，另一台出现涂抹；为什么一台肤色稳定，另一台在混合光源下偏色。证据来自输出风格、metadata、处理延迟、运动伪影和功能模式差异。

HAL 或系统 API 层解释“哪些能力能被 App 使用”。Android 通过 Camera2、CameraX、Camera HAL、vendor tag 和 extensions 暴露能力；Apple 通过 AVFoundation 暴露设备、格式、输出和稳定等能力。默认相机应用可能进入更深的厂商或系统私有路径，第三方 App 通常受公开 API 边界约束。它回答为什么同一设备默认相机和 App 内置相机质量不同。

系统策略层解释“为什么能力会被动态调整”。相机长时间使用会受到温度、功耗、内存带宽、后台状态、权限、隐私提示和多 App 资源仲裁影响。夜景、HDR、视频防抖和人像都需要计算预算；当系统需要维持温控或帧率时，算法强度、分辨率、帧率、曝光时间或并发输出组合可能变化。用户看到的是画质下降、预览变暗、帧率降低、功能不可选或相机 session 重建。

最终判断可以用一条责任链表达：App 意图是拍摄夜间人像；Framework 入口是 Camera2、CameraX 或 AVFoundation；系统服务负责权限、设备打开、session 和 stream 配置；HAL 或平台后端把请求映射到传感器、ISP、算法和 buffer；资源策略根据前台状态、温度和功耗调整处理强度；返回结果体现为照片、视频、metadata、错误码或可见质量变化。这条链能解释设备之间的差异，也能解释同一设备不同 App 之间的差异。

本章建立的核心理解是：手机影像质量是跨层系统结果。传感器和镜头给出输入上限，ISP 和算法决定信息恢复方式，HAL/API 决定能力开放边界，默认相机和第三方 App 决定实际路径，功耗与温控决定持续运行时的策略。分析设备级影像差异时，应沿这条链逐层定位责任主体和证据。

最小自检任务

用户反馈：同一台手机在系统默认相机中拍夜间人像清晰、背景高光保留好、人像虚化稳定；在某短视频 App 内置相机中画面噪声明显、灯牌过曝、边缘虚化不稳定。另一台手机在同一短视频 App 中表现更差。请分析这个现象的系统路径，写出可能的责任主体、能力边界、策略检查点和用户可见结果。

答案要点

请求路径应从 App 意图开始：短视频 App 通过 Camera2、CameraX 或 AVFoundation 打开相机，配置实时预览、视频帧率、分辨率、滤镜或分割链路；系统服务检查相机权限、前台状态、设备占用和 session 配置；HAL 或平台后端把请求映射到传感器、ISP、算法、buffer 和编码输入；最终返回实时画面或错误状态。默认相机应用可能使用更完整的夜景、HDR、人像和多帧处理路径，短视频 App 通常受公开 API、实时帧率和编码链路限制。

责任主体应分层判断。硬件层负责传感器尺寸、光圈、OIS、对焦和读出速度；ISP 与算法层负责降噪、HDR、tone mapping、人像分割和防抖；HAL 或系统 API 层负责 stream、metadata、depth、RAW、extension 和厂商能力暴露；App 层负责选择分辨率、帧率、输出格式、滤镜和编码策略；系统策略层负责温控、功耗、前台状态和多 App 资源仲裁。

能力边界应围绕公开能力展开。若短视频 App 只能获得实时 YUV 或预览 stream，它难以复用默认相机照片级多帧夜景。若 Android 设备没有为该 App 暴露对应 CameraX Extension、vendor tag 或稳定 stream combination，夜景和人像效果会受限。若 Apple 设备公开 AVFoundation 能力覆盖基础 capture，但默认相机使用更深系统影像 pipeline，第三方 App 的结果会低于默认相机。

策略检查点包括权限授予、前台 camera session、stream 组合可用性、目标 fps、温度状态、功耗预算、内存带宽和编码实时性。用户可见结果包括噪声上升、高光过曝、虚化边缘漂移、画面裁切、帧率降低、预览变暗、相机功能不可选或 session 重建。另一台手机表现更差，可能来自更小传感器、更弱 OIS、更慢 ISP、更少公开能力、更保守温控策略或 OEM HAL 扩展能力不足。

本章知识点总结

• 硬件入口：相机模组把光线转换成系统可处理的数字信号，传感器尺寸、镜头、防抖和对焦共同决定原始采样条件。
• 像素边界：像素数量只能描述采样网格，夜景和动态范围还依赖物理尺寸、读出速度、噪声模型和曝光策略。
• 镜头责任：光圈、焦距、镀膜、OIS 和对焦系统会影响亮度、透视、眩光、手抖补偿和弱光清晰度。
• ISP 角色：ISP 负责把 RAW 数据转换成可预览、可编码、可保存的图像，并承担降噪、色彩、HDR 和 tone mapping 等处理。
• 风格来源：图像风格来自曝光、白平衡、噪声、锐化、局部对比度、肤色保护和多帧融合的综合调校。
• Android 边界：Android Camera2、Camera HAL、vendor tag、CameraX Extensions 和默认相机私有路径共同决定 OEM 影像差异。
• Apple 边界：Apple 通过软硬件一体化提升默认体验一致性，第三方 App 通过 AVFoundation 使用公开能力。
• HDR 差异：HDR 质量依赖传感器动态范围、多帧输入、ISP 合成、tone mapping、编码和显示链路。
• 夜景差异：Night Mode 依赖弱光采样、OIS、融合帧数、运动补偿、算力、内存带宽和热预算。
• 人像差异：Portrait 质量依赖深度来源、语义分割、镜头标定、边缘细化和公开 API 输出能力。
• 防抖差异：Video Stabilization 由 OIS、EIS、陀螺仪、裁切窗口、曝光时间和编码实时性共同决定。
• 第三方差距：第三方 App 的画质上限由公开 API 暴露能力决定，实际结果还受 App 自身实时处理和编码策略影响。
• 策略影响：温控、功耗、权限、前台状态和多 App 仲裁会动态改变相机分辨率、帧率、算法强度和可用功能。
• 判断顺序：分析设备级影像差异时，先看硬件输入，再看 ISP 与算法，再看 HAL/API 暴露，最后看 App 路径和系统策略。