页面一切换就“失忆”？聊聊鸿蒙里的生命周期管理与状态保持【华为根技术】

页面一切换就“失忆”？聊聊鸿蒙里的生命周期管理与状态保持

一、引子：是不是你也被这些问题折磨过？

我先问你几个问题，看看是不是“似曾相识”。

• 页面刚填了一半表单，切到后台回个微信，再回来——内容没了

• 列表滚到第 50 条，点进详情页，再返回——直接回到顶部

• 应用被系统回收重启后，用户一脸懵：

  “我刚刚不是点到这里了吗？”

如果你在做 HarmonyOS 应用，这些问题你一定遇到过。

很多同学第一反应是：

“鸿蒙是不是不稳定？”
“是不是系统 Bug？”

说句公道话：
👉 大多数时候，不是系统问题，是我们没把“生命周期 + 状态”这件事想清楚。

二、原理讲解：生命周期不是“回调顺序”，而是“生存策略”

我们先别急着写代码，先把一个认知纠偏讲清楚。

在鸿蒙里（尤其是 ArkUI），生命周期不是为了告诉你“发生了什么”，而是为了提醒你：

“现在这个组件，还值不值得你继续为它保存状态？”

1️⃣ 页面为什么会被销毁？

在 HarmonyOS 中，页面（Ability / Page）随时可能：

• 被切到后台
• 被系统回收
• 被重新创建

原因很简单：
👉 系统优先保证整体体验，而不是你这个页面的“情绪稳定”。

所以记住一句话：

页面销毁不是异常，是常态。

2️⃣ 生命周期的核心阶段（说人话版）

以 ArkUI 页面为例，核心你只要记住这几类：

• onAppear：我上场了
• onDisappear：我暂时下场了
• onPageShow / onPageHide：我被看到 / 看不到了
• 页面重建：我“投胎”了

关键不是回调名字，
而是你要想清楚：

什么状态，能跟我一起“投胎”？

三、实战代码：三种状态，三种正确姿势

下面这部分是重点，我会用 ArkTS 给你掰开揉碎。

第一种：临时 UI 状态（用 @State）

@Entry
@Component
struct CounterPage {
  @State count: number = 0

  build() {
    Column() {
      Text(`当前计数：${this.count}`)
      Button('加 1')
        .onClick(() => {
          this.count++
        })
    }
  }
}

适合什么？

• 页面内展示状态
• 不要求跨页面
• 页面销毁就丢，也没关系

👉 这是“页面级记忆”，不抗重启。

第二种：页面级持久状态（用 @StorageProp / PersistentStorage）

PersistentStorage.persistProp('username', 'guest')

@Entry
@Component
struct ProfilePage {
  @StorageProp('username') username: string = 'guest'

  build() {
    Column() {
      Text(`你好，${this.username}`)
      Button('修改用户名')
        .onClick(() => {
          this.username = 'Echo_Wish'
        })
    }
  }
}

这个就不一样了：

• 页面销毁没关系
• 应用重启还能找回来
• 系统帮你兜底

👉 这是“跨生命周期记忆”。

第三种：全局状态（AppStorage / 状态中心）

AppStorage.setOrCreate('loginState', false)

@Component
struct LoginStatus {
  @AppStorage('loginState') isLogin: boolean = false

  build() {
    Text(this.isLogin ? '已登录' : '未登录')
  }
}

适合：

• 登录态
• 用户身份
• 全局配置

👉 这是“应用级人格”。

四、场景应用：什么时候该“记住”，什么时候该“放手”？

这一步非常关键，也是很多项目混乱的根源。

场景一：列表页返回保持位置

正确思路不是“记 UI”，而是：

• 记滚动位置
• 页面重建时恢复

@State scrollOffset: number = 0

页面消失时保存，
页面出现时恢复。

👉 记“状态”，不是记“界面”。

场景二：表单填写中断

• 用户明确在“输入”
• 中断概率极高

✅ 推荐方案：

• 输入内容 → PersistentStorage
• 提交成功后清空

👉 这是对用户时间的尊重。

场景三：临时动画、加载态

这类状态我通常的建议是：

该丢就丢。

加载中、动画中，
恢复成本比重新开始还高。

五、Echo_Wish 式思考：生命周期，其实是“产品观”

写到这里，说点我个人的感受。

我一直觉得：

生命周期管理，本质上不是技术问题，而是“你把用户当不当回事”。

1️⃣ 状态不是越多越好

很多新同学有个误区：

“既然会丢，那我全存起来不就行了？”

结果就是：

• 状态混乱
• 恢复逻辑复杂
• Bug 成倍增长

👉 记住：状态是负债。

2️⃣ 好的状态设计，是“可预期的”

用户真正想要的是：

• 我离开，再回来
• 世界还是熟悉的

而不是：

• 一切都原封不动
• 但我根本不知道发生了什么

3️⃣ 鸿蒙的状态体系，其实很“高级”

说句实在话，HarmonyOS 在状态管理这块：

• 响应式
• 系统级持久化
• 语义清晰

前提只有一个：
👉 你得按它的“哲学”来，而不是硬套别的平台经验。

六、最后总结一句

如果你只记一句话，我希望是这句：

生命周期不是“何时调用”，
而是“哪些东西，值得被记住”。

页面可以重建，
状态必须有边界，
而用户的时间，永远是最贵的资源。