图像超分完成，并不等于用户已经拿到一张可保存的图片。处理引擎交出的是一份 PixelMap，而点击“导出 PNG”之后，应用还要经历尺寸检查、异步编码、文件写入，以及内存资源交接。这里最容易被忽略的，不是清晰度，而是处理结果在异步阶段究竟由谁负责保管。

本文用 ImageGate 小样例限定问题范围：已经取得一份外部算法提供的超分结果，源图记录为 1024×768，示例增强结果为 2048×1536；这里只讨论 Image Kit 编码和生命周期，不声称通过某个未经确认的系统“超分 API”完成了放大，也不把配图中的数值视为实测数据。

一、导出动作为什么需要单独设计

图片处理页面通常习惯把“任务完成”写成一个布尔值。放在单步滤镜中或许还能应付，一旦有外部算法回调、页面退出和文件导出，这个值就不够用了。任务显示完成时，源图片可能仍在缓存中；点击导出后，编码器又会持有同一份 PixelMap 一段时间。此时另一处清理逻辑若直接调用 release，就会把还在使用的对象提前回收。

华为在 Image Kit 常见崩溃说明中明确提到这种场景：使用 packToData、packToFile 等异步接口时，传入对象不得在操作结束前被释放或修改。它不是纯粹的“偶现闪退”经验判断，而是官方列出的明确风险。工程上应该让所有权沿着“结果生成 → 校验 → 编码 → 释放”单向流动，而不是几个组件各自决定何时销毁。

我把例子里的任务标记为 SR-208，状态采用 READY、EXPORTING、ENCODED、FAILED 四个文本值。状态仅服务于界面观察，不把它伪装成 Image Kit 提供的枚举；尺寸和最大像素数同样是 Demo 的应用层约束，并非系统固定限额。

二、先做输入闸门，再讨论编码器

如果大图进入编码之前没有任何检查，后面的异常通常很难定位。ImageGate 先看结果尺寸是否合理，再决定是否开始编码。例如 2048×1536 是 3,145,728 个像素，按每像素约四字节估算，单份未压缩像素缓冲约需十二兆字节。真实进程还会产生临时缓冲、压缩器内存与纹理副本，所以这个数字不能当成峰值内存测试结论。

这段是纯 ArkTS 的前置校验逻辑：限制像素数量、拒绝空尺寸，同时输出一个仅用于预算的估计值。它不依赖不存在的超分接口，也不直接操作文件系统。

export interface OutputSize { width: number; height: number }
export interface SizeAudit { pixels: number; estimatedBytes: number }

export function auditOutput(size: OutputSize): SizeAudit {
  const { width, height } = size;
  if (!Number.isInteger(width) || !Number.isInteger(height) ||
      width <= 0 || height <= 0) {
    throw new Error('INVALID_SIZE');
  }
  const pixels = width * height;
  if (!Number.isSafeInteger(pixels) || pixels > 12000000) {
    throw new Error('PIXEL_LIMIT');
  }
  return { pixels, estimatedBytes: pixels * 4 };
}

把检查写在独立方法中，是为了让编码按钮和批量队列使用同一条规则。estimatedBytes 并非 PixelMap 的实际内存占用：像素格式、内存对齐和硬件存储方式都会改变真实数字。不要拿这个估计值与系统可用内存直接相减，然后断言编码一定成功。若业务要求低内存机型稳定运行，还需要独立监测真实峰值和失败恢复路径。

这个闸门也不能替代格式校验。输入可能是 HDR 图片、包含透明通道，或者采用特殊像素格式；即使宽高正常，后续编码仍可能因格式和设备支持差异失败。对于图像超分场景，建议将增强引擎的输出格式和交付格式写在业务契约中，而不是只传递一个模糊的“图片对象”。

三、编码完成之前，不释放传入的 PixelMap

关键代码用官方 Image Kit 的 image.createImagePacker() 与 packToData()。函数约定接收后取得 PixelMap 的所有权：不论成功或失败，都会在 finally 中释放。外部调用方一旦将结果交给此函数，就不能同时裁剪它、再次编码它，或者在页面销毁时先行释放它。这里将返回的 ArrayBuffer 交给后续写盘步骤，写盘操作可以独立于 PixelMap 生命周期。

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

export async function encodeOwnedPixelMap(
  pixelMap: image.PixelMap, taskId: string
): Promise<ArrayBuffer> {
  let packer: image.ImagePacker | null = null;
  try {
    const info = await pixelMap.getImageInfo();
    auditOutput(info.size);
    console.info(`${taskId} state=EXPORTING`);
    console.info(`${taskId} info=${info.size.width}x${info.size.height}`);
    packer = image.createImagePacker();
    const bytes = await packer.packToData(pixelMap, {
      format: 'image/png', quality: 100
    });
    console.info(`${taskId} state=ENCODED`);
    return bytes;
  } catch (err) {
    console.error(`${taskId} state=FAILED ${String(err)}`);
    throw err;
  } finally {
    pixelMap.release();
    packer?.release();
    console.info(`${taskId} release=done`);
  }
}

