从单页面到系统化：鸿蒙 App 演进路径

大家好，我是子玥酱，一名长期深耕在一线的前端程序媛 👩‍💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

技术方向：前端 / 跨端 / 小程序 / 移动端工程化
内容平台：掘金、知乎、CSDN、简书
创作特点：实战导向、源码拆解、少空谈多落地
文章状态：长期稳定更新，大量原创输出

我的内容主要围绕前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读展开。文章不会停留在“API 怎么用”，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。

子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”

持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱

引言

很多鸿蒙项目刚开始时，都会有一种“开发特别顺”的感觉：

页面很好写 ArkUI 很流畅 状态驱动很舒服

于是很多项目初期都会这样：

先把页面做出来

然后：

• 写接口
• 接状态
• 加功能
• 拼业务

前几个月通常都很顺，但只要项目继续往下做，很快就会进入一种熟悉的状态：

页面越来越大 状态越来越乱 模块越来越耦合

最后：

整个项目像一团线

很多团队最后才意识到：

真正难的，从来不是“写页面”。

而是：

如何让 App 长期保持“系统化”。

这也是为什么：

鸿蒙 App 的真正挑战

从来都不是：

UI

而是：

系统结构

一、很多鸿蒙 App 都会经历同一条演进路径

几乎所有项目都会经历：

单页面 ↓ 多页面 ↓ 模块化 ↓ 状态化 ↓ Task 化 ↓ 系统化

问题是，很多团队会卡死在：

“页面堆积阶段”

二、第一阶段：单页面时代

这是所有项目的起点，通常：

一个首页 几个按钮 几个接口

例如：

@Statelist:any[]=[]

然后：

aboutToAppear(){this.load()}

非常简单，这个阶段最大的特点：

开发效率极高

但问题也会慢慢出现

因为：

页面开始承担所有职责

例如：

• UI
• 状态
• 业务逻辑
• 网络请求
• 生命周期
• 流程控制

最后：

页面越来越胖

三、第二阶段：多页面时代

随着业务增长：

页面开始增加

例如：

• 首页
• 订单页
• 消息页
• 个人中心

这时候很多团队会开始：

复制页面逻辑

例如：

loadData()fetchList()updateUser()

到处都是。

很快会进入一个问题

多个页面开始共享数据

例如：

用户信息 订单状态 消息数量

于是：

状态同步问题开始出现

四、第三阶段：Store 化

这是很多鸿蒙项目第一次真正“架构升级”，团队会开始意识到：

状态不能继续放页面里。

于是：

Store 出现了

例如：

classUserStore{user:User}

页面：

userStore.user

这是非常关键的一步

因为：

状态终于开始“中心化”

项目也会稳定很多。

但新的问题又来了

很多团队会继续：

疯狂往 Store 塞逻辑

最后：

Store 变成“超级类”

例如：

classOrderStore{asynccreate()asyncpay()asyncrefund()asyncsync()asyncupload()}

Store 越来越重。

五、第四阶段：System 化

很多项目做到中期之后，会发现：

业务流程越来越复杂

例如，创建订单：

检查库存 ↓ 创建订单 ↓ 创建支付单 ↓ 同步设备

这时候：

页面已经扛不住了

于是：

System 层开始出现

示例

classOrderSystem{asynccreateOrder(){}}

这是一个非常重要的阶段

因为：

业务流程终于开始独立

但这里也是最危险的阶段

很多项目会开始：

System 持有状态

例如：

classOrderSystem{currentOrder:Order}

最后：

• 状态冲突
• 并发混乱
• 分布式同步失败

开始全面爆发。

六、第五阶段：Task 化

这是 AI 时代非常关键的一步，传统 App：

页面是核心

未来：

Task 才是核心

为什么

因为 AI 本质上：

是任务驱动系统

例如：

awaitagent.run("帮我整理今天会议")

背后可能：

• 更新日历
• 创建待办
• 发送消息
• 同步设备

这些已经不是：

单页面行为

而是：

完整任务流

所以未来结构会变成

Intent ↓ Task ↓ State ↓ UI

这里：

页面开始外围化

七、第六阶段：系统化

这是很多团队真正成熟的阶段，到了这里项目已经不再是：

“页面集合”

而是：

“运行中的系统”

一个真正系统化的鸿蒙 App

通常具备：

• Store 中心化
• Task Runtime
• 状态分层
• 无状态 System
• 分布式状态同步
• AI Runtime
• 多设备协同

这些东西共同组成：

系统秩序

八、为什么很多项目始终无法“系统化”

因为很多团队始终停留在：

页面思维

例如：

加功能 = 加页面

但真正成熟的系统：

加功能 = 加能力

这是本质区别。

九、鸿蒙为什么特别强调“系统化”

因为鸿蒙天然具备：

• 分布式
• 多设备
• AI 调度
• Task 流转
• 跨端协同

这些能力意味着：

系统复杂度会指数级增长

如果没有：

清晰结构

后面一定：

越来越失控

十、为什么 AI 会逼着鸿蒙 App 进化

传统 App：

用户一次操作 只改一个状态

AI App：

一次任务 可能改几十个状态

例如：

awaitagent.run("整理今天所有会议")

AI 可能：

• 修改日历
• 更新待办
• 发送消息
• 调整提醒

如果系统仍然是：

页面驱动

一定会：

彻底混乱

十一、真正成熟的鸿蒙 App 长什么样

不是：

页面多漂亮

而是：

结构极其稳定

通常具备：

• State Flow
• Task Flow
• Runtime
• Intent System
• Store 中心化
• 无状态 System

这些东西：

决定项目后期还能不能继续演进。

十二、一个非常关键的认知

很多人以为：

架构升级 = 技术升级

其实真正的升级是：

从“页面思维”走向“系统思维”。

过去：

功能 = 页面

未来：

功能 = 能力 + 状态 + Task

十三、推荐一个未来结构

app/ ├── ui/ ├── state/ ├── task/ ├── runtime/ ├── distributed/ ├── domain/ └── infrastructure/

每层职责清晰

ui/ 负责：

展示

state/ 负责：

状态

task/ 负责：

流程

runtime/ 负责：

AI 调度

distributed/ 负责：

跨设备协同

十四、总结

如果用一句话总结：

鸿蒙 App 的演进，本质上是“从页面走向系统”。

过去：

页面驱动

未来：

Task + State + Runtime 驱动

页面不会消失

但会：

外围化

真正核心会变成：

• Intent
• Task
• Runtime
• State Flow

很多鸿蒙项目后期越来越难维护，并不是因为：

• ArkUI 不够强
• AI 太复杂
• 分布式太难

真正的问题其实只有一个：

项目始终停留在“页面阶段”。

记住一句话：

真正成熟的鸿蒙 App， 不是“很多页面”， 而是“一个稳定运行的系统”。

当你真正完成：

• Store 中心化
• Task 化
• Runtime 化
• 无状态 System
• Intent System
• 分布式状态同步

你会明显感觉到：

整个鸿蒙 App 开始真正“系统化”了