

子玥酱 (掘金 / 知乎 / CSDN / 简书 同名)
大家好,我是 子玥酱,一名长期深耕在一线的前端程序媛 👩💻。曾就职于多家知名互联网大厂,目前在某国企负责前端软件研发相关工作,主要聚焦于业务型系统的工程化建设与长期维护。
我持续输出和沉淀前端领域的实战经验,日常关注并分享的技术方向包括 前端工程化、小程序、React / RN、Flutter、跨端方案,
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。
技术方向: 前端 / 跨端 / 小程序 / 移动端工程化 内容平台: 掘金、知乎、CSDN、简书 创作特点: 实战导向、源码拆解、少空谈多落地 **文章状态:**长期稳定更新,大量原创输出
我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在"API 怎么用",而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍,希望能帮你在实际工作中少走弯路。
子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端,或准备长期走前端这条路
📚 关注我,第一时间获取前端行业趋势与实践总结
🎁 可领取 11 类前端进阶学习资源 (工程化 / 框架 / 跨端 / 面试 / 架构)
💡 一起把技术学"明白",也用"到位"
持续写作,持续进阶。
愿我们都能在代码和生活里,走得更稳一点 🌱
文章目录
-
- 引言
- [ArkUI 的生命周期设计思路](#ArkUI 的生命周期设计思路)
- 页面生命周期
-
- [1 aboutToAppear](#1 aboutToAppear)
- [2 aboutToDisappear](#2 aboutToDisappear)
- [3 onPageShow](#3 onPageShow)
- [4 onPageHide](#4 onPageHide)
- 一个完整示例
- 组件生命周期
- [一个常见误区:在 build 中写逻辑](#一个常见误区:在 build 中写逻辑)
- [生命周期 + 状态更新](#生命周期 + 状态更新)
- [为什么 ArkUI 生命周期更少](#为什么 ArkUI 生命周期更少)
- 总结
引言
很多开发者在从 Android / iOS / Flutter 转到 ArkUI(ArkTS) 时,都会问一个问题:
ArkUI 的生命周期在哪里?
因为在传统开发中,生命周期是非常明确的。例如 Android Activity:
onCreate
onStart
onResume
onPause
onStop
onDestroy
或者 Flutter Widget:
initState
didUpdateWidget
dispose
这些生命周期决定了:
什么时候初始化数据
什么时候刷新 UI
什么时候释放资源
但当你开始写 ArkUI 时,会发现一个明显变化:
生命周期看起来少了很多。
这并不是 ArkUI 没有生命周期,而是:
生命周期被重新设计了。
理解这一点,对写好 ArkUI 应用非常重要。
ArkUI 的生命周期设计思路
ArkUI 采用的是 声明式 UI + 状态驱动更新。因此它的核心理念是:
状态变化 → UI 更新
而不是传统模式:
生命周期 → 手动更新 UI
这意味着很多传统生命周期的职责被简化了。例如:
UI刷新
状态同步
组件更新
都由框架自动完成,所以 ArkUI 的生命周期通常分为两个层级:
页面生命周期
组件生命周期
页面生命周期
在 ArkUI 中,页面通常使用:
@Entry
@Component
定义,例如:
ts
@Entry
@Component
struct HomePage {
build() {
Text("Home")
}
}
页面主要有几个核心生命周期。
1 aboutToAppear
这是最常用的生命周期,触发时机:
页面即将显示时。
通常用于:
初始化数据
发起网络请求
加载资源
示例:
ts
@Entry
@Component
struct HomePage {
aboutToAppear() {
console.log("页面即将出现")
this.loadData()
}
loadData() {
// 请求接口
}
build() {
Column() {
Text("Home Page")
}
}
}
这是 ArkUI 中最接近传统:
onCreate / initState
的生命周期。
2 aboutToDisappear
触发时机:
页面即将消失时。
常见用途:
停止定时器
取消请求
保存数据
示例:
ts
aboutToDisappear() {
console.log("页面即将离开")
this.stopTimer()
}
例如:
ts
private timer: number = 0
aboutToAppear() {
this.timer = setInterval(() => {
console.log("running")
}, 1000)
}
aboutToDisappear() {
clearInterval(this.timer)
}
这类似传统:
onDestroy / dispose
3 onPageShow
触发时机:
页面进入前台时。
例如:
应用从后台回到前台
页面重新显示
示例:
ts
onPageShow() {
console.log("页面显示")
}
常见用途:
刷新数据
恢复状态
重新检查权限
4 onPageHide
触发时机:
页面进入后台时。
例如:
用户切换应用
页面被覆盖
示例:
ts
onPageHide() {
console.log("页面进入后台")
}
常见用途:
暂停动画
暂停播放
保存临时状态
一个完整示例
一个完整的页面生命周期示例:
ts
@Entry
@Component
struct HomePage {
aboutToAppear() {
console.log("aboutToAppear")
}
onPageShow() {
console.log("onPageShow")
}
onPageHide() {
console.log("onPageHide")
}
aboutToDisappear() {
console.log("aboutToDisappear")
}
build() {
Column() {
Text("Lifecycle Demo")
}
}
}
大致执行顺序通常是:
aboutToAppear
↓
onPageShow
↓
(页面运行)
↓
onPageHide
↓
aboutToDisappear
组件生命周期
除了页面,组件也有生命周期。例如:
ts
@Component
struct UserCard {
aboutToAppear() {
console.log("组件出现")
}
aboutToDisappear() {
console.log("组件销毁")
}
build() {
Text("User Card")
}
}
当组件被创建或移除时,这些生命周期会触发。这在动态 UI 中非常有用。例如:
ts
@State showCard: boolean = true
ts
if (this.showCard) {
UserCard()
}
当 showCard 变为 false 时:
aboutToDisappear
就会触发。
一个常见误区:在 build 中写逻辑
很多新手会写出这样的代码:
ts
build() {
this.loadData()
Column() {
Text("Hello")
}
}
这是一个非常危险的写法,因为:
build 可能被调用很多次。
例如:
状态变化
UI刷新
组件更新
都会触发 build,正确做法是:
初始化逻辑 → aboutToAppear
UI 渲染 → build
生命周期 + 状态更新
ArkUI 的一个重要特点是:
生命周期只负责初始化,状态负责更新。
例如:
ts
@State list: string[] = []
初始化:
ts
aboutToAppear() {
this.fetchData()
}
请求数据:
ts
fetchData() {
this.list = ["A", "B", "C"]
}
UI:
ts
ForEach(this.list, (item) => {
Text(item)
})
当 list 更新时:
UI自动刷新
不需要额外生命周期。
为什么 ArkUI 生命周期更少
很多开发者刚开始会觉得:
生命周期太少了。
但其实这是设计理念不同,传统 UI:
生命周期驱动 UI
ArkUI:
状态驱动 UI
生命周期只负责:
初始化
清理资源
而 UI 更新全部交给:
状态系统
这就是声明式 UI 的核心思想。
总结
ArkUI 的生命周期比传统框架更简洁,但依然非常重要。
核心生命周期包括:
aboutToAppear 页面即将出现
onPageShow 页面进入前台
onPageHide 页面进入后台
aboutToDisappear 页面即将销毁
组件也有:
aboutToAppear
aboutToDisappear
理解 ArkUI 生命周期的关键在于:
生命周期 → 初始化 / 清理
状态 → UI更新
当你掌握这种模式之后,就会发现:
ArkUI 的生命周期虽然少,但足够用。
真正需要花时间理解的,其实不是生命周期本身,而是:
状态驱动 UI 的工作方式。