HarmonyOS 7 应用快启后设置还是旧的？快启点前读盘为什么会被跳过

一位同事在手机上改了阅读页字体，退出应用再打开，页面却又显示修改前的字体。清掉应用进程后重启，字体恢复正常。这个现象很容易被误判成“数据库没写进去”；实际排查时，还要看启动是不是复用了之前的初始化结果。

这里讨论的是 应用快启，不是把启动页动画缩短。华为文档说明，这项机制从 API 24 开始提供；在 HarmonyOS 7 上适配时，快启点之前的一部分初始化可能被复用，不会像普通冷启动那样重新执行。当前仅支持手机；线上启用还有企业开发者权限申请和系统侧决策约束，不能写成“配置完每次启动必然快启”。

先找出哪一步被跳过

假设 AbilityStage.onCreate() 读了一次本地设置，之后的页面一直使用这个内存值。普通冷启动时，onCreate() 读到刚保存的字体；快启初始化曾经读过旧字体，用户之后修改了设置，再次启动复用旧结果时，那次读盘不会自动重来。

排查时先在日志里分别记录：读盘发生时间、读到的值、onAboutToCreateAbility() 是否调用、onLaunchFromHyperSnap() 是否调用、页面最终显示的值。只看“启动快了多少毫秒”，很难发现数据已经过期。

启动路径	快启点前 onCreate() 的读盘	快启点外的刷新
普通冷启动	会按普通流程执行	onAboutToCreateAbility() 仍会调用
复用快启结果	可能直接复用先前结果	onAboutToCreateAbility() 仍会调用；onLaunchFromHyperSnap() 只在快启流程调用

这里的“可能”很重要。是否执行快启由系统结合条件决定，不能仅凭一次普通启动结果断言接入失败。

案例一：字体已经保存，重新打开却还是旧字体

先做一个有意保留问题的最小场景：启动时从本地存储读取 fontFamily，写入内存供页面使用；退出应用前修改并持久化字体。若把读盘放在快启点前，内存快照可能保留上次的值。

// 示意代码：SettingsRepository 是项目自己的存储封装，不是系统 API。
class AppAbilityStage extends AbilityStage {
  private fontFamily: string = 'system';

  onCreate(): void {
    this.fontFamily = SettingsRepository.readFontFamily();
  }
}

更直接的改法是把这次依赖实时存储的读取移到快启点外。华为给出的 onAboutToCreateAbility() 无论普通启动还是快启都会调用。

class AppAbilityStage extends AbilityStage {
  private fontFamily: string = 'system';

  onCreate(): void {
    // 只保留可复用、无外部实时状态依赖的初始化。
  }

  onAboutToCreateAbility(): void {
    this.fontFamily = SettingsRepository.readFontFamily();
    StartupLog.record('font-loaded', this.fontFamily);
  }
}

SettingsRepository 和 StartupLog 是示意的业务封装，替换成项目现有实现后才能编译；不要把它们当成 HarmonyOS SDK 接口。这段代码的重点是读盘时机，不是存储 API 的选型。若真实读盘很慢，把所有工作一股脑挪过去也可能让首屏变慢；应先测量读取耗时，再决定缓存、拆分或延后展示。

怎样复现和验收

1. 在符合快启条件的手机上，用 debug 签名版本接入快启并打开生命周期日志；线上启用另需满足官方权限与审核要求。
2. 字体初始设为 A，等待系统完成快启初始化；之后在应用中改成 B，确认 B 已持久化，再退出。
3. 反复做普通冷启动与快启启动的对照，记录是否走了快启路径。不要把每一次重新打开都当成快启。
4. 修复前观察“存储为 B、页面为 A”的不一致；修复后要求两条启动路径的页面都显示 B。再重启设备、更新应用各测一次，因为这两种操作可能清理快启初始化结果。

案例二：主题模式变化了，页面仍停在旧模式

另一个坑是把系统颜色模式监听注册在快启点前，并假设监听在应用尚未启动的阶段也会持续收事件。官方文档明确提醒：快启初始化阶段建立的监听不会在快启前持续响应，期间发生的变化可能丢失。

处理方法不是只补一行监听注册，而是同时做两件事：在快启点外注册后续变化监听，并当场读取当前模式。这样即使错过了之前的变化，也能用当前状态纠正页面。退出或不再需要时注销监听，避免重复注册。

// 示意接口由业务适配层提供，非 HarmonyOS 原生 API 签名。
class ThemeBootstrap {
  private stopListening?: () => void;

  activate(source: ThemeSource, apply: (mode: string) => void): void {
    this.stopListening?.();
    apply(source.readCurrentMode());
    this.stopListening = source.onModeChange(apply);
  }

  dispose(): void {
    this.stopListening?.();
    this.stopListening = undefined;
  }
}

把 activate() 放到快启点外、且页面依赖主题值之前的生命周期位置。验收时至少覆盖两个时间点：应用正常运行中切换深浅色，和快启初始化完成后、用户真正打开应用前切换深浅色。第二种更容易暴露“只靠监听、不读当前值”的问题。

我把这段封装抽成不依赖设备的模型在本地跑了四项检查：启动前错过的变化能通过当前值补回、运行中的变化能送达、重复激活不会叠加监听、销毁会注销监听。四项均通过；它们只证明这段状态处理逻辑，不证明系统快启回调已经在真机上触发。

两种修法怎么选

优先方案：后移风险操作。 设置读取、监听注册能安全移到 onAboutToCreateAbility() 一侧时，两条启动路径共用一套刷新逻辑，状态更容易对齐。

兜底方案：快启回调补同步。 业务暂时无法拆开 onCreate() 时，可在 onLaunchFromHyperSnap() 重新读取外部数据。但它只在快启流程调用，普通冷启动仍要有自己的初始化路径；必须分别测两条路径，也要防止同一值被覆盖两次。不要把回调当成“快启初始化时就会执行”的钩子。

我把排查顺序固定为：确认快启路径 → 找快启点前的外部状态读取/监听 → 比对存储值与内存值 → 移动或补同步 → 两条启动路径分别回归。这样能避免为了提速而把“启动快但数据错”的问题带上线。

验证边界

本文中的两段生命周期代码用于说明官方回调的放置位置，业务封装名称是示意。当前环境没有可用的快启真机与线上企业权限，没有完成快启设备复现或量产性能对比；上面的复现清单是需要在目标手机上执行的验收步骤，而非已经得到的实测结论。不能把“应用快启支持接入”写成“接入后一定生效”，也不能把本地逻辑模型的正确性当成系统快启已验证。

参考：华为《应用快启》开发指导，更新于 2026-09-09。