项目里有个图片浏览功能，刚上线的时候一切正常，图片加载快、滑动流畅。后来用户反馈：连续打开几张高清照片后，页面开始卡，再开几张就直接闪退了。我拿日志一看，内存从几十兆涨到几百兆，OOM 了。

一开始我以为是图片文件太大，压缩一下就好了。后来发现问题没那么简单——用户拍的照片是 4000×3000 分辨率的，解码成 PixelMap 以后，按 ARGB_8888 格式算，一张就是 4000×3000×4 = 48MB。连续打开十张就是 480MB，不 OOM 才怪。

更麻烦的是，PixelMap 对象如果不主动释放，内存不会立刻回收。页面来回进出几次，内存只涨不降，越来越卡。这篇就讲讲从"能显示图片"到"显示图片不爆内存"中间踩的那些坑。

一、高清图片为什么会把内存撑爆

先说说这个问题的根源。

很多人以为图片文件大小就是内存占用，其实完全不是一回事。一张 5MB 的 JPG 文件，解码成 PixelMap 以后可能占 48MB 内存。因为 JPG 是压缩格式，文件里存的是压缩后的数据；而 PixelMap 是解码后的位图，每个像素占 4 个字节（ARGB_8888），内存占用 = 宽 × 高 × 4。

一张 4000×3000 的照片，解码后就是 4000×3000×4 = 48,000,000 字节，约 48MB。如果列表里同时显示十张这样的图，就是 480MB，大部分手机的应用内存上限都扛不住。

所以问题的关键不是文件大小，而是解码后的 PixelMap 尺寸。你在一个 200×200 的 Image 组件里显示一张 4000×3000 的图，完全是浪费——组件只需要 200×200 的像素，却解码了 4000×3000 的数据，多占了 400 倍的内存。

正确的做法是按目标尺寸解码。列表里的缩略图只需要 200×200，就解码成 200×200 的 PixelMap，内存占用只有 200×200×4 = 160KB，和 48MB 差了 300 倍。预览页需要全屏显示，就按屏幕尺寸解码，不需要原始分辨率。

二、按目标尺寸解码是第一步

按目标尺寸解码的核心是用 ImageSource 的 decodingOptions，指定目标宽高，让解码器在解码时就做缩放，而不是先解码成全尺寸再缩放。

先解码全尺寸再缩放，内存峰值是全尺寸的大小，缩放后虽然 PixelMap 变小了，但峰值已经过去了，OOM 可能已经触发了。而在解码时指定目标尺寸，解码器会在解码过程中直接采样，内存峰值就是目标尺寸的大小，这才是真正省内存。

下面这段代码放在 ImageLoader.ets 里，封装了按目标尺寸解码图片的逻辑。它在需要显示图片时调用，传入文件路径和目标尺寸，返回解码后的 PixelMap。

import { image } from '@kit.ImageKit';

export class ImageLoader {
  async loadThumbnail(filePath: string, targetWidth: number, targetHeight: number): Promise<image.PixelMap | null> {
    try {
      const imageSource = image.createImageSource(filePath);
      const decodingOptions: image.DecodingOptions = {
        desiredSize: { width: targetWidth, height: targetHeight },
        editable: false
      };
      const pixelMap = await imageSource.createPixelMap(decodingOptions);
      imageSource.release();
      return pixelMap;
    } catch (e) {
      console.error(`[ImageLoader] loadThumbnail failed: ${filePath}, error: ${JSON.stringify(e)}`);
      return null;
    }
  }

  async loadPreview(filePath: string, screenWidth: number, screenHeight: number): Promise<image.PixelMap | null> {
    try {
      const imageSource = image.createImageSource(filePath);
      const imageInfo = await imageSource.getImageInfo();
      // 按屏幕尺寸等比缩放，保持宽高比
      const scale = Math.min(screenWidth / imageInfo.size.width, screenHeight / imageInfo.size.height);
      const targetWidth = Math.round(imageInfo.size.width * scale);
      const targetHeight = Math.round(imageInfo.size.height * scale);
      const decodingOptions: image.DecodingOptions = {
        desiredSize: { width: targetWidth, height: targetHeight },
        editable: false
      };
      const pixelMap = await imageSource.createPixelMap(decodingOptions);
      imageSource.release();
      return pixelMap;
    } catch (e) {
      console.error(`[ImageLoader] loadPreview failed: ${filePath}, error: ${JSON.stringify(e)}`);
      return null;
    }
  }
}

这段代码要解决的问题：loadThumbnail 按指定目标尺寸解码缩略图，适合列表场景；loadPreview 先获取原图尺寸，再按屏幕尺寸等比计算目标尺寸，保证预览图不变形；两个方法都在解码完成后释放 ImageSource，避免资源泄漏。

实际运行时要注意：desiredSize 的具体行为需要根据 API 版本确认——有些版本是精确匹配目标尺寸，有些版本是按比例缩放后取最接近的尺寸。如果对尺寸精度要求高，建议在解码后再检查实际尺寸。另外，editable 设为 false 可以减少内存占用，如果不需要修改 PixelMap 就不要设为 true。ImageSource 用完一定要 release，否则会泄漏底层资源。

三、PixelMap 的释放时机比创建更重要

解码控制了尺寸，内存占用降下来了，但还有一个更关键的问题：PixelMap 用完了要释放。

PixelMap 是一个底层资源对象，它的内存不只是 JS 堆里的那一点，大部分内存在 Native 层。JS 的垃圾回收不会立刻回收 Native 内存，如果你不主动调用 release()，PixelMap 对象可能会在内存里待很久，导致内存只涨不降。

