HarmonyOS 鸿蒙Next HDR Vivid影像开发：从拍照到录像的避坑与思考

HarmonyOS 鸿蒙Next HDR Vivid影像开发：从拍照到录像的避坑与思考 最近因为项目需要，花时间把HarmonyOS的HDR Vivid相机开发（拍照和录像）从头到尾撸了一遍。官方文档写得很详细，但真正动手时发现有些坑点还是值得拿出来聊聊，顺便也理一理自己的思路。这篇文章不是教程复述，更像是一个开发者的实践笔记，希望能给正在或准备做这块的朋友一些参考。

一、先搞明白：HDR Vivid到底给相机带来了什么？

在接触具体API之前，我花了一点时间理解HDR Vivid的本质。简单说，它让照片和视频能记录更亮的亮部、更深邃的暗部，以及更丰富的色彩。对比SDR，最直观的感受是：逆光人像不再死白或死黑，日落时分的天空色彩过渡更平滑。

从开发角度看，这个“质变”其实就体现在几个关键的参数设置上：

• 拍照：色彩空间从 SRGB 切换到 DISPLAY_P3。
• 录像：色彩空间从 BT709_LIMIT 切换到 BT2020_HLG_LIMIT，同时像素格式要选10bit的 P010。

明白了这个底层逻辑，再看API就清晰多了——我们做的，就是通过代码告诉相机硬件：“请用更宽的色域和位深来采集数据”。

二、实战中的“意料之外”与解决思路

1. 兼容性检查不是“可选”，而是“必须”

拿到一台新设备，第一件事就是跑一遍 getSupportedColorSpaces() 和Profile查询。千万别假设所有HarmonyOS设备都支持HDR Vivid。我们在调试中就遇到过一台中端设备，拍照支持 DISPLAY_P3，但录像却不支持 BT2020_HLG_LIMIT 和 P010 格式。

建议的优雅降级策略：

• 如果支持HDR，就按HDR流程走。
• 如果不支持，代码分支自动切换回标准的SDR拍照/录像流程，并给用户一个清晰的提示（比如“当前设备不支持HDR录像，已切换至普通模式”）。

2. 录像的“顺序”问题，折腾了我一下午

录像流程里有个细节文档特别强调了，但我一开始没在意：色彩空间设置（setColorSpace）必须在 commitConfig 之前，而视频防抖设置（setVideoStabilizationMode）必须在 commitConfig 之后。

如果不小心把防抖设置在 commitConfig 之前，接口不会报错，但防抖实际上没生效，导致录制的HDR视频画面有轻微晃动（因为HDR对抖动更敏感）。所以记住这个口诀：“色彩提交前，防抖提交后”。

3. AVRecorder的“坑”：宽高比和Surface ID

录像需要结合 AVRecorder。这里有两个容易忽略的点：

• 宽高比必须一致：传给 AVRecorder 的分辨率（如640x480）和传给 VideoOutput 的Profile分辨率必须完全一致，并且预览流的宽高比也要与之匹配，否则会报错或画面变形。
• Surface ID的生命周期：从 avRecorder.getInputSurface() 获取的ID，用于创建 VideoOutput。这个Surface在 avRecorder.prepare() 之后才有效，并且在录像结束后需要妥善释放，否则会影响下一次录像。

三、关于流程设计的一些思考

拍照与录像的流程对比

把两个流程放在一起看，会发现核心骨架其实是一样的：

这个对比表帮我在设计统一相机模块时，能清晰地区分两个流程的差异点，复用大部分公共代码。

关于“预览”与“最终效果”的差异

无论拍照还是录像，预览画面通常都显示为SDR效果。这意味着用户通过取景器看到的，并不是最终的HDR效果。这在产品设计上需要有所考虑，比如可以在UI上增加一个“HDR已开启”的标识，让用户知道当前工作模式，避免产生“怎么开了HDR没变化”的疑惑。