图片超分场景里，有一种错误不太像算法问题：用户选了一张照片，点了增强；处理还没结束，又重新挑了一张。界面上明明已经换成新图，稍后出现的“完成”状态却可能来自上一张图。这样的错位不能交给图片组件自行解决，得先给一次处理的输入确定归属。本文用 PixelQueue 做一个受控的业务演示。它展示图库选择、任务版本和过期回调隔离，不调用未经核实的超分接口，也不把示例图上的“就绪”视为真实画质提升结果。演示任务固定为 PQ-091，旧版本 PQ-091-v2，重选后的当前版本 PQ-091-v3；最终页面显示 READY，但这个状态仅表示示例流程已接受当前输入。## 一、先把三个“当前”分开产品原型常把 currentImage 当成万能变量：缩略图绑定它，任务读取它，结果也往它里面写。刚开始只有一张图片时看起来很简洁，一旦选择和处理能够交错发生，就会出现两个时间点。发起处理时的输入是 A，页面此刻显示的输入已经是 B；如果完成回调无条件更新页面，A 的结果就被错安到 B 的位置上。这里需要区分三个概念。activeUri 是用户此刻选中的媒体 URI；selectionVersion 是用户确认一次新选择后递增的业务版本；activeRun 是某一次运行所捕获的任务标识。URI 用于访问媒体，版本用于裁决谁有权更新界面，运行标识用于日志追踪。三个字段看着重复，承担的责任却不一样。我没有用文件名充当身份。用户可能重复选择同一照片，也可能选择显示名相同的不同素材。文件名不适合作为并发任务的判据；在这个演示里，每次重新选择都产生新的版本，即使 URI 恰好相同也一样。还要把一个容易误写的前提说清楚：本文模拟的是旧处理结果迟到，不宣称 PhotoViewPicker 选择的 URI 会自动在几秒后失效。用户选择后的权限性质，应以对应版本的官方文档为准；读取失败是需要处理的异常分支，不是本文用来解释旧帧问题的必要原因。## 二、图库返回时不立即启动任务选择器只负责返回用户选中的媒体位置。业务层接到新选择，第一件事不是立刻调用图像算法，而是让页面进入一个明确的 SELECTED 状态，更新版本，然后再允许用户启动示例处理。这样一来，连续点“重新选图”和点“运行示例”就不会悄悄挤进同一条执行链。下面这段代码解决图库选择与版本登记的问题。PhotoViewPicker、PhotoSelectOptions、PhotoViewMIMETypes.IMAGE_TYPE 和 select() 来自 Media Library Kit；示例只取一张图，避免把多选排序引入当前问题。代码为放入 QueuePage.ets 的关键片段，页面 build() 与完整布局另按项目需要补足。arktsimport { photoAccessHelper } from '@kit.MediaLibraryKit';@Entry@Componentstruct QueuePage { @State selectionVersion: number = 2; @State activeUri: string = ''; @State activeRun: string = ''; @State status: string = 'IDLE'; private disposed: boolean = false; private async chooseAgain(): Promise<void> { try { const options = new photoAccessHelper.PhotoSelectOptions(); options.MIMEType = photoAccessHelper.PhotoViewMIMETypes.IMAGE_TYPE; options.maxSelectNumber = 1; const picker = new photoAccessHelper.PhotoViewPicker(); const result = await picker.select(options); if (this.disposed || result.photoUris.length === 0) return; this.selectionVersion += 1; this.activeUri = result.photoUris[0]; this.activeRun = `PQ-091-v${this.selectionVersion}`; this.status = 'SELECTED'; } catch (err) { this.status = 'SELECT_FAILED'; console.error(`[PixelQueue] picker failed: ${String(err)}`); } }}值得注意的是，取消选择与调用失败不是同一回事：前者可能只产生空结果或取消路径，后者需要在 catch 里留下一条可追踪的信息。实际项目还要依据目标 SDK 的选择器行为补全取消场景的状态恢复；这里不虚构某个固定错误码。组件离开页面后也不该接受迟到的选择结果，所以添加 disposed 守卫。## 三、把结果写回资格交给版本号真正决定页面是否错位的是第二段异步操作。处理过程可能来自本地任务池、图片处理库，或者带网络等待的业务服务。它们的调用方式不同，但都能抽象成“拿着某一刻的输入开始，过一段时间返回”。在结果回来之前，新输入是否已经被选中，必须重新检查。我让 runSample() 在启动时捕获版本与 URI。即使后面的处理时间很长，这两个局部常量也不会随页面状态一起变化。完成后先比较版本，再触碰 status；否则一个过期 Promise 很容易把 READY 写回不属于它的页面。arktsprivate async runSample(): Promise<void> { if (!this.activeUri || this.disposed) return; const snapshotVersion = this.selectionVersion; const snapshotUri = this.activeUri; const runId = `PQ-091-v${snapshotVersion}`; this.activeRun = runId; this.status = 'RUNNING'; try { await this.previewAdapter(snapshotUri); if (this.disposed || snapshotVersion !== this.selectionVersion) { console.info(`[PixelQueue] stale=${runId} ignored`); return; } this.status = 'READY'; console.info(`[PixelQueue] active=${runId} status=READY`); } catch (err) { if (!this.disposed && snapshotVersion === this.selectionVersion) { this.status = 'FAILED'; } console.error(`[PixelQueue] run=${runId} failed: ${String(err)}`); }}这里的 READY 不意味着图片已经成功超分，更不意味着画质、耗时和输出尺寸满足某项指标。它只是一个演示适配器返回后、并且版本检查通过的业务状态。图片算法的实际结果必须额外验证内容、格式、内存和资源释放。把这个前提写进正文和界面，比在示意图上编一个“耗时 87ms”要有价值。对 catch 的判断同样重要。旧任务处理失败，不应该把当前已重选的输入改成红色失败状态；但失败本身仍然要出现在日志里，以免问题被彻底吞掉。页面需要的是“当前任务是否成功”，日志需要的是“每次任务发生了什么”，两者范围不能混在一起。## 四、演示适配器与生命周期的边界为了让读者把注意力放在业务时序上，我没有在示例中塞进一个名字看起来像真实图像超分的虚构 API。previewAdapter() 只是延时返回的测试替身，根本没有做像素计算。真正接入模型时，应把它替换为经过 SDK 文档确认的实现，并由调用方负责输入数据是否可读、输出对象何时释放。下面的第三段代码说明假任务与页面退出的关系。为了可读性，示例用一次延时模拟回调，没有持有真实 PixelMap。如果实际处理层可以取消，应在退出页面时调用其真实取消能力；如果不可取消，至少要让完成回调失去修改已销毁页面的资格。arktsprivate previewAdapter(uri: string): Promise<void> { return new Promise<void>((resolve, reject) => { if (!uri) { reject(new Error('EMPTY_URI')); return; } setTimeout(() => resolve(), 450); // 仅模拟异步耗时 });}aboutToDisappear(): void { this.disposed = true; this.selectionVersion += 1; // 让在途结果全部过期}上面的三段片段共同描述一个页面逻辑，复制到实际工程时应整合在同一个 QueuePage 组件内，补齐 build() 和业务按钮。不能把它们当成三个独立的完整页面编译。这里没有承诺 setTimeout() 具备释放算法资源的作用，它只是简化演示；真实图片处理中仍要关闭文件句柄，清理像素缓冲与监听器，避免退到后台后继续占用内存。这个选择还有一个细节：一旦在 aboutToDisappear() 把 disposed 置为真，页面重新进入时应创建新的组件实例，或者在明确恢复路径里重置标记。不要随意在旧组件实例上恢复异步写回资格，否则退出前的老回调有机会重新混进来。## 五、怎样观察“旧回调被丢弃”本例把输入重选后设置为版本 3，当前运行标识为 PQ-091-v3。为了说明旧任务被拦截，演示日志给出 stale=PQ-091-v2 ignored，随后出现 active=PQ-091-v3 status=READY。这两行是预期的演示日志文本，不是我在 DevEco Studio 真机环境里截取的实测输出。画面上的“夜雨街道”只是选中素材的名称；左边原图和右边预览图也只是效果占位。当前重点是下方身份核验卡：旧版本的结果没有被允许覆盖版本 3。读者若把这个页面当成图像质量基准，会误读本篇文章想解决的问题。调试可以从三个时间点切入。重选之前记录 selectionVersion 与 activeRun；处理返回后记录它携带的 snapshotVersion；真正写回 UI 前记录版本比较结果。只看“完成”一条日志无法证明这次完成属于当前输入。遇到异常先确认是访问媒体失败、业务处理失败，还是更新资格被拒绝，然后再决定是否重试。不要用“新选图后删除旧文件”作为默认处理。PhotoViewPicker 返回的 URI 对应用户媒体，业务层要处理的是自己的任务引用，不应替用户执行清理动作。即便用户选了同一张图，是否复用先前处理结果也应建立在确定的内容指纹和参数缓存策略上，而不是仅凭 URI 相同便默许旧结果覆盖。## 六、这套门禁能解决和不能解决的事它能解决的是同一页面中“新输入已生效、旧异步结果迟到”造成的状态串写，适用于图像超分预览、文搜图过滤、缩略图生成和其他带异步返回的交互。它不能证明算法正确、不能解决多进程写文件竞争，也不能代替真实取消与资源回收；复杂批量任务还需要队列级任务 ID、持久化状态与崩溃恢复。我倾向于把版本比对放在最终写 UI 的入口，而不是散落到所有数据读取函数里。这样异步处理实现即使更换，谁拥有当前页面的写入资格仍清晰可见。准备把 Demo 变成真实应用时，下一步应在实际 SDK、设备和不同生命周期场景中验证回调顺序，并用可复现日志替换本文的示意文字。资料核对： 华为开发者文档《PhotoViewPicker（Class）》 https://developer.huawei.com/consumer/cn/doc/doccenter-references/api/arkts-apis-photoaccesshelper-photoviewpicker ；《多目标识别》中的 PhotoViewPicker 选图示例 https://developer.huawei.com/consumer/cn/doc/HarmonyOS-Guides/core-vision-object-detection 。