HarmonyOS技术精讲-Camera Kit（相机服务）第11篇：分段式拍照实践-平芜编程栈

《HarmonyOS技术精讲-Camera Kit（相机服务）第11篇：分段式拍照实践》

为什么需要分段式拍照

HarmonyOS NEXT 的相机开发里，拍照速度是一个容易被低估的坑。大部分开发者第一次实现拍照功能时，会直接用PhotoOutput.capture等待完整照片返回——这个操作在普通场景下没问题，但如果设备正在处理高分辨率图像、HDR 合成或者多帧降噪，回调时间可能长达 2-3 秒。

分段式拍照（Deferred Capture）解决的是这个问题：拍照动作和照片处理解耦。用户按下快门瞬间得到一张“快速预览图”，后台继续计算完整照片。用户不用死盯着取景框等转圈，体验差距很明显。

这个方案适合拍照速度敏感的 App（社交分享、扫码记录），不适合需要实时预览照片元数据的场景（专业摄影、科研分析）。如果业务上要求每次拍照后立刻拿到完整照片去校验，分段式反而增加了复杂度。

环境说明

DevEco Studio 版本：DevEco Studio 6.1.0 及以上 HarmonyOS SDK 版本：HarmonyOS 6.1.0(23) 及以上 目标设备：手机

核心实现：分段式拍照完整流程

1. 初始化相机和预览流

第一步也是被很多人忽略的一步：分段式拍照依赖DeferredPhotoOutput对象，但它必须在CameraSession配置阶段就绑定。不能等用户按下快门再去创建。