我踩过的坑是：页面里创建了 PixelMap 赋给组件，页面退出后以为组件销毁了 PixelMap 就自动释放了。实际上不是，组件销毁只是解除了引用，PixelMap 对象还在内存里，等 GC 回收可能要等很久。如果用户频繁进出页面，每次都创建新的 PixelMap 而不释放旧的，内存就会持续上涨。

正确的做法是：在页面的 aboutToDisappear 里，主动调用所有 PixelMap 的 release() 方法。列表场景更复杂，因为列表是复用的，滑出屏幕的图片对应的 PixelMap 也应该释放，滑入时再重新加载。这个可以配合 LazyForEach 和 onVisibleAreaChange 来做。

我的做法是建一个 PixelMapPool，管理当前活跃的 PixelMap。页面退出时调用 pool.releaseAll()，列表滑动时根据可见区域释放不可见的 PixelMap。这样内存就能保持在一个稳定的水平，不会越用越多。

四、缩略图和原图的策略要分开

列表页和预览页对图片的需求不一样，不能用同一种解码策略。

列表页只需要缩略图，目标尺寸就是列表项的大小，比如 200×200。这时候解码成 200×200 就够了，内存占用很小。但如果列表有几百项，同时解码几百张缩略图也会有内存压力。我的做法是只解码可见区域的图片，滑出屏幕的释放掉，滑入的再加载。配合 LazyForEach 的按需加载，内存里同时存在的 PixelMap 数量是有限的。

预览页需要更大的图，但也不需要原始分辨率。按屏幕尺寸解码就够了，比如屏幕是 1260×2720，就按这个尺寸等比缩放。用户双指放大的时候，再按需解码更大的尺寸，而不是一开始就加载全尺寸。

还有一个细节：缩略图和原图可以做两级缓存。列表页解码的缩略图缓存到内存里，预览页解码的预览图也缓存，但两者分开存。用户从列表点进预览页，先显示缩略图（已经缓存了，秒开），同时后台解码预览图，解码完成后替换。这样用户体验好，内存也可控。

缓存的大小要有限制。我的做法是 LRU 缓存，最多缓存 20 张缩略图和 3 张预览图，超过上限就释放最久没用到的。缓存不是越大越好，太大了内存压力大，太小了频繁解码影响性能。

五、多图并发和超大图处理

多图并发加载是另一个容易出问题的场景。如果列表一上来就同时解码几十张图，虽然每张都不大，但同时解码的内存峰值可能很高，而且解码本身是 CPU 密集型操作，并发太多会导致 UI 卡顿。

我的做法是控制并发数，同时最多解码 3 张图，其他的排队。用一个简单的队列管理：需要加载的图片加入队列，有空闲的解码槽位就取一个出来解码，完成后再取下一个。这样内存峰值可控，UI 也不会因为解码太多而卡顿。

超大图是特殊情况。比如用户有一张 10000×10000 的图，即使按屏幕尺寸解码，解码器可能也需要先读取完整的图像数据，内存峰值还是很高。这种情况需要用区域解码（region decode），只解码用户当前看到的区域，类似地图的瓦片加载。区域解码的 API 比较复杂，需要根据当前显示的位置和缩放比例动态计算解码区域，这个我目前还没有在项目里实现，需要验证可行性。

损坏图片也要处理。如果图片文件损坏，解码会抛异常。我的做法是在 loadThumbnail 和 loadPreview 里捕获异常，返回 null，页面显示一个占位图。不能让解码异常导致页面崩溃，也不能让一个损坏图片阻塞整个列表的加载。

六、内存监控和边界情况

最后说几个需要注意的边界情况。

内存监控。建议在开发阶段加内存监控，在图片加载和释放的关键节点打印内存占用。这样可以直观地看到内存的涨跌，确认释放逻辑是否生效。HarmonyOS 提供了获取应用内存占用的 API，可以在调试时使用。生产环境不需要一直打日志，但可以在内存超过阈值时上报告警。

页面切换时的状态。用户从列表页进入预览页，再返回列表页，列表页的 PixelMap 应该还在缓存里，不需要重新解码。但如果预览页占用了太多内存，返回列表页时可能需要先释放预览图的 PixelMap，再恢复列表的缩略图。这个顺序要注意，不能先加载列表再释放预览，否则内存峰值会叠加。

低内存设备。不同设备的内存上限不同，高端机可能 512MB 都没事，低端机 192MB 就 OOM 了。我的做法是根据设备内存等级调整缓存大小和并发数：内存大的设备缓存多一些、并发高一些，内存小的设备缓存少一些、并发低一些。设备内存等级可以通过系统 API 获取。

GIF 和动图。如果应用里有 GIF 或其他动图，PixelMap 的处理方式不一样——动图可能需要持续解码多帧，内存占用更高。这个我目前没有深入处理，需要验证动图场景下的内存管理策略。

API 版本兼容性。PixelMap 和 ImageSource 的 API 在不同 HarmonyOS 版本之间可能有差异，比如 DecodingOptions 的字段、createPixelMap 的参数、release 的行为。上面的代码是基于通用写法，实际接入时需要对照当前 API 版本（API 26）的文档确认。特别是 desiredSize 的精确行为和区域解码的支持情况，需要在真机上验证。

把图片解码尺寸控制住、把 PixelMap 释放时机管好了，内存问题基本上就解决了大半。图片加载看起来就是调个 API，但真正在项目里跑起来，解码策略、缓存管理、释放时机、并发控制，每一个环节处理不好都可能导致内存上涨、页面卡顿。把这些环节理顺了，用户连续翻多少张高清图都不会卡。