网罗开发小红书、快手、视频号同名大家好我是展菲目前在上市企业从事人工智能项目研发管理工作平时热衷于分享各种编程领域的软硬技能知识以及前沿技术包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。图书作者《ESP32-C3 物联网工程开发实战》图书作者《SwiftUI 入门进阶与实战》超级个体COC上海社区主理人特约讲师大学讲师谷歌亚马逊分享嘉宾科技博主华为HDE/HDG我的博客内容涵盖广泛主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告同时也会提供产品优缺点分析、横向对比并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。展菲您的前沿技术领航员 大家好我是展菲 全网搜索“展菲”即可纵览我在各大平台的知识足迹。 公众号“Swift社区”每周定时推送干货满满的技术长文从新兴框架的剖析到运维实战的复盘助您技术进阶之路畅通无阻。 微信端添加好友“fzhanfei”与我直接交流不管是项目瓶颈的求助还是行业趋势的探讨随时畅所欲言。 最新动态2025 年 3 月 17 日快来加入技术社区一起挖掘技术的无限潜能携手迈向数字化新征程文章目录引言一、什么是数据流二、鸿蒙常见的数据流问题1 数据来源混乱2 状态分散3 UI 直接操作数据三、一个好的数据流应该具备什么1 单向流动2 单一数据源3 可追踪四、推荐的数据流架构五、分层详解 代码示例1 UI 层ArkUI2 ViewModel / 状态层3 Service / UseCase 层4 Repository 层5 DataSource 层六、AI 场景下的数据流变化传统数据流AI 数据流示例代码七、关键设计状态管理推荐做法错误写法正确写法八、数据流设计的进阶优化1 引入 Store全局状态2 引入事件流Event Bus3 引入缓存策略4 数据不可变推荐九、完整数据流示意总结1 单向数据流2 单一数据源3 UI 只负责展示引言很多鸿蒙应用一开始都很简单页面请求数据 → 渲染 UI → 完成但随着项目变大你很快会遇到这些问题数据更新了但 UI 没刷新多个页面状态不一致网络数据、缓存数据、内存数据混在一起AI 功能接入后数据流彻底混乱这时候你会发现问题不在 UI而在“数据是怎么流动的”。数据流才是一个 App 是否稳定、可扩展的关键。一、什么是数据流简单来说数据流 数据从哪里来经过哪里最终到哪里去在鸿蒙应用中一个完整的数据流通常是用户操作 ↓ 触发逻辑 ↓ 获取数据网络 / 本地 ↓ 状态更新 ↓ UI 渲染看起来很简单但复杂项目里数据来源会变多网络数据 缓存数据 本地数据库 AI 结果 设备数据传感器一旦没有清晰的数据流设计 Bug 会非常难查二、鸿蒙常见的数据流问题先看几个真实开发中经常踩的坑。1 数据来源混乱// 页面直接请求this.dataawaithttp.get()// Service 里也请求this.service.getData()// Repository 也在请求this.repo.fetch()问题数据来源不唯一很难统一管理2 状态分散StatedataAStatedataBStatedataC不同页面各自维护一套状态数据不同步3 UI 直接操作数据this.list.push(item)问题无法追踪数据变化UI 状态不可预测三、一个好的数据流应该具备什么一个设计良好的数据流应该具备1 单向流动Data → State → UI而不是UI ↔ Data双向混乱2 单一数据源Single Source of Truth3 可追踪每一次数据变化都可以知道谁改的 什么时候改的 为什么改四、推荐的数据流架构在鸿蒙应用中推荐采用类似这样的结构UI Layer ↓ ViewModel / State ↓ UseCase / Service ↓ Repository ↓ DataSourceNetwork / DB / Cache五、分层详解 代码示例1 UI 层ArkUIUI 层只负责展示数据 触发事件示例EntryComponentstruct UserPage{Stateusernullvm:UserViewModelnewUserViewModel()aboutToAppear(){this.vm.loadUser()}}UI 不直接请求数据2 ViewModel / 状态层负责管理状态 驱动 UI 更新示例exportclassUserViewModel{ObservedusernullasyncloadUser(){this.userawaituserService.getUser()}}所有 UI 状态集中在这里3 Service / UseCase 层负责业务逻辑 数据组合示例exportclassUserService{asyncgetUserProfile(){constuserawaituserRepo.getUser()constordersawaitorderRepo.getOrders(user.id)return{user,orders}}}4 Repository 层负责数据来源统一 缓存策略示例exportclassUserRepository{asyncgetUser(){constcacheawaitcache.get(user)if(cache)returncacheconstdataawaitapi.get(/user)cache.set(user,data)returndata}}统一数据入口5 DataSource 层负责真正的数据获取例如exportclassApiClient{asyncget(url:string){returnfetch(url)}}六、AI 场景下的数据流变化当接入 AI 后数据流会发生变化传统数据流UI → Service → Repository → DataAI 数据流用户输入 ↓ AI解析意图 ↓ Service / Tool ↓ Repository ↓ 数据返回 ↓ UI 展示示例代码exportclassAIService{asynchandle(input:string){constintentawaitthis.parse(input)if(intentuser){returnawaituserService.getUser()}if(intentorder){returnawaitorderService.getOrders()}}}数据流不再由 UI 驱动而是由 AI 驱动。七、关键设计状态管理鸿蒙 ArkUI 中的状态机制State Observed ObjectLink推荐做法状态只存在一个地方ViewModel / Store错误写法PageA 自己维护一份 PageB 再维护一份正确写法exportclassGlobalStore{Observedusernull}多个页面共享ObjectLinkstore:GlobalStore八、数据流设计的进阶优化1 引入 Store全局状态适用于用户信息 登录状态 主题配置2 引入事件流Event Bus适用于跨模块通信3 引入缓存策略例如内存缓存 磁盘缓存 过期策略4 数据不可变推荐避免this.list.push()改为this.list[...this.list,newItem]更容易追踪变化九、完整数据流示意用户点击 / AI 输入 ↓ ViewModel ↓ Service ↓ Repository ↓ DataSource ↓ 返回数据 ↓ 更新 State ↓ UI 渲染总结很多鸿蒙应用的问题其实都不是 UI 问题而是数据流没有设计好。记住三个核心原则1 单向数据流Data → State → UI2 单一数据源不要多个地方同时改数据3 UI 只负责展示不要让 UI 参与业务逻辑当你把数据流设计清楚之后你会发现Bug 明显减少状态更稳定AI 接入也更自然
鸿蒙 App 的数据流设计
发布时间：2026/7/26 9:45:23
网罗开发小红书、快手、视频号同名大家好我是展菲目前在上市企业从事人工智能项目研发管理工作平时热衷于分享各种编程领域的软硬技能知识以及前沿技术包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。图书作者《ESP32-C3 物联网工程开发实战》图书作者《SwiftUI 入门进阶与实战》超级个体COC上海社区主理人特约讲师大学讲师谷歌亚马逊分享嘉宾科技博主华为HDE/HDG我的博客内容涵盖广泛主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告同时也会提供产品优缺点分析、横向对比并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。展菲您的前沿技术领航员 大家好我是展菲 全网搜索“展菲”即可纵览我在各大平台的知识足迹。 公众号“Swift社区”每周定时推送干货满满的技术长文从新兴框架的剖析到运维实战的复盘助您技术进阶之路畅通无阻。 微信端添加好友“fzhanfei”与我直接交流不管是项目瓶颈的求助还是行业趋势的探讨随时畅所欲言。 最新动态2025 年 3 月 17 日快来加入技术社区一起挖掘技术的无限潜能携手迈向数字化新征程文章目录引言一、什么是数据流二、鸿蒙常见的数据流问题1 数据来源混乱2 状态分散3 UI 直接操作数据三、一个好的数据流应该具备什么1 单向流动2 单一数据源3 可追踪四、推荐的数据流架构五、分层详解 代码示例1 UI 层ArkUI2 ViewModel / 状态层3 Service / UseCase 层4 Repository 层5 DataSource 层六、AI 场景下的数据流变化传统数据流AI 数据流示例代码七、关键设计状态管理推荐做法错误写法正确写法八、数据流设计的进阶优化1 引入 Store全局状态2 引入事件流Event Bus3 引入缓存策略4 数据不可变推荐九、完整数据流示意总结1 单向数据流2 单一数据源3 UI 只负责展示引言很多鸿蒙应用一开始都很简单页面请求数据 → 渲染 UI → 完成但随着项目变大你很快会遇到这些问题数据更新了但 UI 没刷新多个页面状态不一致网络数据、缓存数据、内存数据混在一起AI 功能接入后数据流彻底混乱这时候你会发现问题不在 UI而在“数据是怎么流动的”。数据流才是一个 App 是否稳定、可扩展的关键。一、什么是数据流简单来说数据流 数据从哪里来经过哪里最终到哪里去在鸿蒙应用中一个完整的数据流通常是用户操作 ↓ 触发逻辑 ↓ 获取数据网络 / 本地 ↓ 状态更新 ↓ UI 渲染看起来很简单但复杂项目里数据来源会变多网络数据 缓存数据 本地数据库 AI 结果 设备数据传感器一旦没有清晰的数据流设计 Bug 会非常难查二、鸿蒙常见的数据流问题先看几个真实开发中经常踩的坑。1 数据来源混乱// 页面直接请求this.dataawaithttp.get()// Service 里也请求this.service.getData()// Repository 也在请求this.repo.fetch()问题数据来源不唯一很难统一管理2 状态分散StatedataAStatedataBStatedataC不同页面各自维护一套状态数据不同步3 UI 直接操作数据this.list.push(item)问题无法追踪数据变化UI 状态不可预测三、一个好的数据流应该具备什么一个设计良好的数据流应该具备1 单向流动Data → State → UI而不是UI ↔ Data双向混乱2 单一数据源Single Source of Truth3 可追踪每一次数据变化都可以知道谁改的 什么时候改的 为什么改四、推荐的数据流架构在鸿蒙应用中推荐采用类似这样的结构UI Layer ↓ ViewModel / State ↓ UseCase / Service ↓ Repository ↓ DataSourceNetwork / DB / Cache五、分层详解 代码示例1 UI 层ArkUIUI 层只负责展示数据 触发事件示例EntryComponentstruct UserPage{Stateusernullvm:UserViewModelnewUserViewModel()aboutToAppear(){this.vm.loadUser()}}UI 不直接请求数据2 ViewModel / 状态层负责管理状态 驱动 UI 更新示例exportclassUserViewModel{ObservedusernullasyncloadUser(){this.userawaituserService.getUser()}}所有 UI 状态集中在这里3 Service / UseCase 层负责业务逻辑 数据组合示例exportclassUserService{asyncgetUserProfile(){constuserawaituserRepo.getUser()constordersawaitorderRepo.getOrders(user.id)return{user,orders}}}4 Repository 层负责数据来源统一 缓存策略示例exportclassUserRepository{asyncgetUser(){constcacheawaitcache.get(user)if(cache)returncacheconstdataawaitapi.get(/user)cache.set(user,data)returndata}}统一数据入口5 DataSource 层负责真正的数据获取例如exportclassApiClient{asyncget(url:string){returnfetch(url)}}六、AI 场景下的数据流变化当接入 AI 后数据流会发生变化传统数据流UI → Service → Repository → DataAI 数据流用户输入 ↓ AI解析意图 ↓ Service / Tool ↓ Repository ↓ 数据返回 ↓ UI 展示示例代码exportclassAIService{asynchandle(input:string){constintentawaitthis.parse(input)if(intentuser){returnawaituserService.getUser()}if(intentorder){returnawaitorderService.getOrders()}}}数据流不再由 UI 驱动而是由 AI 驱动。七、关键设计状态管理鸿蒙 ArkUI 中的状态机制State Observed ObjectLink推荐做法状态只存在一个地方ViewModel / Store错误写法PageA 自己维护一份 PageB 再维护一份正确写法exportclassGlobalStore{Observedusernull}多个页面共享ObjectLinkstore:GlobalStore八、数据流设计的进阶优化1 引入 Store全局状态适用于用户信息 登录状态 主题配置2 引入事件流Event Bus适用于跨模块通信3 引入缓存策略例如内存缓存 磁盘缓存 过期策略4 数据不可变推荐避免this.list.push()改为this.list[...this.list,newItem]更容易追踪变化九、完整数据流示意用户点击 / AI 输入 ↓ ViewModel ↓ Service ↓ Repository ↓ DataSource ↓ 返回数据 ↓ 更新 State ↓ UI 渲染总结很多鸿蒙应用的问题其实都不是 UI 问题而是数据流没有设计好。记住三个核心原则1 单向数据流Data → State → UI2 单一数据源不要多个地方同时改数据3 UI 只负责展示不要让 UI 参与业务逻辑当你把数据流设计清楚之后你会发现Bug 明显减少状态更稳定AI 接入也更自然
