👋 你好，欢迎来到我的博客！我是【菜鸟学鸿蒙】
   我是一名在路上的移动端开发者，正从传统“小码农”转向鸿蒙原生开发的进阶之旅。为了把学习过的知识沉淀下来，也为了和更多同路人互相启发，我决定把探索 HarmonyOS 的过程都记录在这里。
  
  🛠️ 主要方向：ArkTS 语言基础、HarmonyOS 原生应用（Stage 模型、UIAbility/ServiceAbility）、分布式能力与软总线、元服务/卡片、应用签名与上架、性能与内存优化、项目实战，以及 Android → 鸿蒙的迁移踩坑与复盘。
  🧭 内容节奏：从基础到实战——小示例拆解框架认知、专项优化手记、实战项目拆包、面试题思考与复盘，让每篇都有可落地的代码与方法论。
  💡 我相信：写作是把知识内化的过程，分享是让生态更繁荣的方式。
  
   如果你也想拥抱鸿蒙、热爱成长，欢迎关注我，一起交流进步！🚀

前言：生命周期不是“记住名字”，是“知道该把活儿放哪儿”😤

很多人学生命周期，学法特别像背英语单词：
“aboutToAppear… aboutToDisappear… onPageShow… onPageHide…”
背完一合书：该把网络请求放哪？订阅在哪取消？首帧为啥慢？——照样一脸懵。

我这篇不带你背口诀，我带你搞清楚一件事：

生命周期 = 系统给你的“时机窗口”。你把重活放错窗口，性能就会用脚投票。

1) 页面生命周期：页面不是“建一次”，而是“上台下台反复演”🎬

这里按 ArkUI 页面常见回调来讲（你写 @Entry 页面时最常碰到那套）。

1.1 最常用的一组：aboutToAppear / aboutToDisappear

• aboutToAppear：页面（或组件树）即将显示前触发
  适合做：轻量初始化、读本地缓存、准备首屏数据（注意“轻量”两个字）
• aboutToDisappear：页面即将离开时触发
  适合做：释放资源、取消订阅、停定时器、落盘必要状态

你可以把它俩当成“进场/退场”的总闸门。

1.2 更偏“可见性”的：onPageShow / onPageHide

• onPageShow：页面真正对用户可见（适合开始上报、动画、轮询）
• onPageHide：页面不可见（适合暂停动画、停止轮询、降频）

这俩的意义在于：
你别一上来就“只要页面创建就开轮询”，结果用户切走了你还在后台狂刷接口——电量和流量都得跟你急😅

1.3 一张“人话版”时序图（别笑，真挺好用）

进入页面：
aboutToAppear  ->  build/渲染  ->  onPageShow

离开页面：
onPageHide  ->  aboutToDisappear

具体触发细节会因路由、组件结构略有差异，但“进场/可见/隐藏/退场”这条主线很稳定。

2) 组件生命周期：别把子组件当“静态标签”，它也会反复挂载/卸载🧩

组件生命周期最容易踩坑的一点是：
你以为某个子组件“就在那里”，结果由于条件渲染（if/ForEach）或状态变化，它可能会被销毁重建。

2.1 条件渲染导致的“反复出生”

比如你写了个弹窗组件：

@Component
struct ConfirmDialog {
  aboutToAppear() {
    console.info('Dialog aboutToAppear: 我出生了😄')
  }
  aboutToDisappear() {
    console.info('Dialog aboutToDisappear: 我下线了👋')
  }

  build() {
    Column() {
      Text('确定要继续吗？')
    }.padding(16)
  }
}

@Entry
@Component
struct PageWithDialog {
  @State show: boolean = false

  build() {
    Column({ space: 12 }) {
      Button(this.show ? '隐藏弹窗' : '显示弹窗')
        .onClick(() => this.show = !this.show)

      if (this.show) {
        ConfirmDialog()
      }
    }.padding(20)
  }
}

你一旦用 if (show) 控制渲染，组件就是“真销毁/真重建”。
所以：订阅、定时器、资源句柄这类东西，如果在子组件里开了，就得在 aboutToDisappear 里关掉，不然分分钟变成“幽灵后台任务”👻

3) 生命周期与性能关系：性能问题，80% 都是“活儿放错地方”😮‍💨

我把 ArkUI 性能的“锅”按常见程度排个名（血泪榜单）：

3.1 第一名：把重活写进 build()（求你了别这么干🙏）

