技术栈：HarmonyOS 7、ArkTS、Image Kit、PixelMap、ImagePacker

Demo：PixelLease；任务：PL-606；以下时间、状态和尺寸均为设计演示数据，不是实机测试记录。

一、图片已经变清楚，导出阶段却可能把应用拖垮

做图像超分时，人们最容易盯着放大倍数、边缘细节和模型耗时。实际工程里，还有一道更隐蔽的关卡：增强后的 PixelMap 能正常预览，并不意味着导出 JPEG 的那一刻就安全。预览结束、页面退出、用户连续点两次“保存”，都有机会改变底层资源的使用时序。

我给这条链路起名 PixelLease。它不实现超分模型，而是假定业务上游已经交付一张增强结果 PixelMap，只讨论“谁持有它、谁有权编码、什么时候释放”。这样选边界有意避开模型差异：放大算法可以替换，资源所有权必须始终明确。演示任务 PL-606，输入图为 1024×768，增强结果为 2048×1536；导出配置采用 image/jpeg、质量 92。数据只是用于核对文章和配图。

这里的关键矛盾不在于 release() 调得早还是晚，而在于编码任务与 UI 生命周期不是同一条时间线。页面已经不再可见，底层异步编码可能仍在工作。把两者混成一个布尔值，会让“关闭页面等于可以回收像素数据”成为危险假设。

二、先划清三类对象的归属，再讨论接口

Image Kit 的 PixelMap 是图像像素载体，ImagePacker 负责封装输出，目标文件描述符则是另一类资源。它们可以在同一个操作中使用，却不该由同一个不加区分的 finally 随手处理。应用需要先决定：本次导出是否独占 PixelMap、目标 fd 由谁打开和关闭、页面离开时由谁等待未完成操作。

华为官方《Image Kit常见崩溃报错问题》（2026-09-09）明确提示：在异步 packToFile 尚未完成时释放或修改 PixelMap，可能造成崩溃；推荐等待异步操作后再释放。官方示例同时展示 image.createImagePacker()、image.PackingOption 和 packToFile()。这几项是本文直接依赖的公开能力，而 PixelLease、PL-606、业务状态码均是示例自定义内容，不能误当系统接口。

业务上把所有权分成三层：上游只负责生成并移交 PixelMap；导出服务从领取到释放期间独占写入权；UI 只订阅“正在编码、已完成、失败”的结果，不碰原生释放方法。对于文件描述符，本文示例约定由调用者打开，导出 Promise 结束后再关闭，因此不会把导出服务写成万能资源管家。

三、把 await 放在 release 前面，才有时序保证

第一段代码解决最底层的问题：不论正常打包还是抛出异常，像素对象在编码 Promise 结束之前都要有效。下面是可以纳入工程的编码服务核心；为突出所有权，目标 fd 由调用者传入，代码不涉及具体目录权限或相册授权流程。

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

export async function packOwnedPixelMap(
  pixelMap: image.PixelMap, fd: number
): Promise<void> {
  let packer: image.ImagePacker | null = null;
  try {
    packer = image.createImagePacker();
    const options: image.PackingOption = {
      format: 'image/jpeg', quality: 92
    };
    await packer.packToFile(pixelMap, fd, options);
  } finally {
    pixelMap.release();
    packer?.release();
  }
}

注意这段函数意味着调用一开始便移交 PixelMap 所有权：即使 JPEG 写入失败，也会执行释放。若上游的预览组件还在引用同一个对象，就不能直接把它传进来；应该在所有权转移前完成预览，或单独准备用于导出的副本。图像组件是否缓存像素、是否需要再次展示，必须结合真实工程验证，不能靠“看起来正常”来推断。

finally 不等于“总能写成可用文件”。编码失败后，目标文件可能只写入了一部分；调用者应在关闭 fd 后删除或标记不完整文件，不能提前把结果加入相册。这里也没有声称 JPEG 编码必然支持每一种 HDR 输入，生产环境还需检查像素格式、目标格式及动态范围支持情况。

四、连续点击和页面退出是两种不同的并发

第二个问题是用户连点：两次调用如果领取同一张 PixelMap，后完成的操作可能引用已释放资源。一个简单 busy 标志能挡住同一实例内的重复进入，但挡不住不同页面各自新建服务实例。于是我让一次导出拥有明确的“正在执行 Promise”，相同任务直接拒绝，而不是再启动第二次打包。

export class ExportGate {
  private occupied: boolean = false;

  begin(): boolean {
    if (this.occupied) {
      return false;
    }
    this.occupied = true;
    return true;
  }

  finish(): void {
    this.occupied = false;
  }
}

ExportGate 是应用内自定义的轻量门禁，不是 Image Kit API。它适合页面共享一个服务实例的情形；如果跨 Ability、跨进程或多个任务并行，应该按照任务 ID 管理独立门禁与资源句柄，不能把一个全局布尔值当作完整调度器。也不能只靠按钮 enabled(false) 防重，因为事件已经投递到业务层时，界面可能尚未刷新。

本轮演示规定 PL-606 的首次点击进入 PACKING，第二次点击记录 IGNORED。编码结束后状态标为 PACKED，PixelMap 标为 RELEASED。这套状态是预设的逻辑演练，不是计时器推出来的真实性能数据；它的价值是使 UI、日志和文件清单拥有同一套术语。