import{camera}from'@kit.CameraKit';import{image}from'@kit.ImageKit';import{common}from'@kit.AbilityKit';letcameraManager:camera.CameraManager;letcameraInput:camera.CameraInput;letpreviewOutput:camera.PreviewOutput;letdeferredPhotoOutput:camera.DeferredPhotoOutput;letsession:camera.PhotoSession;asyncfunctioninitCamera(context:common.Context,surfaceId:string):Promise<void>{// 获取 CameraManagercameraManager=camera.getCameraManager(context);if(!cameraManager){console.error('CameraManager init failed');return;}// 获取可用相机constcameras:Array<camera.CameraDevice>=cameraManager.getSupportedCameras();if(cameras.length===0){console.error('No camera available');return;}// 创建会话 - 这步很关键，后续所有Output都要在session中配置session=cameraManager.createSession('photo')ascamera.PhotoSession;session.beginConfig();// 创建相机输入cameraInput=cameraManager.createCameraInput(cameras[0]);awaitcameraInput.open();session.addInput(cameraInput);// 创建预览输出previewOutput=camera.createPreviewOutput(surfaceId);session.addOutput(previewOutput);// 创建分段式拍照输出 - 重点！deferredPhotoOutput=camera.createDeferredPhotoOutput();session.addOutput(deferredPhotoOutput);awaitsession.commitConfig();awaitsession.start();}

这里有一个容易踩的坑：createDeferredPhotoOutput创建的是专门用于分段式拍照的 Output 对象，它和普通PhotoOutput互斥——不能同时添加到同一个 Session。如果业务上还需要普通拍照，必须两个 Session 切换。

2. 实现快速拍照按钮

用户按下快门时，核心逻辑是调session.startDeferredPhoto，而不是deferredPhotoOutput.capture。这一点设计有些反直觉。

@StatephotoCount:number=0;@StatelastPhotoUri:string='';privatecaptureReady:boolean=false;// 快速拍照按钮的点击回调asyncfunctiontakeQuickPhoto():Promise<void>{if(!deferredPhotoOutput||!session){console.error('Camera not initialized');return;}if(!captureReady){console.warn('Previous capture still processing');return;}captureReady=false;try{// 关键API: 启动分段式拍照awaitsession.startDeferredPhoto((err:BusinessError,photo:camera.DeferredPhoto)=>{if(err){console.error(`Deferred photo error:${err.message}`);captureReady=true;return;}// 收到快速预览图回调console.info(`Quick photo received, id:${photo.photoId}`);// 可以在这里展示缩略图// 注意：photo.image 是 PixelMap，可以直接绑定到 Image 组件handleQuickPhoto(photo);});}catch(error){console.error(`Capture failed:${error}`);captureReady=true;}}functionhandleQuickPhoto(photo:camera.DeferredPhoto):void{// photo.image 是快速预览图if(photo.image){// 假设 UI 有一个 @State 绑定的 image 变量// this.quickPhoto = photo.image;console.info('Quick photo pixelMap received');}// 注册后台处理完成的回调photo.on('photoAvailable',(err:BusinessError,result:camera.Photo)=>{if(err){console.error(`PhotoAvailable error:${err.code},${err.message}`);}else{// result 是最终完整的照片console.info(`Full photo available:${result.mainUri}`);// 更新UI, 保存到相册等操作handleFullPhoto(result);}// 允许下一次拍照captureReady=true;});}functionhandleFullPhoto(photo:camera.Photo):void{// 获取完整照片的uriconstphotoUri=photo.mainUri;console.info(`Full photo saved at:${photoUri}`);// 更新UI状态// this.lastPhotoUri = photoUri;// this.photoCount++;}

注意captureReady标志位的设计——很多人在这个逻辑里出现并发问题，连续点击快门时、上次处理还没完成就去触发下一次，导致startDeferredPhoto被多次调用，Session 内部状态紊乱。实际开发里这是高频错误。

3. 注册后台处理完成的通知

分段式拍照的核心机制就是“先给你预览图，后台算完再通知”。这个通知依赖photoAvailable事件，事件触发时返回的Photo对象已经携带了完整照片的文件 URI。

监听这个事件有生命周期限制：如果页面在后台处理完成前被销毁，事件监听也会被回收。推荐在onPageHide或组件卸载时临时保存一个标识，等页面恢复后重新查询。

@Entry@Componentstruct CameraPage{@StatequickPhotoPixelMap:PixelMap|null=null;@StatefullPhotoUri:string='';@StatetakeEnabled:boolean=true;build(){Column(){// 预览区域XComponent({id:'cameraXComponent',type:XComponentType.SURFACE,controller:newXComponentController()}).width('100%').height('70%')// 快速预览缩略图if(this.quickPhotoPixelMap){Image(this.quickPhotoPixelMap).width(80).height(80)}// 拍照按钮Button('快速拍照').width(120).height(120).borderRadius(60).backgroundColor(this.takeEnabled?'#007AFF':'#999').enabled(this.takeEnabled).onClick(()=>{this.takeQuickPhoto();})// 最后一张完整照片状态if(this.fullPhotoUri){Text(`完整照片已保存:${this.fullPhotoUri}`).fontSize(14)}}.width('100%').height('100%')}asynctakeQuickPhoto():Promise<void>{// 复用上面的 takeQuickPhoto 函数，同时更新 UI 状态this.takeEnabled=false;// ... 完整实现}}

常见问题

问题1：页面返回后后台照片丢失

现象：用户拍照后立刻返回首页，后台照片处理完成后找不到 UI 实例去触发回调。

原因：photoAvailable回调绑定在DeferredPhoto对象上，这个对象生命周期跟随当前 Page。页面销毁后，回调自然失效。

解决方案：不要在回调里直接更新 UI，改为向全局事件总线发送事件，或者写入本地数据库。推荐用EventHub。

// 在 onPageShow 时注册全局监听onPageShow():void{AppStorage.setOrCreate('photoAvailable',(uri:string)=>{// 更新UIthis.fullPhotoUri=uri;});}

问题2：连续快速拍照导致 Session 报错

现象：用户在 0.5 秒内连续点击拍照按钮，控制台出现camera session is busy。

原因：startDeferredPhoto是异步操作，内部有防重入机制。但并发调用没有做保护，第二次调用时前一次还在执行。

解决方案：加一个boolean锁，配合try/finally确保状态回滚。上面的takeQuickPhoto已经演示了这个方案。

问题3：模拟器上拍照无响应

现象：代码在真机上正常，在模拟器上点击拍照按钮没有回调。

原因：分段式拍照依赖硬件 ISP 后处理能力，模拟器模拟的相机 API 不完整，startDeferredPhoto可能直接返回错误或永不回调。

解决方案：只在真机上测试此功能。代码里可以加systemCapability判断：

if(canIUse('SystemCapability.Multimedia.Camera.DeferredPhoto')){// 支持分段式}else{// 回退到普通拍照}

最佳实践

不要把session.startDeferredPhoto放在异步函数的 finally 块里
很多人为了确保锁释放，在 finally 中调用session.startDeferredPhoto。但 Session 状态机不允许连续调用，finally 释放锁后如果用户再次点击，第二次调用还在前一次处理中。正确的做法是在photoAvailable回调里释放锁。
预览图拿到后尽快展示并释放内存
DeferredPhoto.image是 PixelMap，如果占用着持有不释放，内存占用会持续增大。拿到 PixelMap 后转成 BitMap 显示，然后手工释放原对象。ArkTS 的垃圾回收机制不如 Java 及时，建议在onPageHide时释放所有 PixelMap 引用。
控制后台处理超时
官方没有暴露后台处理超时时间。实测某些设备在多帧降噪场景下，完整照片生成可能超过 10 秒。如果业务上需要，建议在takeQuickPhoto的同时启动一个定时器，超过 5 秒后提示用户“照片正在后台处理，稍后查看”。避免用户觉得 App 无响应。