超大分辨率引发的闪退，图像处理与内存防爆指南

测试同学发来一个截图，红色的内存溢出（OOM）日志极其刺眼。她只是简单地点了一下"修改头像"，从相册选了一张用单反相机拍的高清原图，整个 App 就瞬间闪退了。

移动端处理图片，最忌讳的就是"不解压直接上"。一张在硬盘上只有 20MB 的 JPEG 图片，在内存里解压成未压缩的位图时，体积会膨胀几十倍。这就是为什么明明手机有 8G 内存，却连一张图都加载不了的原因。

算一笔内存账

我们来看一下内存是怎么被吃光的。假设图片分辨率是 6000 x 4000。

如果我们用默认的 RGBA_8888 格式加载（每个像素由红、绿、蓝、透明度四个通道组成，每个通道 8 位，也就是 1 个字节）。

总内存 = 6000 * 4000 * 4 = 96,000,000 字节，约等于 91.5 MB。

如果你在一个列表里加载了五张这样的图片，内存瞬间逼近 500MB，系统会毫不犹豫地把你干掉。

在解码阶段就压缩

解决这个问题的核心逻辑是：不要先解压成完整的大图再去缩小，而是让底层解码器只吐出你需要的那个小尺寸。这就是降采样。

在 HarmonyOS 中，通过 ImageSource 获取 PixelMap 时，必须传入 desiredSize。

typescript

复制代码

const imageSource = image.createImageSource(file.fd);

const decodingOptions: image.DecodingOptions = {
  // 直接告诉系统，我只要 300x300 的图
  desiredSize: { width: 300, height: 300 },
  // 警示：如果图片不需要透明度，强烈建议使用 RGB_565 格式
  // 每个像素只占 2 个字节，内存直接砍半！
  desiredPixelFormat: image.PixelMapFormat.RGB_565 
};

const pixelMap = await imageSource.createPixelMap(decodingOptions);

加上这个设置后，原本 90MB 的解码内存，瞬间降到了不到 1MB。图片展示极度流畅。

跨语言内存的释放陷阱

在重构过程中，我遇到了一个更诡异的问题：用户反复修改头像十几次后，应用虽然没有崩溃，但变得极度卡顿。

这是因为 PixelMap 的内存并不由 ArkTS 的垃圾回收器（GC）管理，而是由底层的 C++ 渲染引擎管理。如果你不断地创建新的 PixelMap 赋值给 Image 组件，旧的 PixelMap 对象依然会被底层引用，造成严重的内存泄漏。

务必注意： 每次替换新图之前，只要旧图不再使用，必须手动调用 release() 释放它。

typescript

复制代码

if (this.currentAvatarPixelMap) {
  this.currentAvatarPixelMap.release();
}
this.currentAvatarPixelMap = newPixelMap;

重编码与上传优化

本地展示问题解决了，但把 20MB 的原图传上服务器也是个大灾难。我们需要在端侧先做一次重编码，把质量压缩到 80% 左右。

使用 ImagePacker 将 PixelMap 重新打包成 JPEG 文件：

typescript

复制代码

const packer = image.createImagePacker();
const packOptions: image.PackingOption = {
  format: 'image/jpeg',
  quality: 80 // 质量控制在 80，肉眼几乎看不出区别，体积能缩小 80%
};
await packer.packToFile(pixelMap, targetFile.fd, packOptions);

记住一个原则：图片的解码、压缩、写入流，这一整套动作全部是 CPU 密集型操作，千万不要在主线程里做，统统丢进 TaskPool 里。

在相册里挑一张体积最大的原图，用直接加载和降采样两种方式分别测试。用内存分析工具对比一下内存曲线，你会对"降采样"有全新的认识。