鸿蒙 App 的 Task + State 双核心架构

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

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

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

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

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

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

引言

很多人第一次做鸿蒙 App 架构时，核心思路其实都很简单：

页面展示数据 按钮触发逻辑 状态驱动 UI

刚开始这种结构没有问题。但随着项目越来越复杂，很快就会进入一种熟悉的状态：

状态越来越多 任务越来越乱 页面越来越重

尤其 AI 接入之后，你会发现：

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

例如：

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

AI 可能：

• 更新日历
• 创建待办
• 写入笔记
• 同步消息
• 修改提醒状态

这时候，一个问题会突然爆发：

到底谁在管理任务？

到底谁在管理状态？

很多项目后期失控，本质原因就是：

Task 和 State 没有分离

最后整个系统会变成：

任务到处跑 状态到处改

于是越来越多中大型鸿蒙项目，最终都会走向一种新结构：

Task + State 双核心架构。

一、为什么传统页面架构越来越撑不住

传统 App 的核心模型：

页面 ↓ 按钮 ↓ 功能 ↓ 状态更新

问题在于：

页面承担了太多职责

例如：

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

最后页面会越来越像：

巨型控制器

一个典型页面

@Stateloading:boolean=false@Stateorders:Order[]=[]asyncload(){this.loading=truethis.orders=awaitapi.getOrders()this.loading=false}

刚开始没问题，但后面：

• AI 也会改 orders
• 分布式同步也会改 orders
• 其他页面也会改 orders

最后：

状态来源彻底失控

二、Task + State 架构真正解决的是什么

一句话总结：

Task 负责“过程”，State 负责“结果”。

Task 管什么

Task 管：

• 流程
• 调度
• 执行
• 生命周期
• 多步骤协同

State 管什么

State 管：

• 数据
• 当前状态
• UI 响应
• 状态同步
• 数据一致性

一个非常关键的认知

很多项目的问题：

Task 偷偷保存状态 State 偷偷处理流程

最后：

职责完全混乱

三、Task 为什么会成为未来鸿蒙 App 的核心

因为未来 App 的核心已经不是：

页面

而是：

用户目标

例如：

创建订单 整理会议 发送报告 同步设备

这些本质上都是：

任务

AI 更是天然 Task 化

AI 不理解：

页面

AI 理解的是：

目标

例如：

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

AI 真正执行的是：

任务流

而不是：

页面跳转

四、State 为什么会成为另一半核心

因为鸿蒙本质是：

状态驱动系统

ArkUI 的核心：

@State

本质就是：

状态变化 驱动 UI

但未来，状态来源已经不只是：

用户点击

还包括：

• AI
• 分布式同步
• 多设备协同
• 后台任务
• Task 调度

于是：

State 会越来越重要

五、Task + State 的真正关系

这是整个架构最核心的一点：

Task 不持有状态。

Task 只修改 State。

错误写法

classOrderTask{currentOrder:Order}

问题：

状态藏在 Task 内部

后面一定会出现：

• 状态覆盖
• 分布式异常
• 生命周期错乱

正确写法

classOrderTask{asyncrun(){constorder=awaitapi.create()orderStore.set(order)}}

Task：

只负责流程

State：

只负责数据

六、Task + State 双核心模型

推荐一个非常稳定的结构：

Intent ↓ Task ↓ State ↓ UI

每层职责

1、Intent

用户目标，例如：

创建订单 取消支付 同步会议

2、Task

任务执行，例如：

• 调用多个 Service
• 编排流程
• 调度 AI
• 分发任务

3、State

状态存储，例如：

orderStore.orders

4、 UI

状态展示，例如：

Text(orderStore.current.title)

七、为什么这种结构特别适合 AI

因为 AI 最大的问题：

不可预测。

例如：

awaitagent.run("整理今天任务")

AI 可能：

• 创建日程
• 修改订单
• 删除待办
• 更新消息

如果 AI 可以直接操作 UI：

整个系统一定失控

正确方式

AI：

只能操作 Task

Task：

只能修改 Store

UI：

只能监听状态

这就是边界

AI → Task → State → UI

八、为什么这种结构特别适合分布式

因为鸿蒙本质不是：

页面系统

而是：

状态同步系统

多设备协同真正同步的是什么

不是页面，而是：

任务上下文 + 状态

示例

手机：

taskCenter.run("继续会议")

PC：

meetingStore.currentMeeting

自动恢复。

分布式同步

awaitkvStore.put("meeting_state",meetingStore.current)

这里同步的不是：

页面

而是：

State

九、为什么未来鸿蒙 App 一定会走向“双核心”

因为未来系统会越来越：

弱页面化

用户越来越习惯：

直接表达目标

例如：

“帮我继续昨天会议” “帮我总结待办” “帮我创建订单”

这些本质都是：

Task

但最终真正驱动 UI 的：

仍然是 State

所以未来鸿蒙 App 会越来越明显地变成：

Task + State 双核心系统。

十、一个推荐的代码结构

app/ ├── task/ ├── store/ ├── system/ ├── repository/ ├── ai/ └── ui/

task/

负责：

流程 编排 调度

store/

负责：

状态 缓存 同步

system/

负责：

无状态能力

repository/

负责：

数据访问

ai/

负责：

AI 调度 意图解析

ui/

负责：

界面展示

十一、真正优秀的鸿蒙 AI App 都在做什么

不是：

疯狂堆页面

而是：

建立稳定的 Task + State 架构

因为未来真正重要的已经不是：

• 页面数量
• 导航层级
• Tab 结构

而是：

• Task 流
• 状态流
• AI 调度
• 分布式同步

十二、总结

如果用一句话总结：

Task + State，本质是“过程”和“结果”的彻底分离。

Task：

负责系统怎么运行

State：

负责系统当前是什么状态

只有当两者彻底解耦：

整个鸿蒙 App 才会真正稳定

很多人以为：

未来 App 的核心还是页面

但真正的变化其实是：

页面正在退居外围。

未来系统真正的核心会变成：

Task + State

你会越来越明显地发现：

Task 决定系统行为 State 决定系统呈现

最终很多鸿蒙 AI App 会逐渐演变成：

一个由 Task 驱动、由 State 渲染的智能系统。