HarmonyOS 7 图像超分连续处理会涨内存：任务队列、取消与 destroy 怎么设计

HarmonyOS 7 图像超分连续处理会涨内存：任务队列、取消与 destroy 怎么设计

图像超分最容易演示成功，也最容易在真实页面里出问题。用户快速滑过十张缩略图，如果应用为每一张图同时创建分析任务，即使最终只展示最后一张，前面的解码、推理和 PixelMap 仍可能继续占用资源。页面看起来只是“偶尔卡一下”，多进出几次后才出现内存上升甚至被系统回收。

HarmonyOS 7/API 26 从 26.0.0 开始提供图像超分能力。官方链路是创建 ImageSRAnalyzer、准备 PixelMap 请求、调用 process，并在不再使用时 destroy。工程问题不在于少写一行接口，而在于谁拥有分析器、同时允许多少任务、旧请求如何失效、结果由谁释放。

验证与边界：本文先核对华为官方文档与 API 版本，再用可执行的宿主逻辑测试验证状态转换、排序、幂等或资源预算。当前本机 DevEco SDK 为 API 24，且没有 HDC 真机，因此文中的 API 26 接口代码属于依据官方签名整理的接入骨架，不宣称已经完成 API 26 工程编译或真机实测。正式上线前仍需在 API 26 SDK 与目标设备上完成编译、运行、异常分支和资源指标验收。

先定资源所有权

一个页面实例持有一个分析器，比每次点击都创建一个更容易管理。页面出现时创建，页面退出时停止接收新任务，等待或丢弃旧结果，再销毁分析器。不要让列表项各自持有分析器，否则资源数量会跟可见项和复用次数一起增长。

import { imageSuperResolution, visionBase } from '@kit.CoreVisionKit';

class SuperResolutionSession {
private analyzer: imageSuperResolution.ImageSRAnalyzer | null = null;
private generation: number = 0;

async open(): Promise<void> {
this.analyzer = await imageSuperResolution.ImageSRAnalyzer.create();
}

cancelOlderJobs(): number {
this.generation += 1;
return this.generation;
}

async close(): Promise<void> {
this.generation += 1;
await this.analyzer?.destroy();
this.analyzer = null;
}
}

generation 不是取消系统推理的官方接口，它是应用侧的结果失效标记：旧任务即使返回，也不再覆盖当前 UI。代码中要明确这一点，不能把“忽略旧结果”描述成“系统任务已取消”。

案例一：轮播图只需要最后一次结果

快速切换时使用“最新任务优先”。每次选择新图片都增加版本号，结果返回后先比对版本；版本过期就释放该结果，不更新页面。

interface Job { id: number; source: string; estimatedMb: number }
function selectLatest(queue: Job[], budgetMb: number): Job[] {
const latest = queue.at(–1);
return latest && latest.estimatedMb <= budgetMb ? [latest] : [];
}

console.assert(selectLatest([
{ id: 1, source: 'a.jpg', estimatedMb: 32 },
{ id: 2, source: 'b.jpg', estimatedMb: 28 }
], 40)[0].id === 2);

这里不适合 FIFO。用户已经切到 B 图，再处理 A 图不会带来可见价值，只会占用内存和推理时间。选择“只保留最新任务”是体验与资源之间最直接的取舍。

案例二：老照片批处理必须完整完成

批处理与轮播图相反，用户希望每一张都处理完成。此时采用有界 FIFO，每次只运行一个或少量任务，记录每张图片的输入路径、输出路径、状态和失败原因。进程恢复后从未完成项继续，不重新处理成功项。

type BatchState = 'WAITING' | 'RUNNING' | 'DONE' | 'FAILED';
interface BatchItem { path: string; state: BatchState; retries: number }

function nextBatchItem(items: BatchItem[]): BatchItem | undefined {
return items.find(v => v.state === 'WAITING' || (v.state === 'FAILED' && v.retries < 2));
}

console.assert(nextBatchItem([
{ path: '1.jpg', state: 'DONE', retries: 0 },
{ path: '2.jpg', state: 'FAILED', retries: 1 }
])?.path === '2.jpg');

这个案例需要 FIFO 和断点续跑，不能照搬轮播图的“只留最后一次”。同一个 API 在不同产品目标下，调度策略必须不同。

内存预算不要只看文件大小

压缩图片文件只有几百 KB，解码后的 PixelMap 可能按宽 × 高 × 每像素字节数占用数十 MB；超分输出尺寸更大，还可能同时存在输入、输出和中间结果。任务入队前应估算解码内存，并预留页面本身、缓存和系统波动空间。

function rgbaMemoryMb(width: number, height: number): number {
return width * height * 4 / 1024 / 1024;
}

console.assert(Math.round(rgbaMemoryMb(4000, 3000)) === 46);

如果预算不足，优先降低并发、延后处理或要求用户确认，而不是偷偷降质后仍称“高清修复”。输出尺寸和视觉质量还要用真实图片做前后对比，不能只看 API 成功返回。

三种方案怎么选

上线验收

• 连续切换 30 张图，最终只展示当前图片结果。
• 页面退出后，旧任务不能再次更新 UI。
• 分析器创建失败、处理失败和销毁失败都有日志与用户提示。
• 输入 PixelMap、输出 PixelMap 和页面缓存的所有权明确。
• 批处理被系统中断后可以继续，成功项不会重复执行。
• 在目标设备上记录峰值内存、单张耗时和连续处理温升。

官方资料

• 图像超分开发指南
• Core Vision Kit API 26 变更

超分能力把图片变清晰，任务调度决定应用会不会因此变卡。先设计所有权和预算，再接入推理接口，后续扩展到批处理、后台恢复和多设备时才不会返工。