HarmonyOS应用实战-启示散页-98-隐私弹窗别挡住恢复路径：先保证可退出和可重开

HarmonyOS 应用实战 98隐私弹窗别挡住恢复路径先保证可退出和可重开隐私弹窗最容易被写成“首次启动弹一次”。这样做上线前看起来没问题但遇到备份恢复、版本升级、用户拒绝后再次进入就会暴露两个风险没有明确同意记录或者弹窗挡住了退出和恢复路径。“答案之书”当前工程里应用级偏好有firstLaunchDone但没有独立的隐私同意状态。第 98 篇要说清楚这个边界首次启动完成不等于用户同意隐私协议隐私状态应该有版本、同意时间、拒绝出口和再次打开入口。当前偏好键只覆盖启动状态libraryHAR/src/main/ets/models/AppPreferences.ets当前定义如下exportinterfaceAppPreferences{schemaVersion:number;currentDeckId:string;firstLaunchDone:boolean;}exportclassAppPrefKey{staticreadonlySchemaVersion:stringschemaVersion;staticreadonlyCurrentDeckId:stringcurrentDeckId;staticreadonlyFirstLaunchDone:stringfirstLaunchDone;staticreadonlyLastSeededVersion:stringlastSeededVersion;}这里的firstLaunchDone只能说明“首次启动流程是否完成”。它不能说明用户看过哪一版隐私文本不能说明用户何时同意也不能支持撤回或重新查看。启动链路也没有隐私拦截点EntryAbility当前启动时会初始化 Preferences 并运行SeedLoader然后加载首页try{awaitPreferencesStore.init(ctx);awaitSeedLoader.run(ctx);}catch(err){hilog.error(DOMAIN,testTag,bootstrap failed: %{public}s,(errasError).message);}windowStage.loadContent(pages/Index,(err){if(err.code){hilog.error(DOMAIN,testTag,Failed to load the content. Cause: %{public}s,JSON.stringify(err));return;}hilog.info(DOMAIN,testTag,Succeeded in loading the content.);});这段代码说明当前应用更关注“数据能否就绪”。如果要加隐私弹窗不能简单塞在首页最上层遮住所有内容而要设计清楚未同意时能退出已同意后能进入业务恢复或升级后能重新判断协议版本。为什么不能用 firstLaunchDone 代替同意记录两者的含义不同字段代表什么不能代表什么firstLaunchDone首次引导或启动初始化完成用户同意隐私协议schemaVersion本地数据结构版本隐私文本版本LastSeededVersion默认题库播种版本用户授权状态currentDeckId当前选择题库是否允许进入业务页如果把隐私同意混在firstLaunchDone里用户恢复备份后可能直接进入业务页协议更新后也无法判断是否需要重新展示。这不是 UI 问题而是状态语义不清。建议新增独立 ConsentRecord下面是建议补强模型不表示当前工程已经存在exportinterfacePrivacyConsentRecord{accepted:boolean;policyVersion:string;acceptedAt:number;source:first_open|settings|restore;}exportclassPrivacyPrefKey{staticreadonlyConsentRecord:stringprivacyConsentRecord;}policyVersion要和隐私文本版本绑定。只存一个 boolean 不够因为协议内容更新后程序需要知道旧同意是否还能继续使用。source也不是装饰字段它能帮助排查“用户是在首次打开同意还是恢复后重新确认”。用服务封住读写规则隐私状态不建议散落在页面里直接读写 Preferences。可以用一个服务集中处理classPrivacyConsentServiceImpl{asyncload():PromisePrivacyConsentRecord|null{returnawaitPreferencesStore.getJsonPrivacyConsentRecord|null(PrefStoreName.App,PrivacyPrefKey.ConsentRecord,null);}asyncisAccepted(policyVersion:string):Promiseboolean{constrecord:PrivacyConsentRecord|nullawaitthis.load();return!!recordrecord.acceptedrecord.policyVersionpolicyVersion;}asyncaccept(policyVersion:string,source:PrivacyConsentRecord[source]):Promisevoid{constrecord:PrivacyConsentRecord{accepted:true,policyVersion,acceptedAt:Date.now(),source};awaitPreferencesStore.setJson(PrefStoreName.App,PrivacyPrefKey.ConsentRecord,record);}}页面不应该自己拼 key也不应该自己判断版本兼容。页面只负责展示协议、同意、拒绝、重新打开服务负责状态含义和写入位置。弹窗要有拒绝出口隐私弹窗不应只提供“同意”。用户拒绝时至少要能退出当前业务入口不能被遮罩卡死BuilderfunctionPrivacyGate(){Column({space:16}){Text(隐私说明).fontSize(20).fontWeight(FontWeight.Medium)Text(请阅读并确认本地题库、收藏和提问历史的使用方式。).fontSize(14)Row({space:12}){Button(不同意).onClick(()this.exitApp())Button(同意并进入).onClick(()this.acceptAndEnter())}}}exitApp()在真实工程里可以调用 Ability 上下文结束当前页面或退回安全入口。关键是保留明确出口而不是让用户只能点同意才能继续操作。恢复后要重新判断而不是沿用旧界面状态备份恢复会改变 Preferences隐私状态也可能被带回来。恢复链路完成后应该重新读取同意记录asyncfunctionafterRestore(policyVersion:string):Promisevoid{constok:booleanawaitPrivacyConsentService.isAccepted(policyVersion);if(!ok){AppStorage.setOrCreate(privacyGateVisible,true);return;}AppStorage.setOrCreate(privacyGateVisible,false);}这段逻辑的重点是“恢复后重新判断”。不要因为当前页面已经在业务态就默认恢复后的偏好仍然可信。尤其是跨版本恢复时协议版本必须重新对齐。和当前启动流程怎么配合更稳的接入顺序是EntryAbility初始化PreferencesStore。SeedLoader保证默认题库和currentDeckId可用。首页或统一入口读取PrivacyConsentService.isAccepted()。未同意时展示可退出的隐私入口。同意后写入policyVersion acceptedAt再开放业务操作。这样做不会阻断启动自愈也不会把同意状态和默认题库播种混在一起。数据可以先就绪业务入口再根据隐私状态决定是否可用。验证路径静态确认rg-nFirstLaunchDone|PrivacyConsent|ConsentRecord|policyVersion|acceptedAtD:\ProgramData\huawei\lesson\The_Book_of_Answers\libraryHAR\src\main\etsD:\ProgramData\huawei\lesson\The_Book_of_Answers\entry\src\main\ets交互回归场景期望结果首次安装打开展示隐私入口拒绝可退出同意后重启不重复弹同一版本协议协议版本升级重新展示并记录新版本恢复旧备份重新判断policyVersion用户从设置重看能打开协议不改变同意时间除非重新同意本文没有实际改 HarmonyOS 工程代码也没有执行真机隐私流程这些是落地方案时必须补跑的验证项。常见问题隐私流程出问题时通常不是弹窗样式不够明显而是状态语义没有分清。排查时先确认当前读取的是启动标记、协议版本还是用户同意记录再看拒绝和恢复路径是否能走通。现象常见原因修复方向用户拒绝后退不出去弹窗没有拒绝分支提供退出或返回安全入口协议更新后不再弹只存 boolean加policyVersion恢复后直接进业务恢复链路没有重读同意状态恢复完成后重新判断同意记录说不清来源只存 true/false保存acceptedAt和source收口隐私弹窗不是首次启动装饰。当前工程里的firstLaunchDone只能表示启动流程不能替代隐私同意。要让隐私流程可维护就把同意状态独立成PrivacyConsentRecord保留版本、时间、来源、拒绝出口和恢复后的重新判断。这条边界一旦立住后续扩展会简单很多协议文本更新时只比较policyVersion备份恢复后只重新读取同意记录用户拒绝时只退回安全入口。业务页不用理解隐私状态的存储细节也不会因为一个启动标记被误用而绕过用户选择。