鸿蒙 App 架构：为什么页面越来越薄？

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

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

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

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

引言

很多人刚开始做鸿蒙 App 时，都会下意识这样设计：

页面 = 功能

于是：

• 页面写逻辑
• 页面调接口
• 页面管状态
• 页面处理流程

项目初期：

开发非常快

但随着项目越来越大，很快就会进入一种熟悉状态：

页面越来越厚 一个页面几千行

最后：

不敢改 一改就连锁爆炸

很多团队做到后面才慢慢意识到：

真正稳定的鸿蒙架构，页面一定会越来越“薄”。

因为未来鸿蒙 App 的核心，已经不再是：

Page

而是：

Task State Runtime

页面开始从：

“业务中心”

变成：

“状态展示层”

这是未来 AI Native 鸿蒙 App 一个非常重要的变化。

一、为什么传统 App 页面会越来越重

因为传统移动开发一直是：

页面驱动

典型结构：

Page ↓ 业务逻辑 ↓ 接口 ↓ 数据

于是很多页面最后会变成：

loadUser()loadOrder()submit()pay()cancel()

页面既负责：

• UI
• 数据
• 流程
• 网络
• 状态

最后页面会变成：

一个“巨型控制器”。

二、鸿蒙为什么更容易出现“大页面”

因为 ArkUI：

状态驱动非常方便

很多人很容易：

@Stateorders:Order[]@Stateuser:User@Stateloading:boolean

接着：

aboutToAppear(){this.loadAll()}

最后：

所有逻辑都堆进页面

尤其：

• 分布式
• AI
• 多设备
• Task 流程

一旦加入：

页面复杂度会指数级增长

三、真正的问题：页面承担了“不属于它的责任”

很多项目的核心问题：

页面知道得太多。

例如，页面知道：

• 接口怎么调
• 数据怎么存
• AI 怎么运行
• 状态怎么同步
• Task 怎么调度

结果：

页面和整个系统高度耦合

最后：

任何模块改动 页面都会受影响

四、为什么未来页面一定越来越薄

因为未来 App 的核心正在变化，过去：

页面组织功能

未来：

Task 组织能力

例如，过去：

打开订单页 点击按钮 创建订单

未来：

awaitagent.run("帮我下单")

这里：

页面甚至可能不存在

真正执行的是：

Task Runtime

所以页面会越来越像：

“结果展示器”

五、页面真正应该负责什么

未来稳定的鸿蒙页面，只应该负责：

1、UI 展示

例如：

Text(userStore.name)

2、用户交互

例如：

Button("提交")

3、局部 UI 状态

例如：

@StateshowDialog:boolean

页面不应该负责

网络错误：

http.request()

AI 调度错误：

agent.run()

全局状态错误：

globalStore.user=xxx

分布式同步错误：

kvStore.put()

六、真正的变化：Store 开始成为中心

过去：

Page 是核心

未来：

Store 是核心

推荐结构：

UI ↓ Store ↓ Task ↓ System ↓ Repository

为什么

因为：

页面会变化

但：

业务状态不会变化

例如：

手机页面

单栏布局

平板页面

双栏布局

TV 页面

焦点卡片

但：

订单状态

本质是同一个，所以：

真正稳定的是 State，不是 Page。

七、AI 为什么会逼着页面“变薄”

因为 AI 会让：

页面逻辑彻底失控

传统 App：

用户一次点击 一个动作

AI App：

一次任务 几十个动作

例如：

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

AI 可能：

• 创建待办
• 更新日历
• 发送消息
• 创建提醒
• 写入笔记

如果这些逻辑都在页面：

页面一定爆炸

所以未来一定会变成：

AI Runtime ↓ Task Runtime ↓ Store ↓ UI

页面只负责：

渲染结果

八、Task 架构会进一步削弱“页面中心化”

传统：

页面 = 功能入口

Task 架构：

Intent = 功能入口

例如：

帮我继续昨天没看完的视频

系统自动：

• 找视频
• 找播放记录
• 切换设备
• 恢复进度

这里：

用户甚至没进入页面

所以未来：

页面的重要性会持续下降

九、真正优秀的鸿蒙项目，都有一个特点

不是：

页面特别复杂

而是：

页面极其简单

很多成熟项目页面最后只有：

• UI
• Store Binding
• Event

例如：

Button("支付").onClick(()=>{orderStore.pay()})

页面根本不知道：

• 怎么支付
• 怎么调接口
• 怎么同步状态

这些都在：

Task / Store / Runtime

内部完成。

十、为什么“页面越来越薄”是必然趋势

因为未来 App 会越来越：

系统化

而不是：

页面化

过去：

页面驱动功能

未来：

任务驱动系统

过去：

用户操作 UI

未来：

用户表达目标

所以：

UI 会逐渐外围化

十一、未来鸿蒙 App 的真正核心

未来真正核心会变成：

State Flow

负责：

状态流转

Task Runtime

负责：

任务执行

AI Runtime

负责：

智能调度

Distributed Runtime

负责：

多设备协同

页面只负责：

把结果显示出来

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

很多人会觉得：

页面代码少了 是不是架构退化了

其实恰恰相反，真正成熟的系统一定是：

页面越来越简单，系统越来越强。

因为：

复杂度被“下沉”了

下沉到：

• Store
• Runtime
• Task
• AI
• Domain

这些真正稳定的地方。

十三、总结

如果用一句话总结：

页面越来越薄，本质上是 App 开始“系统化”。

过去：

Page First

未来：

Runtime First

过去：

页面组织能力

未来：

Task 组织能力

过去：

UI 驱动功能

未来：

State 驱动系统

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

• ArkUI 太复杂
• 分布式太难
• AI 太重

真正的问题是：

页面承担了太多“不属于页面”的责任。

记住一句话：

真正优秀的鸿蒙架构， 一定是： 页面越来越薄， 系统越来越厚。

当你真正完成：

• Store 中心化
• Task 化
• Runtime 化
• 状态分层
• AI 解耦
• 页面去业务化

你会明显感觉到：

整个鸿蒙 App 开始“像操作系统” 而不是“页面集合”