1. 适配问题到底出在哪里从一次灰度事故说起相机适配凡是亲手做过移动端或嵌入式摄像头方案的人都得承认这是整个项目里最磨人的模块之一。很多人以为相机适配就是打开摄像头、把预览画面显示出来真正经历过一次灰度事故才会明白问题远不止如此。前年我们给一款App接入新的预览方案灰度到5%的时候后台开始陆续收到两类反馈一部分中低端机型黑屏另外一部分预览严重卡顿甚至偶尔弹无法连接到相机。最诡异的是崩溃率并没有明显上涨——也就是说代码层面没有崩但用户体验已经跌到谷底。当时排查了一整天最后定位到问题出在两处第一适配层在配置预览流时写死了一个 1920×108030fps 的组合第二代码里对所有机型统一开启了 HDR。这两件事单看都不致命但叠加在低端SoC平台上就出问题了——ISP负载扛不住帧率直接掉到15fps以下而黑屏更直接代码请求的尺寸帧率像素格式HDR使能这个组合在设备的 StreamConfigurationMap 里根本不存在会话创建直接失败。这才是相机适配最真实的日常。1.1 事故还原不是崩溃是组合不存在那次事故的本质不是某个API用错了而是我们的适配策略默认了所有设备的相机能力都一样。同一批代码高端机上跑得丝滑低端机上却连会话都建不起来。干这一行时间长了你会发现相机模块的差异是三维叠加的硬件维度传感器像素、靶面尺寸、ISP算力、镜头模组、防抖马达每台机器都不一样。系统维度不同安卓版本的API行为不同各厂商的HAL实现不同不同SoC平台的ISP驱动也不同。场景维度预览、扫码、人脸、录像、直播对能力的需求完全是另一套逻辑。这三个维度一叠加组合数几乎是无穷的。所以写完一套配置就能跑遍所有机器的代码现实中不存在。正因为这样我后来把相机适配的思路彻底改了不再去适配机型而是建立一套从探测、决策、执行到反馈的闭环。核心就是三个策略能力探测前置、分层抽象、场景驱动调优。2. 策略一能力探测优先于写死参数这是我最想强调的一条。很多团队做相机适配第一反应是维护一个机型白名单某个型号出问题了就往里面加特判。说实话这个思路在机型少的年代还能凑合现在完全行不通。2.1 为什么机型白名单靠不住同一款型号的手机不同批次可能换了传感器。你说你针对某品牌某型号做了校准结果用户手里的机器是第二批货传感器换了ISP参数变了你的白名单和特判全部作废。更要命的是厂商系统升级也会改变HAL行为。同一个机型安卓12和安卓13上的相机表现很可能是两回事。白名单写得再细也追不上新机发布和系统迭代的速度。所以我的原则很简单运行时让设备自己告诉我们它能做什么而不是靠我们在代码里猜它应该能做什么。2.2 能力探测到底探什么一份清单以安卓平台为例核心信息来源是 CameraCharacteristics尤其是其中的 StreamConfigurationMap。以下维度是必探的输出能力所有输出尺寸与帧率组合、支持像素格式列表注意帧率组合要查高帧率视频的专用接口预览和录像的配置不是一套。对焦系统AF模式列表、对焦距离范围能不能微距、能不能无穷远。曝光系统AE/AWB模式、ISO范围、曝光时间范围、AE目标帧率范围。稳定系统OIS光学防抖和EIS电子防抖的支持情况。计算摄影能力HDR模式、RAW输出、多帧降噪、超高分辨率输出。多摄能力物理摄像头ID集合、逻辑多摄组合、广角/长焦/景深摄像头映射。基础特性镜头朝向前置/后置、闪光灯模式、畸变校正、时间戳来源。这里面最容易漏的是组合校验。很多团队查了尺寸表发现 1080p 存在就认为1080p预览没问题。但实际上 1080p 30fps YUV格式 HDR 使能可能就不是有效组合。组合校验必须用 StreamConfigurationMap 的接口逐项核对不能只查单一维度。2.3 探测结果缓存与更新策略相机能力矩阵不是每次打开摄像头都要重新探测。我的做法是进程启动后探测一次缓存到内存里App升级时清缓存重新探测后台如果发现某机型上报了缓存结果与实际能力不一致可以主动打点上报为后续维护提供线索。这样做的原因是探测本身有开销首次打开相机要快等用户开始扫码或拍照时再异步补齐完整能力矩阵。缓存分层第一层是必备能力尺寸、帧率、格式用于会话创建第二层是增强能力HDR、RAW、防抖等用于策略决策。前者同步读取后者异步补齐。2.4 探测之后怎么选配置一个可落地的选择逻辑探测只是第一步怎么用探测结果生成配置才是关键。我写过一个选择逻辑思路是目标优先、逐级降档找到一个分辨率其长宽比与业务期望一致面积最接近目标分辨率然后校验该分辨率下是否支持目标帧率再校验格式和HDR组合是否成立如果有任何一项不满足就按降级顺序往下走。核心降级顺序可以是先降帧率30 - 24 - 15再降分辨率1080p - 720p - 480p关掉计算摄影HDR、多帧降噪关闭最后更换像素格式从 YUV_420_888 切到更通用的 NV12 等代码大概长这样fun resolvePreviewConfig( caps: DeviceCapabilities, targetSize: Size, targetFps: Int, needHdr: Boolean ): PreviewConfig { val candidates caps.previewSizesByAspect(targetSize.width, targetSize.height) for (size in candidates.sortedBy { it.area() }) { val fpsSupported caps.isFpsSupported(size, targetFps) if (!fpsSupported) continue val hdrSupported !needHdr || caps.isHdrSupported(size, targetFps) if (hdrsupported) { return PreviewConfig(size, targetFps, needHdr) } } // 降级关 HDR // 降级降帧率 24/15 // 降级降分辨率 return fallbackConfig(caps) }我说一个实测体会90%的线上问题不是分辨率不存在而是分辨率帧率格式HDR的组合不存在。所以配置选择逻辑的核心不是找最大分辨率而是校验组合。3. 策略二分层抽象让业务代码永远不碰硬件细节如果你只在单个App里做相机功能分层可能显得多余。但只要你的相机能力被多个业务模块共用——扫码、人脸识别、拍照、录像、直播——分层就是刚需。3.1 三层结构设计我通常会把相机模块拆成三层层级职责典型接口底层驱动封装层对接系统Camera API维护能力表、会话创建、参数归一化openCamera / createSession / applyRequest策略决策层接收业务场景诉求结合能力矩阵产出最终配置resolve(scene, capability)业务服务层只暴露扫码/人像/视频等高语义接口不感知硬件startScene(ScanScene)底层封装层最重要的工作是参数归一化。不同平台的AF模式、AE模式、防抖模式的命名和枚举都不同统一映射到内部枚举后策略决策层和业务层就完全不用关心设备差异。3.2 适配层的关键职责归一化、降级、错误翻译归一化之外最容易被忽视的是错误翻译。厂商返回的错误码五花八门有的设备在相机被占用时返回 ERROR_CAMERA_IN_USE有的返回 ERROR_MAX_CAMERAS_IN_USE有的干脆统一返回 ERROR_CAMERA_SERVICE 之类的大类错误。适配层要把这些错误统一翻译成内部枚举业务层才可能给出正确的用户提示和重试逻辑。另一个关键职责是降级路由。会话创建失败时不能让业务直接感知创建失败而是要自动走降级链路。这个链路本质上就是策略一里的降级顺序只不过放在分层结构里实现fun createSessionWithFallback(config: SessionConfig): Session { var current config repeat(3) { try { return rawCreateSession(current) } catch (e: CameraException) { current current.reduce() // 按降级顺序生成低一档配置 } } throw CameraException(LOW_LEVEL_CREATE_FAILED) }注意这里有个细节降级次数一定要有限制而且每次降级后都要打点上报。如果三次降级仍然失败说明这台设备的问题不是配置能解决的这时候再返回错误并带上最终的降级报告方便后台分析。3.3 分层之后接入新机型到底有多轻松分完层之后新机型接入就变成了一件事在底层驱动封装层补全能力表确认归一化逻辑没有踩到这台设备的特殊坑其他两层完全不用动。而业务侧新增场景也变得简单。比如要加一个文档扫描场景业务服务层加一个场景定义策略决策层填上该场景的目标配置比如需要畸变校正、需要连续对焦、不需要高帧率适配层的能力表已经能支撑整个过程不会超过半天。还有一个容易被忽略的好处分层之后Debug变得极其舒服。可以在底层注入一个模拟数据源把真实相机替换成预设图像流业务层和策略层不用接真机就能跑通大部分逻辑。这在自动化测试里价值非常大。4. 策略三场景驱动链路调优不搞一刀切相机适配做到后期你会发现一个残酷的事实**没有一套万能配置能同时满足所有业务场景。**拍照想要高分辨率扫码想要低延迟录像想要稳定帧率直播想要低发热。这四件事哪怕在同一台设备上诉求都是互相打架的。4.1 不同业务场景对相机的诉求完全不同扫码场景我们要的是低分辨率YUV帧回调、快速对焦、曝光尽量锁定。分辨率高了反而增加CPU/ISP负担帧率上不去二维码在暗光下反而不容易解出来。人像/人脸场景要的是连续对焦灵敏度、人脸检测回调、画面畸变修正。这时分辨率不宜太高不然人脸检测的耗时上不去但美颜算法又需要足够的图像细节所以要在720p到1080p之间找平衡。普通拍照要的是主摄最大可用分辨率单帧可能不够最好能用上HDR或者多帧合成。对焦反而是按一下对一下不需要全程追焦。视频录制和直播要的是帧率和码率稳定性优先编码器硬编支持优先。这里防抖和发热控制往往比解析力更重要。4.2 场景参数矩阵一张表讲清楚我习惯把不同场景的参数整理成一张矩阵表后续做优化、做灰度、做问题排查都直接查表场景目标分辨率目标帧率对焦策略3A策略关键降级边界扫码720p30连续对焦/固定焦距AE锁定帧率下限15fps人像1080p30连续AF人脸优先AWB自动分辨率下限720p普通拍照主摄最大单帧单次对焦HDR/多帧可用曝光/ISO上限兜底视频录制1080p/4K30/60连续AF防抖优先帧率稳定度优先直播720p/1080p30连续AF码率优先优先降码率而非帧率这张表不是拍脑袋定的每条都来自线上数据。比如扫码帧率下限15fps——实测很多低端机在暗光下扫二维码头帧率一旦掉到15fps以下连续帧之间的模糊会让解码成功率暴跌。这条降级边界后来直接做成了策略层的红线宁可降低分辨率也绝不跌破帧率。4.3 链路分离与动态切换场景调优不只是参数不同链路本身也要分离。预览链路、拍照链路、分析链路用于扫码/人脸/OCR、录像链路是四条独立的数据通路不能一股脑全开。全开的结果就是ISP和DDR带宽被耗尽中端机直接卡死。动态切换场景时我的经验是尽量不重建CameraSession。重建意味着几十毫秒到上百毫秒的黑屏和重新曝光有些场景根本等不起。正确的做法是先停掉不再需要的分析流或录像流更新RepeatingRequest模板替换场景参数再绑定需要的目标Surface比如从预览流切换到拍照流最后用设置新的会话交替配置替换旧配置这套流程在安卓Camera2和CameraX上都有对应的机制难点不在API而在于工程上要有一个明确的状态机避免切换过程中收到用户连点操作导致状态错乱。4.4 场景冲突的处理原则多场景并发是躲不开的最常见的是录像中点击拍照。两个场景抢同一个主摄的曝光和ISP资源处理不好就是录像掉帧拍照糊片。我的方案是优先保证主场景不崩。录像时点击拍照如果设备支持逻辑多摄优先用超广角或者副摄做拍照如果不支持则降低录像帧率到可接受的范围给拍照留出资源。如果平台实在扛不住同时操作宁可拦截拍照请求给出提示也不要让录像质量崩掉。这个决策要跟产品提前对齐不能纯技术自己拍板——但在工程上主场景优先这条原则不变。5. 三个策略之外的保命工程监控、灰度与回归策略定好了代码写完了不代表就稳了。相机模块的特殊性在于很多问题只在部分机型、部分系统、部分光照条件下出现没有监控和灰度体系出了问题你甚至不知道该不该回滚。5.1 监控指标怎么定才有效相机模块的监控不能只看崩溃率。以下几个指标是我每次都要求团队埋上的打开耗时从用户点击到首帧出现分机型聚合超过阈值即告警。出帧稳定性连续N帧帧间间隔的p95/p99。这比平均帧率更能反映卡顿。黑屏/无帧上报预览会话超时无帧是最直接的适配失败信号。会话异常率创建失败次数、降级命中路径、最终使用的档位。硬件错误回调系统Camera HAL主动上报的错误类型。埋点维度必须是机型系统版本场景三键组合。只看聚合值没有意义一台低端机把整体p95拉高了你会误判成所有机型都有问题。5.2 相机专项灰度的正确打开方式相机模块灰度有两个容易踩的坑一是一次灰度太多参数出问题定位不到元凶二是只看崩溃率漏了卡顿这类体验问题。我的做法是参数维度独立开关HDR开关、帧率开关、分辨率开关、防抖开关各自独立。灰度某个新方案时先把旧方案保留再用反向名单把没测过的机型全部留在旧链路已覆盖机型逐步放量。放量节奏上低中高三个梯度各放一定比例。每个阶段盯两个东西指标差是否超过阈值尤其是出帧稳定性和会话异常率降级报告里出现了哪些新机型提示相机灰度最怕的是看起来没问题。崩溃率没涨不代表体验好了。必须监控黑屏率和帧稳定性否则低端用户就是在默默忍受卡顿而你完全不知道。5.3 真机回归矩阵买哪些机器、测哪些用例真机采购不能只看旗舰机全家桶要让中低端机占大头。我的矩阵思路是主流SoC平台至少各一台——高通、联发科、以及其他自研平台必须有一台千元机必须有一台老系统版本设备必须有一台搭载逻辑多摄的新机。测试用例至少要覆盖这些路径冷启动打开相机、前后摄快速切换、连续多张连拍、长时间录像发热、低光场景切换、亮度突变开关灯、扫码场景连续触发、息屏唤醒后快速恢复、两个应用同时抢相机。特别强调亮度突变这一个用例AE收敛算法在不同平台上的表现差异巨大而且很容易被常规测试漏掉。5.4 灰度日志保留与降级报告灰度期一定要保留完整的降级报告日志保存周期至少一个版本迭代。相机模块的问题往往不是当轮灰度就全部暴露的很多坑是一个季度后系统升级才蹦出来。降级报告里如果出现某个机型的汇聚这就是优化方向的最可靠依据。我之前就有过这样的经历一款中端机的降级报告连续三个版本都在同一个分辨率档位出现后面专门针对它做了ISP参数校准成功率一下提了十个百分点。没有日志这种事只能靠猜。我还有一个习惯碰到新机型第一件事不是跑Demo而是把它的能力矩阵打印出来读一遍。看它支持哪些尺寸、哪些帧率、HDR能不能和30fps共存、防抖走的是EIS还是OIS。这些信息基本能预测这台机器上线后会不会出问题比对着白名单猜准得多。相机适配做到后面其实就是把猜换成探测、试换成验证的过程。