在图片增强页面里，“把照片放大两倍”听起来只是一项设置，工程上却至少涉及三件不同的事：原始图片究竟有多少像素；放大目标在内存中大约需要什么量级的空间；用户连续更换图片时，较早的异步结果是否还有资格刷新当前界面。把它们揉成一个“开始超分”按钮，错误往往不是出在算法本身，而是出在算法前后没有明确的状态边界。本文围绕一个只做预检、不执行AI超分推理的 ClarityGate 示例展开。图中的图像对比只是视觉演示，不表示已经调用超分服务。官方旧版 HiAI/Android 超分示例与 HarmonyOS ArkTS 的 Image Kit 不是可以直接互换的接口，因此这里不捏造 superResolution.run() 一类调用。我们先把独立、可复用的尺寸预算和异步结果隔离写对，再讨论算法接入点。## 一、先把“尺寸”从“画质”里剥离页面展示固定演示任务 SR-204：输入图为 800 × 600，业务设定的目标倍数为 2×，预计输出尺寸 1600 × 1200。若粗略按每像素四字节的 RGBA_8888 单缓冲估算，所需空间为 1600 × 1200 × 4 / 1048576 ≈ 7.32 MiB。示例设置 12.00 MiB 的业务预检阈值，因此它可以显示“预算通过·待接入算法”。这个阈值是 Demo 自己定义的门槛，不是鸿蒙平台规定的 PixelMap 上限。真实处理链路还可能同时持有原图、临时张量、输出缓冲、纹理和编码结果；一个 7.32 MiB 的算术结果，不能推导出任务只会消耗 7.32 MiB 内存。还要分清两个概念：放大尺寸是输出规格，图像超分是增强算法。一般缩放得到 1600 × 1200，并不意味着恢复了丢失的细节。不建议把“超分成功”作为预检状态名。预检只对当前输入和业务预算负责，它没有资格判断算法质量，也无法确认设备是否支持所选推理模型。页面用三个分段状态表达这一点：待预检、预算通过·待接入算法、超过预算。后续引入模型下载或推理排队时，再扩展独立的执行状态，不反向修改预检含义。## 二、预算计算需要拒绝异常数字先在 BudgetGuard.ets 中把计算做成纯函数。它不接触系统图片对象，因此可以用脚本或单元测试检查不同输入；一旦输入不合规，应给出明确拒绝原因，而不是继续产生 NaN、Infinity 或错误的整型溢出结果。下面代码的四字节假设只用于 RGBA_8888 的示例估算。tsexport interface BudgetResult { ok: boolean; targetWidth: number; targetHeight: number; budgetMiB: number; reason: string;}export function inspectBudget(width: number, height: number, scale: number, limitMiB: number = 12): BudgetResult { const reject = (reason: string): BudgetResult => ({ ok: false, targetWidth: 0, targetHeight: 0, budgetMiB: 0, reason }); if (![width, height, scale, limitMiB].every(Number.isFinite) || !Number.isInteger(width) || !Number.isInteger(height) || !Number.isInteger(scale) || width <= 0 || height <= 0 || scale <= 0 || limitMiB <= 0) { return reject('输入尺寸、倍数或阈值不合法'); } const targetWidth = width * scale; const targetHeight = height * scale; const pixels = targetWidth * targetHeight; if (!Number.isSafeInteger(pixels) || pixels <= 0) { return reject('目标像素数超出安全整数范围'); } const bytes = pixels * 4; if (!Number.isSafeInteger(bytes)) return reject('预计字节数超出安全整数范围'); const ok = bytes <= limitMiB * 1048576; // 未四舍五入前进行门禁判断 const budgetMiB = Number((bytes / 1048576).toFixed(2)); return { ok, targetWidth, targetHeight, budgetMiB, reason: ok ? '预算通过' : '超过预算' };}````Number.isSafeInteger` 放在乘法之后，是为了避免把异常规模当作正常数值继续渲染。这里仍有一个工程上的取舍：**比较阈值不宜依赖四舍五入后的两位小数**。本例已经先用未四舍五入的 `bytes` 判断 `bytes <= limitMiB * 1048576`，之后才格式化展示两位小数。如果反过来以格式化值判断，边界附近的任务可能错误地被放行，这一点应放入测试用例。还有一点容易被忽略：图像的“宽、高”应来自当前选中图片的真实元数据，而不是直接信任相册列表里某个缩略图的标注。EXIF 旋转、裁剪、动态图片与不同像素格式会影响后续管线的安排。预算器本身保持简单，只接收已经确认过的尺寸；图片探测由另一层负责。## 三、让 Image Kit 负责拿信息，不让它背业务规则官方 Image Kit 文档提供 `PixelMap.getImageInfo()` 等图像信息能力。对于已经由业务层合法获取、且尚未释放的 `PixelMap`，可先读取尺寸，再调用纯函数。下面保留了异常出口；传入对象的创建、权限和释放仍由调用方管理，避免读图工具偷偷销毁页面仍需要展示的对象。tsimport { image } from ‘@kit.ImageKit’;import { inspectBudget, BudgetResult } from ‘./BudgetGuard’;export async function inspectPixelMap( pixelMap: image.PixelMap, scale: number = 2): Promise { try { const info: image.ImageInfo = await pixelMap.getImageInfo(); return inspectBudget(info.size.width, info.size.height, scale); } catch (err) { console.error([ClarityGate] read info failed: ${String(err)}); return { ok: false, targetWidth: 0, targetHeight: 0, budgetMiB: 0, reason: ‘图像信息读取失败’ }; }}这段代码刻意没有创建新 PixelMap，也没有启动推理。后续使用 ImageSource 解码文件时，应明确谁负责释放 ImageSource、谁持有 PixelMap、异步读取完成之前能否退出页面。不能在 `finally` 里无条件释放外部传进来的 PixelMap，否则预览组件可能还在访问它。若对象确实由本函数创建，才应由同一作用域在结束使用后释放。![](https://i-blog.csdnimg.cn/direct/176ad7db938c4ac3901566b586f9f5fa.png)开发界面演示图把尺寸和状态集中显示：`SR-204`，目标 `1600×1200`，估算 `7.32 MiB`，日志里有 `SR-203 stale ignored`。这些是用于说明业务状态机的**示例文本**，不是本次在设备上实际抓取的 HiLog。由于仅有一张开发图，编辑区优先突出预算和任务标识，完整的代码逻辑以本文为准。## 四、旧回调能返回，不等于还可以上屏尺寸预算只是第一道门。假设用户先选中 `SR-203`，又快速切换到 `SR-204`。前者可能在后者之后才完成读取或者算法计算。若回调只写 `this.status = '已完成'`，就会把旧图状态压到新图上。真正要阻止的是**旧结果提交到当前页面**，不一定能立刻取消底层已经开始的工作。因此我会在页面层维护单调递增的请求序号，同时记住当前任务 ID；每次触发新预检、退出页面或主动撤销时，都令上一批回调失效。下面用 `Promise.resolve()` 模拟一次异步边界；它不是图片推理 API，也不表示底层运算已经取消。将来接入真实任务时，只需在结果落到 UI 之前保留相同的令牌检查。tsimport { inspectBudget } from ‘…/model/BudgetGuard’;@Entry@Componentstruct PreviewPage { @State taskId: string = ‘SR-204’; @State status: string = ‘待预检’; @State budgetMiB: string = ‘–’; private requestSeq: number = 0; private activeTaskId: string = ‘SR-204’; private async startPreflight(): Promise { const seq = ++this.requestSeq; const taskId = this.taskId; const result = inspectBudget(800, 600, 2, 12); await Promise.resolve(); // 仅模拟异步边界 if (seq !== this.requestSeq || taskId !== this.activeTaskId) { console.info([DEMO] ${taskId} stale ignored); return; } this.budgetMiB = result.budgetMiB.toFixed(2); this.status = result.ok ? ‘预算通过·待接入算法’ : result.reason; console.info([DEMO] ${taskId} target=1600x1200, budget=${this.budgetMiB}MiB); } onPageHide(): void { this.requestSeq++; } build() { Column({ space: 16 }) { Text(‘ClarityGate 超分预检台’).fontSize(22) Text(任务 ${this.taskId}) Text(预算 ${this.budgetMiB} MiB / 12.00 MiB) Text(this.status) Button(‘重新预检’).onClick(() => { this.startPreflight(); }) }.width(‘100%’).padding(20) }}```令牌比较解决的是“晚到结果覆盖新状态”，不是硬件资源回收。真正的算法接口如有取消句柄，应在离开页面或替换图片时调用；若不支持取消，仍要保留旧任务资源释放路径，并限制排队数量。另一个常见误区是把 taskId 当唯一防抖依据：如果同一个图片 ID 发起两次请求，依然会发生先后覆盖。因此代码实际比较 requestSeq，显示 ID 只用于诊断。## 五、从演示页面回到接入清单手机图展示 SR-204 的输入尺寸、2× 目标、预算和门禁结果，还特意写着“这不是已完成的 AI 超分结果”。视觉对比区只是帮助读者理解“源图”和“目标展示”的位置关系，不应拿来说明算法质量提高了多少；文中也不提供不存在的耗时、准确率、帧率和内存实测指标。接入真实图像增强管线时，我会要求任务状态至少带上原始输入标识、业务倍数、输出尺寸预期、请求序号、耗时采样点和结束原因。对一次处理中的 PixelMap，必须确认其具体像素格式后再估算真实单缓冲字节量；如果同时保留原图和输出图，应按两份甚至更多中间对象考虑峰值。发生拒绝时给用户可操作的提示，例如选择更小图片、降低目标规格，而不是笼统弹出“处理失败”。调试环节可以先做四组不依赖模型的断言：800×600×2 得到 1600×1200 和约 7.32 MiB；非法 0×600 被拒绝；非常大的输入不会出现错误的正向通过；旧序号在新序号之后返回时只产生日志、不刷新状态。然后才进入设备兼容性、模型初始化、图像质量与实际内存采样。两类测试应分别记录，不能用前者替代后者。当前结论：Image Kit 提供了读取和处理像素数据的基础能力，预算与令牌隔离则是应用自己应实现的业务护栏。这套设计不依赖某个超分算法，也不保证特定设备的推理性能。它最大的作用是让尚未接入算法的页面就把输入约束、过期回调和资源所有权讲清楚，为下一步真正的模型接入保留可解释的失败路径。资料核对：华为开发者文档《使用PixelMap完成图像变换》（更新于2026-09-09）：https://developer.huawei.com/consumer/cn/doc/HarmonyOS-Guides/image-transformation；《Image Kit》能力目录：https://developer.huawei.com/consumer/cn/doc/doccenter-capabilities/image-kit。旧版 HiAI Image Super-Resolution 示例属于不同技术栈，本文未将其接口迁移为 HarmonyOS ArkTS API。