网罗开发 （小红书、快手、视频号同名）

  大家好，我是 展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
📣 公众号“Swift社区”，每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。
💬 微信端添加好友“fzhanfei”，与我直接交流，不管是项目瓶颈的求助，还是行业趋势的探讨，随时畅所欲言。
📅 最新动态：2025 年 3 月 17 日
快来加入技术社区，一起挖掘技术的无限潜能，携手迈向数字化新征程！

引言

很多开发者第一次接触鸿蒙 Stage 模型时，第一反应通常是：

“就是生命周期换了一套写法。”

比如：

• Ability 生命周期变了
• 页面生命周期变了
• 启动流程不一样了

于是很多人把 Stage 模型理解为：

旧模型（FA） → 新模型（Stage）
= 生命周期升级

但如果你深入做一个中大型项目，很快就会发现：

Stage 模型真正改变的，不是生命周期，而是系统边界。

一、为什么很多人误解了 Stage 模型

因为你最先接触到的，是这些代码：

export default class EntryAbility extends UIAbility {

  onCreate() {
    console.log("Ability 创建")
  }

  onDestroy() {
    console.log("Ability 销毁")
  }

}

或者页面：

aboutToAppear() {
  this.loadData()
}

这些都让人产生一种错觉：

Stage = 生命周期 API 的变化

但这只是“表层变化”。

二、旧模型（FA）的问题在哪里

在 FA（Feature Ability）模型中：

Ability = 应用入口 + UI 容器 + 生命周期管理

也就是说：一个 Ability 既管 UI，又管逻辑，还管生命周期。

典型问题

1 职责混乱

// Ability 里既有 UI，又有业务逻辑
startAbility(...)
setUIContent(...)
loadData(...)

UI、业务、系统混在一起

2 边界不清晰

页面属于 Ability
逻辑也属于 Ability

模块无法拆分

3 扩展性差

当你需要：

多窗口
多实例
跨设备

非常困难

三、Stage 模型做了什么

Stage 模型最大的变化是：

重新划分了“系统边界”。

核心拆分

UIAbility（应用级）
   ↓
WindowStage（窗口级）
   ↓
Page（页面级）

示例代码

export default class EntryAbility extends UIAbility {

  onWindowStageCreate(windowStage) {
    windowStage.loadContent('pages/Index')
  }

}

这段代码背后真正的变化是：

Ability 不再直接管理 UI

而是：

Ability → Window → Page

四、系统边界的重新定义

我们来看 Stage 模型重新划分的几个关键边界。

1 应用边界（UIAbility）

职责：

应用生命周期
全局资源
系统交互

不再负责：

具体 UI
页面逻辑

2 窗口边界（WindowStage）

职责：

窗口管理
多窗口能力
UI 容器

3 页面边界（Page / Component）

职责：

UI 渲染
用户交互
局部状态

关键变化：

UI 被“下沉”到了更细粒度的层级

五、为什么这是“架构级变化”

这不是简单拆层，而是：

让系统从“单体结构”变成“分层结构”

旧模型

Ability（大一统）

Stage 模型

Ability
  ↓
Window
  ↓
Page

这带来的变化是：

1 支持多窗口

windowStage.createSubWindow("sub")

一个 Ability 可以管理多个 UI 容器

2 支持多实例

startAbility({
  want: {
    abilityName: "DetailAbility"
  }
})

同一个能力可以多开

3 支持跨设备

结合分布式能力：

startAbility({
  deviceId: remoteDeviceId
})

UI 可以运行在不同设备上

六、对开发者意味着什么

这才是最重要的部分。

1 不要再把 Ability 当“页面容器”

错误理解：

Ability = 页面

正确理解：

Ability = 应用入口（类似进程 / 容器）

2 页面应该完全独立

@Component
struct DetailPage {
  @State data: any
}

页面不依赖 Ability

3 架构必须分层

推荐结构：

entry
 ├─ ability
 ├─ pages
 ├─ components
 ├─ services
 ├─ repository

4 为多窗口设计

不要默认：

只有一个 UI

而要考虑：

多个窗口同时存在

七、一个典型对比

旧写法（FA）

onStart() {
  this.setUIContent("pages/index")
  this.loadData()
}

问题：

UI + 逻辑耦合

Stage 写法

onWindowStageCreate(stage) {
  stage.loadContent("pages/index")
}

页面：

aboutToAppear() {
  this.loadData()
}

职责分离清晰

八、为什么很多人“用错了 Stage”

因为很多项目只是：

换 API
不换架构

例如：

// 依然把所有逻辑写在页面里

结果：

• 页面越来越大
• 逻辑越来越乱
• 维护成本爆炸

九、本质总结

如果用一句话总结：

Stage 模型不是在改“生命周期”，而是在重建“系统边界”。

对比：

维度	FA 模型	Stage 模型
核心	Ability	分层结构
UI 管理	Ability	WindowStage
页面	从属	独立
架构	单体	分层

结语

很多开发者刚开始用 Stage 模型时，会觉得：

“没什么区别”

但当项目变复杂时，你会慢慢意识到：

它改变的是应用的“组织方式”。

如果你只把 Stage 当成：

生命周期 API 升级

那你会很快遇到瓶颈。

但如果你把它当成：

系统边界重构

那你会发现：

• 架构更清晰
• 模块更独立
• 扩展能力更强