await 是这段代码真正的分界线。编码器开始工作后，PixelMap 仍需要保持可用；等 packToData 结束，返回的数据缓冲就可以继续交给另一个保存模块处理。finally 不代表成功，它只是保证不论正常还是异常都进入释放流程。调用者若在外层也 release()，就会出现重复释放或状态错乱；因此“谁接管所有权”需要写在接口注释里。

上面展示的是编码为内存数据，不是“图片已保存到相册”。要在沙箱内落盘，后续仍需使用 Core File Kit 写文件并保证写入失败时关闭句柄；若要进系统相册，还涉及媒体资源创建及相关授权或受限访问能力。不能仅凭 state=ENCODED 就向用户弹出“保存成功”，否则用户去相册找不到照片时，日志却显示绿色完成。

四、页面状态只报告本层确实完成的事

示例页面名称为 ExportPage.ets，按钮文字采用“导出 PNG”。上层超分模块必须通过明确的交接函数提供 PixelMap；在没有结果时按钮应不可用。本段只展示页面的异步调用位置和状态更新方式，资源获取入口由实际项目集成，绝不假设框架存在自动回调。

// 此片段放在 ExportPage.ets 的 @Component 内；
// enhanced 由项目已有的图像处理模块显式交付。
@State private status: string = 'READY';
@State private busy: boolean = false;
private readonly taskId: string = 'SR-208';

private async onEnhancedReady(enhanced: image.PixelMap): Promise<void> {
  if (this.busy) { throw new Error('BUSY'); }
  this.busy = true;
  this.status = 'EXPORTING';
  try {
    const data = await encodeOwnedPixelMap(enhanced, this.taskId);
    // 这里仅确认编码已完成；实际写盘由调用方继续实现。
    if (data.byteLength <= 0) { throw new Error('EMPTY_OUTPUT'); }
    this.status = 'ENCODED';
  } catch (_) {
    this.status = 'FAILED';
  } finally {
    this.busy = false;
  }
}

这里 busy 是页面层的并发闸门。忙碌时拒绝本次交接，新的 PixelMap 所有权仍属于调用方，不能在忙碌分支贸然释放可能与在途编码共享的引用。它无法阻止另一个模块擅自访问 PixelMap，所以要与服务层的所有权约定共同工作。若业务允许连续导出，建议为每个增强结果创建独立所有权记录和任务队列，不要让多个并发编码直接共享同一对象。示例中的 status 是普通业务状态，不能当成 API 官方返回结果。

开发图把重点放在 packToData 的 await 和 release 的先后顺序，同时展示任务 SR-208 的约定日志。它们是为了说明预期顺序构造的日志行，不是 DevEco Studio 实机采样。真正落地时，应在编码之前、结束之后以及 finally 中记录任务 ID、图片宽高、失败类型，再对照异常堆栈检查是否有跨层提前释放。

五、按任务标识检查结果，而不是凭肉眼判断

测试方案可以设计得很明确。第一组输入正常尺寸，确认页面从 READY 进入 EXPORTING，再到 ENCODED；第二组构造超出应用限额的结果，确认被 PIXEL_LIMIT 拦截并进入失败路径；第三组在编码过程中返回上一页，检查页面销毁是否会抢先释放资源。最后一组才是真正定位生命周期问题的关键，因为单纯重复点击按钮并不一定触发它。

示意手机画面显示任务 SR-208、源图 1024×768、增强图 2048×1536 和状态 ENCODED。这些是为了让文章和配图共享同一套状态字段而预设的数据，并非系统返回值，也没有假装取得真实耗时、内存峰值或文件字节数。界面里将“编码完成”和“写盘未执行”并列展示，特意提醒用户不要误把内存缓冲生成视作持久化成功。

六、真正上线前还要补两条链路

第一条是页面与任务生命周期隔离。用户离开页面时，可以停止 UI 更新，但不等于正在进行的图像编码就能瞬间中断。若后台工作不随页面销毁，任务所有权应该放到比页面更稳定的服务对象，并记录终止后如何释放。不应在 aboutToDisappear 里简单遍历所有 PixelMap 然后全部 release()，因为其中可能还有未完成的编码。

第二条是失败后恢复。编码异常、磁盘空间不足、相册授权取消和用户主动取消不是同一类错误。可以分别提供“重新编码”“重新选择保存位置”“返回编辑页”的策略；对于已经释放的 PixelMap，重试必须重新取得可用结果，不能继续调用那个释放后的引用。若超分模型输出需要高成本重算，应评估受控缓存，但仍需给缓存配置上限和明确释放节点。

这个例子真正希望保留下来的结论，是把一次“导出图片”拆成可核验的阶段。ENCODED 只代表内存编码成功，SAVED 才应该在写盘确认后出现；release=done 则是生命周期收口标记，不能和结果成功混为一谈。

参考资料：华为开发者文档《Image Kit常见崩溃报错问题》（2026-09-09），https://developer.huawei.com/consumer/cn/doc/doccenter-capabilities/image-common-mistakes ；《图片绘制（ArkTS）》，https://developer.huawei.com/consumer/cn/doc/harmonyos-guides-v5/pixelmap-drawing-arkts-V5 。