网罗开发小红书、快手、视频号同名大家好我是展菲目前在上市企业从事人工智能项目研发管理工作平时热衷于分享各种编程领域的软硬技能知识以及前沿技术包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。图书作者《ESP32-C3 物联网工程开发实战》图书作者《SwiftUI 入门进阶与实战》超级个体COC上海社区主理人特约讲师大学讲师谷歌亚马逊分享嘉宾科技博主华为HDE/HDG我的博客内容涵盖广泛主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告同时也会提供产品优缺点分析、横向对比并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。展菲您的前沿技术领航员 大家好我是展菲 全网搜索“展菲”即可纵览我在各大平台的知识足迹。每周定时推送干货满满的技术长文从新兴框架的剖析到运维实战的复盘助您技术进阶之路畅通无阻。文章目录引言一、为什么传统 App 页面会越来越重二、鸿蒙为什么更容易出现“大页面”三、真正的问题页面承担了“不属于它的责任”四、为什么未来页面一定越来越薄五、页面真正应该负责什么1、UI 展示2、用户交互3、局部 UI 状态页面不应该负责六、真正的变化Store 开始成为中心为什么手机页面平板页面TV 页面七、AI 为什么会逼着页面“变薄”八、Task 架构会进一步削弱“页面中心化”九、真正优秀的鸿蒙项目都有一个特点十、为什么“页面越来越薄”是必然趋势十一、未来鸿蒙 App 的真正核心State FlowTask RuntimeAI RuntimeDistributed Runtime十二、一个非常关键的认知十三、总结引言很多人刚开始做鸿蒙 App 时都会下意识这样设计页面 功能于是页面写逻辑页面调接口页面管状态页面处理流程项目初期开发非常快但随着项目越来越大很快就会进入一种熟悉状态页面越来越厚 一个页面几千行最后不敢改 一改就连锁爆炸很多团队做到后面才慢慢意识到真正稳定的鸿蒙架构页面一定会越来越“薄”。因为未来鸿蒙 App 的核心已经不再是Page而是Task State Runtime页面开始从“业务中心”变成“状态展示层”这是未来 AI Native 鸿蒙 App 一个非常重要的变化。一、为什么传统 App 页面会越来越重因为传统移动开发一直是页面驱动典型结构Page ↓ 业务逻辑 ↓ 接口 ↓ 数据于是很多页面最后会变成loadUser()loadOrder()submit()pay()cancel()页面既负责UI数据流程网络状态最后页面会变成一个“巨型控制器”。二、鸿蒙为什么更容易出现“大页面”因为 ArkUI状态驱动非常方便很多人很容易Stateorders:Order[]Stateuser:UserStateloading: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.userxxx分布式同步错误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 功能入口例如帮我继续昨天没看完的视频系统自动找视频找播放记录切换设备恢复进度这里用户甚至没进入页面所以未来页面的重要性会持续下降九、真正优秀的鸿蒙项目都有一个特点不是页面特别复杂而是页面极其简单很多成熟项目页面最后只有UIStore BindingEvent例如Button(支付).onClick((){orderStore.pay()})页面根本不知道怎么支付怎么调接口怎么同步状态这些都在Task / Store / Runtime内部完成。十、为什么“页面越来越薄”是必然趋势因为未来 App 会越来越系统化而不是页面化过去页面驱动功能未来任务驱动系统过去用户操作 UI未来用户表达目标所以UI 会逐渐外围化十一、未来鸿蒙 App 的真正核心未来真正核心会变成State Flow负责状态流转Task Runtime负责任务执行AI Runtime负责智能调度Distributed Runtime负责多设备协同页面只负责把结果显示出来十二、一个非常关键的认知很多人会觉得页面代码少了 是不是架构退化了其实恰恰相反真正成熟的系统一定是页面越来越简单系统越来越强。因为复杂度被“下沉”了下沉到StoreRuntimeTaskAIDomain这些真正稳定的地方。十三、总结如果用一句话总结页面越来越薄本质上是 App 开始“系统化”。过去Page First未来Runtime First过去页面组织能力未来Task 组织能力过去UI 驱动功能未来State 驱动系统很多鸿蒙项目后期越来越难维护并不是因为ArkUI 太复杂分布式太难AI 太重真正的问题是页面承担了太多“不属于页面”的责任。记住一句话真正优秀的鸿蒙架构 一定是 页面越来越薄 系统越来越厚。当你真正完成Store 中心化Task 化Runtime 化状态分层AI 解耦页面去业务化你会明显感觉到整个鸿蒙 App 开始“像操作系统” 而不是“页面集合”
鸿蒙 App 架构：为什么页面越来越薄？
发布时间：2026/5/26 6:15:47
网罗开发小红书、快手、视频号同名大家好我是展菲目前在上市企业从事人工智能项目研发管理工作平时热衷于分享各种编程领域的软硬技能知识以及前沿技术包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。图书作者《ESP32-C3 物联网工程开发实战》图书作者《SwiftUI 入门进阶与实战》超级个体COC上海社区主理人特约讲师大学讲师谷歌亚马逊分享嘉宾科技博主华为HDE/HDG我的博客内容涵盖广泛主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告同时也会提供产品优缺点分析、横向对比并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。展菲您的前沿技术领航员 大家好我是展菲 全网搜索“展菲”即可纵览我在各大平台的知识足迹。每周定时推送干货满满的技术长文从新兴框架的剖析到运维实战的复盘助您技术进阶之路畅通无阻。文章目录引言一、为什么传统 App 页面会越来越重二、鸿蒙为什么更容易出现“大页面”三、真正的问题页面承担了“不属于它的责任”四、为什么未来页面一定越来越薄五、页面真正应该负责什么1、UI 展示2、用户交互3、局部 UI 状态页面不应该负责六、真正的变化Store 开始成为中心为什么手机页面平板页面TV 页面七、AI 为什么会逼着页面“变薄”八、Task 架构会进一步削弱“页面中心化”九、真正优秀的鸿蒙项目都有一个特点十、为什么“页面越来越薄”是必然趋势十一、未来鸿蒙 App 的真正核心State FlowTask RuntimeAI RuntimeDistributed Runtime十二、一个非常关键的认知十三、总结引言很多人刚开始做鸿蒙 App 时都会下意识这样设计页面 功能于是页面写逻辑页面调接口页面管状态页面处理流程项目初期开发非常快但随着项目越来越大很快就会进入一种熟悉状态页面越来越厚 一个页面几千行最后不敢改 一改就连锁爆炸很多团队做到后面才慢慢意识到真正稳定的鸿蒙架构页面一定会越来越“薄”。因为未来鸿蒙 App 的核心已经不再是Page而是Task State Runtime页面开始从“业务中心”变成“状态展示层”这是未来 AI Native 鸿蒙 App 一个非常重要的变化。一、为什么传统 App 页面会越来越重因为传统移动开发一直是页面驱动典型结构Page ↓ 业务逻辑 ↓ 接口 ↓ 数据于是很多页面最后会变成loadUser()loadOrder()submit()pay()cancel()页面既负责UI数据流程网络状态最后页面会变成一个“巨型控制器”。二、鸿蒙为什么更容易出现“大页面”因为 ArkUI状态驱动非常方便很多人很容易Stateorders:Order[]Stateuser:UserStateloading: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.userxxx分布式同步错误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 功能入口例如帮我继续昨天没看完的视频系统自动找视频找播放记录切换设备恢复进度这里用户甚至没进入页面所以未来页面的重要性会持续下降九、真正优秀的鸿蒙项目都有一个特点不是页面特别复杂而是页面极其简单很多成熟项目页面最后只有UIStore BindingEvent例如Button(支付).onClick((){orderStore.pay()})页面根本不知道怎么支付怎么调接口怎么同步状态这些都在Task / Store / Runtime内部完成。十、为什么“页面越来越薄”是必然趋势因为未来 App 会越来越系统化而不是页面化过去页面驱动功能未来任务驱动系统过去用户操作 UI未来用户表达目标所以UI 会逐渐外围化十一、未来鸿蒙 App 的真正核心未来真正核心会变成State Flow负责状态流转Task Runtime负责任务执行AI Runtime负责智能调度Distributed Runtime负责多设备协同页面只负责把结果显示出来十二、一个非常关键的认知很多人会觉得页面代码少了 是不是架构退化了其实恰恰相反真正成熟的系统一定是页面越来越简单系统越来越强。因为复杂度被“下沉”了下沉到StoreRuntimeTaskAIDomain这些真正稳定的地方。十三、总结如果用一句话总结页面越来越薄本质上是 App 开始“系统化”。过去Page First未来Runtime First过去页面组织能力未来Task 组织能力过去UI 驱动功能未来State 驱动系统很多鸿蒙项目后期越来越难维护并不是因为ArkUI 太复杂分布式太难AI 太重真正的问题是页面承担了太多“不属于页面”的责任。记住一句话真正优秀的鸿蒙架构 一定是 页面越来越薄 系统越来越厚。当你真正完成Store 中心化Task 化Runtime 化状态分层AI 解耦页面去业务化你会明显感觉到整个鸿蒙 App 开始“像操作系统” 而不是“页面集合”
