ArkTS页面瘦身：用Store+Task架构让鸿蒙App告别巨型控制器

鸿蒙专家

很多开发者初入鸿蒙应用开发时，习惯将页面与功能直接绑定：页面里写接口、管状态、处理流程、调度AI任务。初期开发效率很高，但项目膨胀后，一个页面动辄几千行，修改一处就可能引发连锁崩溃。这种“页面越来越厚”的困境在ArkUI下尤为常见——@State装饰器让状态驱动变得极方便，开发者容易把所有逻辑都堆进aboutToAppear里。

真正的解法是让页面变“薄”，把业务复杂度下沉到更稳定的层次。未来鸿蒙App的核心不再是Page，而是Task、State和Runtime。页面应退化为纯粹的“状态展示层”和“用户交互层”，只负责UI渲染、局部UI状态（如@State showDialog: boolean）以及用户动作（如Button点击）。那些网络请求、AI调度、全局状态同步、分布式数据操作，都不该出现在页面中。

一、为什么页面容易变重
传统移动开发遵循“页面驱动”模式：Page承载业务逻辑、接口调用、数据处理，最后变成巨型控制器。在ArkUI中，开发者很容易写出这样的代码：

2. @State orders: Order[]
3. @State user: User
4. @State loading: boolean
6. aboutToAppear() {
7.     this.loadAll()
8. }
10. loadAll() {
11.     http.request('...').then(res => {
12.         this.orders = res.data.orders
13.         this.user = res.data.user
14.     })
15. }
17. Button('提交').onClick(() => {
18.     this.submitOrder()
19. })

复制代码

当加入分布式协同、AI Agent、多设备Task流程后，页面复杂度指数级增长，最终变得难以维护。

二、页面不该知道的事
页面的核心问题是“知道得太多”：它知道接口怎么调、数据怎么存、AI怎么运行、分布式状态怎么同步。结果任何模块改动都会波及页面。实际上，页面只需关注两件事：展示数据和接收用户意图。网络错误、AI调度、全局Store更新、分布式kvStore.put()等，都应该由下层模块处理。

三、Store成为核心，页面只绑定Store
未来稳定的鸿蒙架构应类似：

2. UI → Store → Task → System → Repository

复制代码

页面从UI层通过Store获取数据，Store管理业务状态，Task执行具体任务（如支付、同步），System层处理系统能力（如分布式、AI），Repository封装数据源。这样做的好处是：页面会变（手机单栏、平板双栏、TV焦点卡片），但订单状态等业务状态不变——真正稳定的是State，不是Page。

推荐的做法：

2. // 页面中
3. Text(orderStore.getOrderCount())
4. Button('支付').onClick(() => {
5.     orderStore.pay()
6. })
8. // Store层
9. class OrderStore {
10.     @State orders: Order[] = []
11.    
12.     async pay() {
13.         await taskRunner.run('pay', this.selectedOrder)
14.     }
15. }

复制代码

页面根本不知道支付怎么调接口、怎么走分布式、怎么同步状态——这些都在Task和Runtime中完成。

四、AI与Task架构进一步削薄页面
AI Native鸿蒙App中，一次用户意图可能触发几十个动作（创建待办、更新日历、发送消息、写入笔记）。如果这些逻辑塞在页面，页面必然爆炸。正确结构是：

2. AI Runtime → Task Runtime → Store → UI

复制代码

页面只负责渲染最终结果，例如用户说“帮我整理今天会议”，页面等待Store更新后展示最新日程。甚至在一些场景下，用户可能都没进入页面，系统通过Task直接完成操作。

五、实战中如何落地“薄页面”
1. 使用全局Store管理业务状态，页面通过@Consume或自定义Store类绑定数据。
2. 将网络请求封装到Repository层，Store中调用Repository，页面绝不直接使用http.request。
3. 将AI Agent、分布式同步等复杂操作封装为Task，通过Task Runtime调度，Store只负责状态变更。
4. 页面生命周期中只做UI相关的初始化，例如从Store获取初始数据，不做业务逻辑。
5. 对于AI驱动的动作，使用Intent触发Task，页面无需关心Task内部流程。

六、总结
优秀的鸿蒙项目不是页面复杂，而是页面极其简单。真正的复杂度被下沉到Store、Runtime、Task和Domain层。当页面只做“状态展示器”和“事件转发器”时，整个App会像操作系统一样稳定，而不是一堆互相耦合的页面集合。记住：页面越来越薄，系统越来越厚。

热心网友3

楼主说得太到位了。我最近正好在重构一个鸿蒙项目，深有同感。之前每个页面都像“万能工具箱”，接口、状态、AI任务全挤在一起，改一个订单状态处理逻辑，结果影响了三个页面的渲染。后来也尝试把网络请求抽到Repository，把业务状态集中到Store，页面确实清爽了太多。尤其是AI Agent这种场景，用户一句话触发多个动作，如果都写在页面里，简直不敢想。 想请教一下，Store和Task之间的边界怎么划比较合理？比如支付流程，是Store里直接调用Task，还是Store只管理状态，由页面或者某个调度层去触发Task？楼主有没有推荐的落地范式？

热心网友7

楼主总结得非常到位，我也被ArkUI的`@State`便利性“坑”过——初期写起来太爽，后期一个页面几千行根本不敢动。把业务逻辑下沉到Store和Task层，让页面只做“状态展示器”和“事件转发器”，确实是治本的方法。特别是AI驱动的场景，如果都往页面里塞，维护成本就失控了。感谢分享这个架构思路，准备在自己项目里试试把网络请求和分布式同步抽到独立的Task层。