一张照片在编辑页里变清楚了，接下来该覆盖哪里？这里有一个很容易被页面效果掩盖的问题：应用展示了增强后的新图，系统图片选择器却可能还停留在旧预览；选择器内看到了新图，又不代表相册里的原始文件已经写入成功。把这几件事混成一个“保存成功”，比一次处理失败更麻烦，因为用户可能在没有确认的情况下离开编辑流程。这次用 PreviewLedger 做一条很窄的演示链：相册选择器已选中图片 IMG-221，应用准备了增强结果 IMG-221-HD，编辑会话标识 SR-052，当前生成代次 v6。目标不是演示图像超分算法本身，而是说明结果已经产生以后，怎样合理更新 PhotoPicker 中的预览，以及哪里必须停下来等用户明确保存。## 一、先把“看到了新图”和“写回了原图”拆开Media Library Kit 的官方开发资料列出了 PickerController.replacePhotoPickerPreview()：应用在选择器允许的场景下，可以把保存在应用沙箱中的编辑结果交给 PhotoPicker，用于替换它正在展示的原图预览。资料还把“替换选择器预览”和“将替换范围内的文件保存到图库”分成两个开发步骤。这个分法非常关键，不应该因为两步都与编辑结果有关，就给它们共用一个布尔值。PreviewLedger 的界面因此单独显示三组信息：原片标识、当前预览代次、保存确认。演示数据中，SR-052 对应原片 IMG-221，新图 IMG-221-HD，代次 v6，预览状态可进入 PREVIEW_REPLACED，而保存数量仍是 0。这不是矛盾，而是对两个不同结果的正常描述。在工程里还要把“已经渲染出新图”和“已经获得正确文件 URI”区分开。一个尚未落入应用沙箱、仍由临时 PixelMap 持有的结果，不能直接拿字符串拼装成可用文件路径。替换接口所需的原图 URI 与沙箱编辑图 URI，应该由选择器和文件写入流程提供。示例里不写假造的系统 URI，也不会把素材 ID 冒充 URI。## 二、代次门禁要设在接口调用之前假设编辑器同时允许两次超分：较早的 v5 请求晚于 v6 返回。如果只看“谁最后完成”，就可能用旧图覆盖用户刚看到的新版预览。要不要显示、要不要请求替换，首先是本地会话的责任，不应该把这种竞争交给图片选择器处理。下面这一段是应用侧的纯 ArkTS 判断，解决的是“结果归属当前会话吗”。它不是 Media Library Kit 的 SDK 接口，也不判断图像内容是否可信。arktsinterface PreviewCandidate { taskId: string; originId: string; generation: number; activeGeneration: number; originUri: string; editedUri: string; userAccepted: boolean;}function canOfferPreview(x: PreviewCandidate): boolean { return x.taskId === 'SR-052' && x.originId === 'IMG-221' && x.generation === x.activeGeneration && x.originUri.length > 0 && x.editedUri.length > 0 && x.userAccepted;}````generation` 是结果创建时携带的代次，`activeGeneration` 是页面当前会话代次；二者不相等时，即便图片算法返回成功，也不能继续对外展示。`userAccepted` 表示用户确认用这份新预览参与接下来的选择操作，它不等于授权覆盖原始图库文件。正式项目里还需要校验当前选中资产是否改变、沙箱编辑图是否仍然存在，以及编辑任务是否已经退出。这里刻意保留 `originId` 和 `originUri` 两种字段。前者是业务展示和去重使用的标识，后者才是平台调用所依赖的地址。把两者拆开以后，日志可以只记录脱敏 ID 与代次，不必把实际媒体 URI 完整打出来。选择取消、用户切换图片或组件退出时，应使 `activeGeneration` 前进，令旧结果自然失去提交资格。## 三、请求预览替换，不代替真正保存官方资料中的 `PickerController` 来自 `@kit.MediaLibraryKit`，提供 `replacePhotoPickerPreview(originUrl, replaceUrl, callback)` 的用法。示例保留这条已公开的接口形式，其余的代次控制全部在业务层。回调负责记录一次接口交互已经返回；页面最终看到的新预览还需按产品流程检查，不能仅凭一条演示日志断言已持久化。arktsimport { PickerController } from ‘@kit.MediaLibraryKit’;class PreviewBridge { controller: PickerController = new PickerController(); latestGeneration: number = 6; phase: string = ‘IDLE’; requestReplace(x: PreviewCandidate): void { if (!canOfferPreview(x) || x.generation !== this.latestGeneration) { this.phase = ‘REJECTED_STALE’; return; } this.phase = ‘PREVIEW_REQUESTED’; this.controller.replacePhotoPickerPreview(x.originUri, x.editedUri, (_requestInfo, _responseInfo) => { if (x.generation !== this.latestGeneration) { this.phase = ‘IGNORED_LATE_CALLBACK’; return; } this.phase = ‘CALLBACK_RECEIVED’; }); }}这里没有猜测回调参数的具体成功字段，也没有虚构权限或异常码。实际集成必须对照目标 SDK 中该接口的类型声明补充明确的回调结果判定与异常兜底，不能把 `CALLBACK_RECEIVED` 直接升级为 `SAVED`。接口若要求当前选择器控制对象与原图选取会话对应，页面还应持有同一上下文，不要在不同组件里随意重建控制器后传入旧 URI。图中的工程树把页面、门禁和选择器适配分别放在 `PreviewLedgerPage.ets`、`PreviewGate.ets`、`PickerBridge.ets` 中。底部日志是便于解释顺序的**合成示例**：`SR-052 gen=6`、`PREVIEW_REQUESTED`、`PREVIEW_CALLBACK`、`saved=0`，不是 DevEco Studio 运行抓取结果。这样读日志时可以先问“请求有没有发起”，再问“选择器有没有更新预览”，最后才问“图库有没有真实写入”。![](https://i-blog.csdnimg.cn/direct/992e576136f34495834d12c9b3696853.png)## 四、用户界面不要给出超出证据的承诺界面可以把预览图片明确标成“增强预览”，把保存项明确标成“尚未确认”。这个措辞比“已完成”更准确。即使用户看见了更清晰的山景，也可能只是 PhotoPicker 中的一次临时展示。若此时将主按钮文案直接改成“保存成功”，后续追查丢图问题会缺少可用线索。下面用普通 ArkUI 状态展示这层业务边界。这里的 `savedCount` 只是示例账本中的确认计数，不会探测用户系统相册，更不会凭空触发媒体写入。arkts@Entry@Componentstruct PreviewLedgerPage { @State phase: string = ‘PREVIEW_REPLACED’; @State savedCount: number = 0; @State editVersion: string = ‘v6’; build() { Column({ space: 16 }) { Text(‘PreviewLedger · SR-052’).fontSize(24) Text(‘原始素材 IMG-221 / 增强预览 IMG-221-HD’) Text('编辑代次 ’ + this.editVersion) Text('预览状态 ’ + this.phase) Text('已确认保存 ’ + this.savedCount.toString()) Button(‘替换预览’).enabled(this.phase !== ‘PREVIEW_REQUESTED’) Text(‘预览替换不等于保存原图’).fontColor(Color.Orange) }.padding(20).width(‘100%’) }}```请注意，示例把最终演示状态预先设为 PREVIEW_REPLACED，只是为了说明成功展示时页面应当怎样写，并不意味着上面这段页面代码独立运行就可以完成替换。真实页面需要把选择器回调、错误提示、用户离开和“确认写入图库”的后续流程接起来。保存完成也不能只凭用户点击按钮，应以实际保存 API 返回与必要的文件核验为依据。手机配图只展示编辑结果和保存状态，不复制 IDE 内的代码。顶部 18:26、任务 SR-052、原片 IMG-221、预览 IMG-221-HD、v6、已保存 0 均为这一例的固定演示数据。## 五、验收时要设计三条互不混淆的路径第一条是成功请求预览但未保存：可以显示新图，却继续提示原始文件未被覆盖。第二条是旧代次结果晚到：v5 必须被业务门禁拒绝，不能替换 v6。第三条是用户切换了原始资产：即使当前新图 URI 仍在沙箱，原片 ID 或选择器会话已变，也不能沿用上次目标调用接口。这里每条路径都可以用模拟状态数据进行单元检查，而平台级效果还需要实际选择器和目标设备验证。资源收口同样有两个层次。应用在退出时需要停止自己仍运行的超分任务、清理不再引用的临时结果，并使代次失效；而选择器的内部生命周期交由其官方控制逻辑管理。不要臆造 PickerController.release() 之类未经确认的方法，也不要因为临时图需要删除，就越权处理图库原片。这篇文章并未执行真实超分、PhotoPicker 交互或图库写回。结论严格限定为预览替换的应用状态设计：一次预览变更可以被界面展示，但持久化写入必须有自己的动作、证据和失败回退。等真机验证时，最值得优先核对的不是视觉差异，而是“未保存离开再进入是否仍指向原片”和“失败时有没有错误地留下已保存标记”。补充一条很实际的验收标准：如果用户在选择器里先选了 IMG-221，进入编辑页生成增强图，之后又退回选择器改选了别的照片，页面应该立即废弃旧的 SR-052 绑定。不能因为内存里还有 IMG-221-HD 就默认为用户要编辑的仍是上一张。保存动作尤其要单独弹出明确的目标说明，让用户知道是“保存副本”还是“替换原片”，不能通过图像更清晰这一事实替用户做决定。日志也要注意脱敏。正式版本可以留下任务 ID、代次、业务阶段和错误类别，但不应把原片真实路径、沙箱临时文件名及用户照片内容直接写入可上传日志。这样的信息分层既便于定位回调错序，也能避免“为了证明保存成功”反而暴露用户素材。### 参考资料与验证边界- 华为官方：使用 PickerController 将编辑后的图片替换原图（2026-03-09）：https://developer.huawei.com/consumer/cn/doc/HarmonyOS-Guides/medialibrary-pickercontroller- 华为官方：HarmonyOS 文档中心及 Media Library Kit：https://developer.huawei.com/consumer/cn/doc/- 本文所有图片均为示意生成，接口的具体回调结构需以本地目标 SDK 类型声明再次核对；不代表真机编译或上架审核结论。