五、把页面存活与底层任务存活分开

页面退出处理的是“结果能否更新 UI”，不负责证明编码可以立即中断。真实业务里，用户在系统多任务界面切走应用，或者在分屏模式下关闭预览页，onPageHide 与异步 Promise 的完成顺序并不固定。正确策略应先禁止对销毁页面回写状态，再由服务自己持有导出任务直到结束，并在 Promise settle 后释放资源。

@Entry
@Component
struct ExportPage {
  @State status: string = 'READY';
  private active: boolean = true;
  private gate: ExportGate = new ExportGate();

  aboutToDisappear(): void {
    this.active = false;
  }

  private async doExport(pixelMap: image.PixelMap, fd: number): Promise<void> {
    if (!this.gate.begin()) {
      console.info('[PixelLease] PL-606 duplicate=IGNORED');
      return;
    }
    if (this.active) this.status = 'PACKING';
    try {
      await packOwnedPixelMap(pixelMap, fd);
      if (this.active) this.status = 'PACKED';
    } catch (err) {
      if (this.active) this.status = 'FAILED';
      console.error('[PixelLease] PL-606 pack failed: ' + String(err));
    } finally {
      this.gate.finish();
    }
  }
  build() { Column() { Text(this.status) } }
}

这段代码是页面与导出服务的连接片段，调用它的事件处理器、上游 PixelMap 交接、fd 的打开关闭仍需在工程中补齐，不能把它理解为复制一个页面文件就能直接运行。aboutToDisappear 只能阻止当前页面回写，并不能暂停内核写入，也不应该在这里直接 pixelMap.release()。如果真要取消编码，要先查证所用 Image Kit 接口是否提供可用取消机制；未查证之前不能伪造 cancelPack() 之类的方法。

还应考虑另一条边界：如果编码服务在同一张图上做了裁剪、缩放，必须等待这些操作结束后再交给 Packer。生产环境通常把“输出像素不可再被修改”写进模块契约，并在代码评审时检查所有异步路径是否持有该引用。

六、如何验证不虚构的“成功”

我会把验收拆成逻辑检查和设备验证两组，而不把两者混写。逻辑检查关注状态次序：同一任务是否只能有一个编码拥有者；失败时释放是否仍能执行；页面退出后有没有异步 UI 回写；第二次点击是不是返回了明确的拒绝原因。这些可以用注入的假 Packer Promise 和假时间调度做单元测试。

设备验证则必须有真实 PixelMap 和真实目标 fd。需要分别测试较大图片、低存储空间、写入权限失败、编码期间退后台、前后台重复进出，以及 HDR/SDR 输入的格式差异。日志至少记录任务 ID、文件创建结果、编码开始/结束、资源释放时机和错误码；若编码失败，不把半成品计入保存成功。本文没有执行这一组测试。

配图中的 14:40:10 [PixelLease] PL-606 state=PACKING fmt=jpeg q=92、14:40:11 [PixelLease] PL-606 duplicate=IGNORED、14:40:12 [PixelLease] PL-606 state=PACKED pixel=RELEASED 只是统一的演示日志。结果页沿用输入 1024×768、输出 2048×1536，预设状态 PACKED、资源 RELEASED。两秒并不是被测得的耗时，更不能据此得出 PixelMap 编码性能结论。

七、工程取舍：宁可少一点“立刻取消”，也不要抢先释放

这类功能表面上是“保存图片”，其实是一次短暂但需要严格约束的资源租约。页面可以关，按钮可以隐藏，导出任务却必须在结束后才释放它所拥有的像素对象。若系统可用内存吃紧，产品可以限制单次导出分辨率，禁止并发大图编码，并在界面明确提示“正在写入，完成前不可重复提交”；这比在 UI 销毁时贸然释放 PixelMap 更可控。

从业务体验上看，完成状态至少应区分“编码 Promise 成功”和“文件已可供用户访问”。前者只是编码接口返回；后者还涉及 fd 关闭、文件有效性、沙箱与相册授权，以及是否有后续提交步骤。本文只负责前一段，不使用未经验证的上架保存能力来填空。

最后还有一个容易被忽略的约束：同一张 PixelMap 如果允许“预览、保存、再保存”，单次移交所有权的函数无法独自完成这个需求。解决方法应是在调用前明确复制或重建独立输出对象，或者对上游资源建立引用计数和所有权协议。不能简单删去 release() 来假装问题消失，那只会把立即崩溃风险换成长期内存问题。

结论很简单：先等待编码完成，再按所有权释放；先决定任务可见性，再决定能否回写页面。 这是比“把超分速度调快一点”更值得单独验收的稳定性工作。

资料核对： 华为官方《Image Kit常见崩溃报错问题》（2026-09-09），https://developer.huawei.com/consumer/cn/doc/doccenter-capabilities/image-common-mistakes 。文中 Image Kit API 与资源释放建议以该一手资料为依据；应用自定义类和演示数据不属于官方 SDK。未进行 DevEco 编译、真实设备或实际 JPEG 写盘验证。