HarmonyOS 鸿蒙Next中我开发了个应用 png888camera,各位能给出点意见吗?

HarmonyOS 鸿蒙Next中我开发了个应用 png888camera,各位能给出点意见吗? 看看有没有什么可以优化的。

5 回复

可以打五星好评吗 ,提出改进点,

更多关于HarmonyOS 鸿蒙Next中我开发了个应用 png888camera,各位能给出点意见吗?的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html


应用在哪里,看不到啊?

应用商店搜了下啊,

在鸿蒙Next中开发相机应用,需使用ArkTS语言及@ohos.multimedia.camera API实现拍摄功能,同时申请ohos.permission.CAMERA权限。png888命名可能涉及PNG格式处理,需确认鸿蒙对888色彩深度图片的编码支持。注意应用需适配Stage模型,避免使用Java或C接口。

  1. 相机流格式选型 原生相机预览流通常是 YUV420_888 或 NV21,保存为 PNG 需要 CPU 转码。如果使用 image.ComponentImageReceiver 解码再编码 PNG,每帧都会走一次软件 JPEG 压缩或 YUV→RGBA8888→PNG 的流水线,热路径开销很高。检查是否直接使用了 photoOutputcapture() 并手工转换,不然后台容易触发功耗限频。

  2. 内存副本与 pixelMap 复用 每次拍照如果 new 一个 image.PixelMap,再调用 packToFileimage.createImagePacker 输出 PNG,会重复申请大块内存。优化:预分配一块 RGBA8888 缓冲区,复用 PixelMap(通过 image.createPixelMap 的 buffer 参数),利用已有的 NativeBuffer 避免 JS 层的频繁 GC 触发。

  3. 颜色空间对齐 888 表示每个通道 8 位,但如果数据来自相机 YUV,转换时务必指定正确的色域(sRGB/P3)。在 ArkUI 显示预览时,Image 组件隐式按 sRGB 渲染,若相机输出是 P3 但未转换,PNG 保存时会偏色。建议在 ImageConverter 里显式配置 PixelFormat.RGBA_8888ColorSpace.SRGB

  4. exif 与 metadata 嵌入 PNG 没有标准 Exif 头,但可以嵌入 iTXt 或 zTXt 块记录拍照参数。如果依赖 photoAccessHelper 创建媒体资源,默认不写 PNG 元数据,可考虑把关键信息(ISO、曝光时间、白平衡)用 image.PropertyKey.IMAGE_DESCRIPTION 塞进 PixelMap 的 property,再打包进 PNG。

  5. 零 copy 写入文件 如果使用 imagePacker.packingFromPixelMap 直接写文件描述符,确保文件打开时使用 fs.open 且 close 放 finally;更高效的方式是用 imagePacker.packingFromPixelMap 拿到 ArrayBuffer 后,通过 fileIo.writeSync 批量落盘,减少 fd 的碎片化写入。

  6. 多线程与任务调度 在拍照保存场景里,转码和写盘放在 Worker 或 TaskPool 里执行,主线程只负责 UI 恢复。注意 Worker 间传递 pixelMap 需要使用 Sendable 类型或 transferDetached,否则仍会跨线程序列化造成负担。ArkUI 侧预览可使用 XComponent 绑定 Surface,避免主线程阻塞。

  7. 权限与隐私保护 HarmonyOS Next 对相机的权限分级更严,检查 module.json5 里 ohos.permission.CAMERA 是否为 user_grant 级别,且运行时正确调用 abilityAccessCtrl.requestPermissionsFromUser。如果应用退到后台继续保存任务,需配置后台任务(短时任务 requestSuspendDelay),否则系统会终止进程导致 PNG 写入不完整。

  8. 文件命名与沙箱路径 保存到应用文件目录时使用 context.filesDircontext.cacheDir,避免使用绝对路径。如果保存到相册,必须通过 photoAccessHelper 创建资产,不可直接写 media 目录。PNG 文件命名带上时间戳防重名,用 systemDateTime.getTime()Date.now() 精度更高。

  9. 性能打点与 tracehiTraceMeter.startTrace 分段记录:相机取流耗时、YUV 转 RGBA 耗时、PNG 压缩耗时、文件落盘耗时。对 1200 万像素图片,总时长远超 800ms 就说明中间有阻塞。可以用 SmartPerf 抓 trace,看是否在 libimage_napi 里有长时间的 libpng 同步调用。

  10. 图片尺寸与下采样 如果用户不需要全分辨率,拍照前通过 camera.CaptureSessionsetPhotoRotation 或设置 pictureSize 时把宽高降一半,会成倍减少 PNG 编码压力。或者保留原图但用 image.ScaleMode.FIT_TARGET 压缩到一个缩略图 PNG,主图后台异步保存。

以上是你可以直接对照检查的点。用 hdc shell 拿应用吞吐和帧时间就能验证大部分优化效果。

回到顶部