build() 是用来“描述 UI 的”，不是用来“干活”的。
因为声明式 UI 会在状态变化时重新计算视图树，你在 build 里做 IO/计算/请求，就等于：

每次刷新 UI，都顺手给自己加一刀。

错误示范：

build() {
  const data = this.readBigFileSync() // ❌ 同步重活
  // ...
}

正确思路：生命周期里做副作用，build 里只画 UI：

@Entry
@Component
struct GoodPage {
  @State text: string = '加载中...'

  async aboutToAppear() {
    // ✅ 在生命周期做异步准备
    this.text = await this.loadData()
  }

  private async loadData(): Promise<string> {
    // 模拟耗时
    await new Promise<void>(r => setTimeout(() => r(), 300))
    return '数据就绪✅'
  }

  build() {
    Column() { Text(this.text).fontSize(20) }.padding(20)
  }
}

3.2 第二名：订阅/定时器开了不关（泄漏 + 后台耗电 + 逻辑串台）

经典“我以为离开页面就结束了”误区：

@Entry
@Component
struct LeakyPage {
  private timerId: number = -1

  onPageShow() {
    this.timerId = setInterval(() => {
      console.info('我还在跑…你关页面也没用😈')
    }, 1000) as unknown as number
  }

  // ❌ 缺少 onPageHide/aboutToDisappear 清理
  build() { Text('看看日志你就懂了').padding(20) }
}

正确写法：把“启动/停止”绑在 show/hide 上：

@Entry
@Component
struct CleanPage {
  private timerId: number = -1

  onPageShow() {
    if (this.timerId !== -1) return
    this.timerId = setInterval(() => {
      console.info('只在可见时工作✅')
    }, 1000) as unknown as number
  }

  onPageHide() {
    if (this.timerId !== -1) {
      clearInterval(this.timerId as unknown as number)
      this.timerId = -1
    }
  }

  build() { Text('我很自律🙂').padding(20) }
}

3.3 第三名：首屏生命周期里同步做“大而全初始化”（直接拖慢首帧）

首屏要讲究策略：

• 先把 UI 画出来（骨架/占位/首屏最小数据）
• 重活（解密、全量 DB、复杂计算、非关键 SDK）往后放
• 需要并发的工作就并发（别全串行排队）

你要记住一个很现实的真相：用户不在乎你后台准备得多完美，用户只在乎“我点开有没有反应”。😅

4) 常见误用问题：这些坑我都见过，甚至有些是我亲手挖的😂

4.1 误用 1：把 aboutToAppear 当成“只会执行一次”

**错。**如果页面被销毁重建，它就会再来一次。
所以：初始化要区分

• “只需一次的全局初始化”（放更上层，比如应用级）
• “页面每次进入要做的初始化”（放页面生命周期）

4.2 误用 2：ForEach 里 key 不稳定，导致组件生命周期乱套

你用 index 当 key，列表一变动就可能触发“错位复用/频繁重建”，生命周期回调像抽风。
**建议：**用稳定唯一 ID 当 key（比如业务 id）。

4.3 误用 3：子组件里乱用双向状态，导致反复刷新

能单向就单向（父管状态、子发事件），别让“谁都能改状态”。
一旦状态流乱了，生命周期里的副作用也会跟着乱（例如重复请求、重复订阅）。

4.4 误用 4：在 onPageShow 里做“必需初始化”

onPageShow 更适合做“可见性相关”的事，比如：

• 动画开始/结束
• 轮询开始/结束
• 埋点/曝光上报
  真正的“必需准备”（比如首屏数据）一般更适合提前到 aboutToAppear，否则用户可能先看到空壳再等你加载——体验会很拧巴😮‍💨

结尾：生命周期管理写得好，性能像开挂；写得烂，Bug 像开会🤣

我最后用一句很“糙但准”的话收尾：

ArkUI 生命周期不是让你“在每个回调里都写点东西”，而是让你把该发生的事，放在最合适的时机发生。

📝 写在最后

如果你觉得这篇文章对你有帮助，或者有任何想法、建议，欢迎在评论区留言交流！你的每一个点赞 👍、收藏 ⭐、关注 ❤️，都是我持续更新的最大动力！

我是一个在代码世界里不断摸索的小码农，愿我们都能在成长的路上越走越远，越学越强！

感谢你的阅读，我们下篇文章再见～👋

✍️ 作者：某个被流“治愈”过的 移动端 老兵
📅 日期：2025-11-05
🧵 本文原创，转载请注明出处。