鸿蒙 App 重构：如何从混乱到清晰？

子玥酱掘金 / 知乎 / CSDN / 简书 同名大家好我是子玥酱一名长期深耕在一线的前端程序媛 ‍。曾就职于多家知名互联网大厂目前在某国企负责前端软件研发相关工作主要聚焦于业务型系统的工程化建设与长期维护。我持续输出和沉淀前端领域的实战经验日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。技术方向前端 / 跨端 / 小程序 / 移动端工程化内容平台掘金、知乎、CSDN、简书创作特点实战导向、源码拆解、少空谈多落地文章状态长期稳定更新大量原创输出我的内容主要围绕前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读展开。文章不会停留在“API 怎么用”而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍希望能帮你在实际工作中少走弯路。子玥酱 · 前端成长记录官 ✨ 如果你正在做前端或准备长期走前端这条路 关注我第一时间获取前端行业趋势与实践总结 可领取11 类前端进阶学习资源工程化 / 框架 / 跨端 / 面试 / 架构 一起把技术学“明白”也用“到位”持续写作持续进阶。愿我们都能在代码和生活里走得更稳一点 文章目录引言一、为什么鸿蒙 App 更容易“越写越乱”一个典型项目演化过程二、真正的问题不是代码多而是边界消失了三、重构第一步先拆“状态”最危险的写法正确做法状态分层四、重构第二步System 必须“去状态化”正确原则五、重构第三步建立“唯一状态入口”正确模型六、重构第四步从“页面驱动”变成“Task 驱动”传统流程新模型七、重构第五步拆“领域”正确做法领域隔离示例结构八、重构第六步建立“状态流”推荐结构示例九、为什么 AI 会逼着鸿蒙 App 重构十、真正优秀的鸿蒙项目都有一个共同点十一、一个非常重要的认知原来重构后十二、本质结语引言很多人第一次写鸿蒙 App 时都会有一种错觉ArkUI 很简单 状态驱动很舒服 开发效率非常高于是项目初期往往推进得特别快。但只要项目开始变大很快就会进入一种熟悉的状态页面越来越大 状态越来越乱 System 越来越重 模块越来越耦合最后整个项目会慢慢变成不敢改 一改就炸很多团队最后会发现真正难的从来不是“写功能”。而是如何让项目长期保持清晰。这也是为什么重构会成为中大型鸿蒙项目绕不开的话题。一、为什么鸿蒙 App 更容易“越写越乱”因为鸿蒙天然具备状态驱动分布式多设备实时同步AI 调度Task 流转这些能力虽然强大但也意味着系统复杂度会指数级上升。一个典型项目演化过程项目初期一个页面 几个状态 几个接口非常简单三个月后页面互相依赖 Store 互相调用 System 到处共享状态半年后没人敢删代码 没人知道状态来源最后整个项目进入“混乱熵增”二、真正的问题不是代码多而是边界消失了很多人会误以为项目乱 是因为代码量大其实不是真正的问题是边界消失。例如UI 能改状态 System 能改状态 Service 能改状态 AI 也能改状态最后没人知道谁是“真正的数据源”三、重构第一步先拆“状态”很多鸿蒙项目最大的问题状态没有分层。最危险的写法Stateuser:UserStateorder:OrderStateproducts:Product[]Stateloading:boolean页面既负责 UI 又负责业务 又负责数据最后页面会越来越巨大。正确做法状态分层推荐一个非常稳定的结构GlobalState全局 ↓ DomainStore业务 ↓ UIState页面1、全局状态负责用户登录设备分布式信息示例globalStore.user2、业务状态负责订单商品搜索消息示例orderStore.orders3、页面状态负责LoadingDialogTab动画示例StateshowDialog:boolean这里最关键的一点页面不要存业务数据。四、重构第二步System 必须“去状态化”很多鸿蒙项目最容易出现的问题System 越来越胖例如classOrderSystem{currentOrder:Order}看起来很方便但后面一定会出现状态覆盖并发冲突分布式同步异常正确原则System 只负责“处理”不负责“存储”。正确写法classOrderSystem{asynccreate(order){returnawaitorderService.create(order)}}System 应该是无状态能力层而不是全局状态黑洞五、重构第三步建立“唯一状态入口”很多项目会这样PageA 修改 user PageB 修改 user System 修改 user结果状态来源失控正确模型一个状态 只有一个写入口示例classUserStore{user:Userupdate(user:User){this.useruser}}外部只能userStore.update(...)而不是this.userxxx到处乱改。六、重构第四步从“页面驱动”变成“Task 驱动”传统 App页面是核心但 AI 鸿蒙时代任务才是核心传统流程页面 ↓ 按钮 ↓ 功能新模型Intent ↓ Task ↓ State ↓ UI示例awaittaskCenter.run(创建订单)UI 只负责展示任务结果七、重构第五步拆“领域”很多项目的问题所有模块互相调用最后改一个功能 整个项目一起震正确做法领域隔离例如user/ order/ message/ payment/每个领域StoreSystemRepositoryTask独立存在。示例结构order/ ├── store/ ├── system/ ├── repository/ ├── task/ └── ui/八、重构第六步建立“状态流”很多鸿蒙项目的问题状态是乱流必须建立统一状态流。推荐结构User Action ↓ Store ↓ System ↓ Repository ↓ Store Update ↓ UI Render示例UIButton(提交).onClick((){orderStore.submit()})Storeasyncsubmit(){constresultawaitorderSystem.create()this.orderresult}Systemasynccreate(){returnawaitrepository.create()}这里UI 不直接操作数据 System 不直接持有状态整个系统会清晰很多。九、为什么 AI 会逼着鸿蒙 App 重构因为 AI 会极速放大架构问题传统 App用户一次操作 只改一个状态AI App一次任务 可能改几十个状态例如awaitagent.run(整理今天会议)AI 可能更新日历创建待办写入笔记发送消息修改提醒如果架构混乱整个 App 会瞬间失控十、真正优秀的鸿蒙项目都有一个共同点不是页面多漂亮而是结构极其清晰优秀项目通常具备状态分层Store 中心化无状态 SystemTask 驱动领域拆分分布式状态隔离这些东西决定项目后期是否还能继续迭代。十一、一个非常重要的认知很多人以为重构 重写其实不是真正的重构是重新建立“边界”。比如原来所有模块互相依赖重构后模块职责明确 状态边界明确 数据流明确本质上重构不是“改代码” 而是“改结构”十二、本质如果用一句话总结鸿蒙 App 的混乱本质是“边界失控”。真正好的架构一定具备状态有边界 模块有边界 任务有边界 设备有边界 AI 有边界一旦边界清晰整个系统会突然稳定结语很多鸿蒙项目后期崩掉并不是因为功能太复杂AI 太难分布式太重真正的问题只有一个系统没有“结构秩序”。记住一句话代码的混乱 本质是架构边界的混乱。当你真正完成状态分层Task 化Store 中心化无状态 System领域拆分你会明显感受到项目终于“能长期维护了”