ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

从分享面板跳进应用后进程被重建:HarmonyOS 7 ShareExtension 冷启动如何避免重复导入

从分享面板跳进应用后进程被重建:HarmonyOS 7 ShareExtension 冷启动如何避免重复导入 从分享面板跳进应用后进程被重建HarmonyOS 7 ShareExtension 冷启动如何避免重复导入先看问题是怎么发生的用户从系统分享面板进入目标应用图片刚解析一半进程因为资源回收被重建。页面恢复后又读一次 SharedData最终同一张图导入两份。仅靠页面内 isImported 标志无效因为页面和进程重建后它都会丢失。验证边界本文依据文末华为开发者官方资料整理并用可执行 TypeScript 状态模型验证应用侧分支。当前本机为 API 24 且未连接 HarmonyOS 7 真机文中的 API 26 代码属于接入骨架不声称已完成 API 26 编译、真机性能测试或设备兼容认证。上线前仍需在目标 SDK 和真实设备上补齐接口、异常码、权限与性能证据。根因和工程边界接收分享要把“读取系统输入”和“提交业务数据”分成两阶段。第一阶段生成稳定 requestId 与项目账本允许恢复第二阶段以 requestId 作为幂等键写业务库。页面只展示账本状态不直接决定是否已提交。这样即使扩展被重建也能继续未完成项而不是重放全部动作。案例一三张图片导入时进程重建恢复后读取本地账本已校验的两张不重复解码只继续第三张。用户确认时以 requestId 提交一次数据库唯一键阻止重复批次。案例二用户返回面板再次选择同一内容新的系统动作生成新会话但文件指纹命中已导入记录。页面明确提示“已存在”允许跳过或保留副本而不是静默写入。可以独立运行的状态模型class CommitLog{private donenew Setstring();commit(id:string,write:()void){if(this.done.has(id))return false;write();this.done.add(id);return true}} const lognew CommitLog();let writes0;log.commit(r-7,()writes);log.commit(r-7,()writes); if(writes!1)throw new Error(分享批次重复提交);这个小模型只验证应用侧判断不替代 HarmonyOS 7 真机和目标 SDK。接入平台接口时应把调用放在模型确定的边界内并把真实错误码、日志和用户可见结果补进验收记录。为什么选择这条方案幂等键应落在业务提交边界而不是只放在按钮防抖里。按钮防抖挡不住进程重建、网络重试和同一回调重复到达。账本只保留恢复所需的最小元数据并在成功或过期后清理避免把临时资源长期当成正式数据。上线前验证清单验证项通过标准进程重建已完成项不重复有可重复步骤、日志或可见结果提交回调重复只写一次有可重复步骤、日志或可见结果账本损坏进入可解释失败页有可重复步骤、日志或可见结果会话过期临时文件被清理有可重复步骤、日志或可见结果相同文件新会话用户决定跳过或保留有可重复步骤、日志或可见结果官方资料与证据边界1. 系统分享详情页处理共享内容2. ShareExtensionAbility API 参考可复用结论先把输入、所有者、生命周期和失败回退写成状态再接入平台能力。这样出现异常时可以回答“哪一步失败、谁负责释放、用户还能做什么”而不是靠重复调用掩盖问题。
返回列表