HarmonyOS应用实战-启示散页-44-设置页别直接改全局状态用 SettingsService 管主题、隐私和诊断开关设置项刚开始通常只有一个深色模式开关直接在页面里写 Preferences 看起来很快。等到隐私开关、诊断导出、动画偏好陆续加入后问题就会变成同一个 key 被多个组件写入失败时 UI 不知道回滚其他页面也不知道该刷新哪一块。这篇文章解决四件事还原这个问题在答案之书这类离线应用里如何出现。明确页面、Service、Repository、AppStorage 或发布清单各自的责任。给出可迁移的 ArkTS/工程代码片段并说明反例为什么会留下隐患。用验证清单和排障表把方案收成可执行检查项。从一个开关失控看设置页为什么要收口真实项目里最容易出错的不是开关本身而是开关背后的副作用。主题切换要刷新颜色隐私开关要影响导出范围诊断开关要影响日志口径。若每个组件都直接 set 一个 Preferences key短期能跑长期会让排障只剩下全局搜索。已核对的现状是当前 AppPreferences 集中管理 schemaVersion、currentDeckId、firstLaunchDone 与种子版本项目里还没有 SettingsService。本文给出的是未来加入设置页时的工程边界不把示例代码当成已上线能力。把设置拆成三层意图、策略、结果先写 owner 表再写代码。否则代码能跑起来却很难说明失败时该由谁回滚、重启后该由谁恢复、其他页面该根据什么信号刷新。Owner负责什么不负责什么SettingsPage收集用户点击、展示保存中与失败态直接写 Preferences 或拼接全局状态SettingsService按 key 执行校验、持久化、刷新信号和失败回滚持有 ArkUI 组件状态SettingsRepository提供稳定读写和默认值决定页面文案和交互AppStorage只广播轻量时间戳保存完整设置对象SettingChange 只表达一次变更不暴露存储结构模型要表达本链路需要的稳定事实不要把页面临时状态或底层存储细节暴露出去。这样后续迁移 Preferences schema、拆模块或增加发布检查时调用方不必跟着重写。typeSettingKeythemeMode|privacyExport|diagnosticsEnabled;interfaceSettingChangeT{key:SettingKey;nextValue:T;source:settingsPage|privacyDialog|debugPanel;}interfaceSettingApplyResultT{key:SettingKey;saved:boolean;currentValue:T;message:string;}这段模型的重点有三点字段命名贴近业务输入输出能覆盖失败分支没有携带 ArkUI 组件状态。页面拿它展示Service 拿它做判断Repository 不需要知道页面长什么样。SettingsService 按 key 选择保存策略Service 是规则 owner。凡是涉及校验、回滚、冲突、恢复、隐私或发布证据的逻辑都不要散落在组件回调里。classSettingsService{asyncapplyTheme(change:SettingChangelight|dark|system):PromiseSettingApplyResultstring{constpreviousawaitSettingsRepository.loadThemeMode();try{awaitSettingsRepository.saveThemeMode(change.nextValue);AppStorage.setOrCreate(settings.theme.changedAt,Date.now());return{key:change.key,saved:true,currentValue:change.nextValue,message:主题设置已保存};}catch(error){return{key:change.key,saved:false,currentValue:previous,message:保存失败已恢复原设置};}}asyncsetDiagnosticsEnabled(enabled:boolean):PromiseSettingApplyResultboolean{awaitSettingsRepository.saveDiagnosticsEnabled(enabled);AppStorage.setOrCreate(settings.diagnostics.changedAt,Date.now());return{key:diagnosticsEnabled,saved:true,currentValue:enabled,message:诊断开关已更新};}}这里的 Service 不追求复杂抽象只做一件事把输入转成可解释结果。页面可以做乐观交互但最终事实必须从 Service 返回。Repository 统一默认值和 schema 迁移Repository 负责稳定读写、默认值和 schema 兼容。它不弹 Toast不决定按钮状态也不拼页面文案。classSettingsRepository{staticasyncloadThemeMode():Promiselight|dark|system{constvalueawaitPreferencesStore.getString(app_settings,theme_mode);returnvaluelight||valuedark||valuesystem?value:system;}staticasyncsaveThemeMode(mode:light|dark|system):Promisevoid{awaitPreferencesStore.setString(app_settings,theme_mode,mode);awaitPreferencesStore.setNumber(app_settings,settings_schema_version,1);}staticasyncsaveDiagnosticsEnabled(enabled:boolean):Promisevoid{awaitPreferencesStore.setBoolean(app_settings,diagnostics_enabled,enabled);}}如果这一层缺失页面会被迫知道 store name、key、默认值和异常处理细节。写到后面所有页面都会变成半个仓储层。页面只做乐观展示不拥有最终事实页面只消费结果、展示状态、触发动作。跨页面刷新用轻量信号完整业务对象继续由 Service 重新读取。Componentstruct SettingsPage{StateprivatethemeMode:light|dark|systemsystem;StateprivatesavingTheme:booleanfalse;privateasynconThemeSelected(nextMode:light|dark|system):Promisevoid{constpreviousthis.themeMode;this.themeModenextMode;this.savingThemetrue;constresultawaitnewSettingsService().applyTheme({key:themeMode,nextValue:nextMode,source:settingsPage});this.savingThemefalse;if(!result.saved){this.themeModeprevious;}}}这类写法的好处是入口可以扩展页面可以重进数据可以迁移。只要 Service 和 Repository 边界稳定页面不需要关心底层怎么保存。反例短期省事长期失控反例是把PreferencesStore.setString(theme_mode, nextMode)直接写在按钮 onClick 里。这样页面知道了底层 key也绕过了失败回滚、刷新信号和诊断记录。后续再加隐私开关时代码会继续复制这条捷径。更具体地说反例通常有三个共同点直接写持久化、没有失败结果、没有刷新 owner。它们在单次手测里很难暴露但在重启、返回、跨入口或发布复查时会变成真实问题。排查顺序\n1. 先找唯一写入 owner。\n2. 再看失败是否返回可展示结果。\n3. 再看刷新信号是否只通知相关页面。\n4. 最后才检查 UI 展示。验证路径不要只走正常操作主题切换成功后关闭页面再进入确认读到的是持久化值。模拟 Preferences 写入失败确认页面回滚到 previous 值。打开依赖主题的首页和结果页确认只订阅 theme.changedAt不读取完整设置对象。诊断开关打开后导出报告确认不包含题库、问题和答案全文。验证时建议把“正常路径、异常输入、重启恢复、跨入口刷新、发布态检查”分开记录。构建通过只能证明语法和资源能打包不能证明这些运行链路都已经被真机验证。rg-nPreferencesStore|AppStorage.setOrCreate|Repository|ServiceD:\\ProgramData\\huawei\\lesson\\The_Book_of_Answers\nrg-nquestion|answerText|deckName|hilogD:\\ProgramData\\huawei\\lesson\\The_Book_of_Answers常见问题与处理现象先看哪里处理切换一个开关导致全页重建是否只广播 settings.changedAt按 key 拆分刷新信号保存失败但 UI 已变Service 是否返回 previous/current失败时恢复旧值不同页面默认值不一致默认值是否散在组件里Repository 统一提供默认值处理这些问题时不要先改 UI 文案。先确认写入 owner、读取 owner 和刷新信号是否一致再看页面是否正确消费结果。若只在页面补一个 Toast用户当次可能看到了提示但重启、返回、跨入口和发布复查仍然会暴露同一个根因。落地取舍这套方案不是为了把轻量应用写重而是为了把真正会跨页面、跨启动、跨发布阶段的事实收住。只影响当前展示节奏的变量可以留在页面会改变用户内容、持久结构、隐私口径或发布证据的逻辑必须进入 Service、Repository 或发布清单。判断点建议位置原因只影响当前按钮、弹层或动画页面State不需要跨入口复用会写本地数据或读持久事实Service Repository需要校验、回滚和恢复会影响其他页面刷新AppStorage 时间戳通知变化不共享完整对象会影响发布、截图、隐私或诊断发布清单或运行账本后续复查需要证据真正落地时可以先从一条最容易复现的路径开始找出唯一写入点补上结果模型再把页面里的直接读写替换成 Service 调用。这个顺序比一次性重构全部页面更稳也更容易在评审时说明每一行代码解决了哪个故障链。评审记录里最好保留对应的命令、截图或复现步骤避免方案只停留在口头约定。小结设置页的关键不是多写一个服务类而是把“用户意图”和“持久事实”分开。页面负责表达选择SettingsService 负责校验与回滚Repository 负责稳定读写AppStorage 只负责通知。这个边界守住后后续加隐私、诊断、动画偏好都不会把全局状态写散。。评审记录里最好保留对应的命令、截图或复现步骤避免方案只停留在口头约定。小结设置页的关键不是多写一个服务类而是把“用户意图”和“持久事实”分开。页面负责表达选择SettingsService 负责校验与回滚Repository 负责稳定读写AppStorage 只负责通知。这个边界守住后后续加隐私、诊断、动画偏好都不会把全局状态写散。