鸿蒙 App 架构升级：从页面到 System

子玥酱掘金 / 知乎 / CSDN / 简书 同名大家好我是子玥酱一名长期深耕在一线的前端程序媛 ‍。曾就职于多家知名互联网大厂目前在某国企负责前端软件研发相关工作主要聚焦于业务型系统的工程化建设与长期维护。我持续输出和沉淀前端领域的实战经验日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。技术方向前端 / 跨端 / 小程序 / 移动端工程化内容平台掘金、知乎、CSDN、简书创作特点实战导向、源码拆解、少空谈多落地文章状态长期稳定更新大量原创输出我的内容主要围绕前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读展开。文章不会停留在“API 怎么用”而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍希望能帮你在实际工作中少走弯路。子玥酱 · 前端成长记录官 ✨ 如果你正在做前端或准备长期走前端这条路 关注我第一时间获取前端行业趋势与实践总结 可领取11 类前端进阶学习资源工程化 / 框架 / 跨端 / 面试 / 架构 一起把技术学“明白”也用“到位”持续写作持续进阶。愿我们都能在代码和生活里走得更稳一点 文章目录引言一、传统 App 架构的问题二、一个关键转变从“页面”到“System”三、重新定义四层结构四、第一步把“状态”从页面中剥离原来写法改造全局 Store五、第二步把“业务逻辑”从页面中剥离页面写逻辑引入 System六、第三步按“领域”拆 System示例UserSystem七、第四步引入“流程调度层”引入 Engine八、UI 的最终职责九、对比一下“升级前 vs 升级后”页面驱动System 驱动十、一个你必须跨过的认知门槛十一、一个更本质的理解十二、和游戏架构的统一总结引言如果你已经写过一段时间鸿蒙应用尤其是用 ArkUI / ArkTS你大概率会经历这样一个阶段页面越写越多 逻辑越堆越散 状态越来越乱一开始你觉得页面 功能所以你的结构通常是/pages ├── HomePage ├── DetailPage ├── ProfilePage每个页面里面UI 请求 状态 业务逻辑刚开始没问题。但当业务一复杂比如登录态 全局数据 跨页面联动 复杂交互问题就来了页面开始“承载一切”你会看到Page 文件 800 行 逻辑到处复制 状态同步混乱这时候你可能会怀疑是不是鸿蒙不适合做复杂 App不是问题的本质只有一个你还在用“页面驱动架构”但系统已经需要“System 驱动架构”一、传统 App 架构的问题先看一个典型写法// HomePage.etsStateuserInfonullonAppear(){this.loadUser()}loadUser(){api.getUser().then(res{this.userInfores})}handleClick(){if(this.userInfo.vip){this.doSomething()}}问题在哪里UI 控制数据 UI 写业务逻辑 UI 管状态换句话说页面 View Controller Service Store这就是经典问题高耦合 难复用 难测试 难扩展二、一个关键转变从“页面”到“System”你必须建立一个新的认知页面不应该驱动业务System 才应该驱动业务结构从用户点击 → 页面处理 → 更新 UI变成用户输入 → System 处理 → Store 变化 → UI 自动更新核心变化只有一句话页面变“薄”System 变“厚”三、重新定义四层结构在鸿蒙 App 中你可以把结构统一成Store状态 System业务规则 Engine调度/流程 UI展示你会发现 这和“鸿蒙游戏架构”是同一套模型因为本质都是状态驱动系统四、第一步把“状态”从页面中剥离原来写法StatecartList:Item[][]问题每个页面一份状态 无法共享 难以同步改造全局 Store// store/CartStore.tsexportclassCartStore{items:Item[][]}页面只负责“用”StatecartStore:CartStoreglobalCartStore此时状态开始集中五、第二步把“业务逻辑”从页面中剥离页面写逻辑addToCart(item){this.cartList.push(item)}问题逻辑散落 不可复用 无法测试引入 System// system/CartSystem.tsexportclassCartSystem{addItem(store:CartStore,item:Item){store.items.push(item)}removeItem(store:CartStore,id:string){store.itemsstore.items.filter(ii.id!id)}}页面变成cartSystem.addItem(cartStore,item)变化很关键UI 不再“决定逻辑”只负责“触发行为”六、第三步按“领域”拆 System不要搞一个AppSystem否则你只是把问题换个地方继续堆。正确方式/system ├── UserSystem ├── CartSystem ├── OrderSystem ├── PaymentSystem每个 System只负责一个领域示例UserSystemexportclassUserSystem{login(store:UserStore,userInfo){store.useruserInfo store.isLogintrue}logout(store:UserStore){store.usernullstore.isLoginfalse}}七、第四步引入“流程调度层”当 System 多了以后你会遇到一个问题流程谁来控制比如下单流程 校验登录 → 创建订单 → 扣库存 → 支付你不能写在 UIif(!login)returncreateOrder()pay()否则 UI 又膨胀。引入 EngineclassOrderEngine{userSystemnewUserSystem()orderSystemnewOrderSystem()paymentSystemnewPaymentSystem()submitOrder(store){if(!store.user.isLogin)returnthis.orderSystem.create(store)this.paymentSystem.pay(store)}}这层的意义组合 System 控制流程 隔离 UI八、UI 的最终职责当你完成这一步之后UI 会变成Button(下单).onClick((){orderEngine.submitOrder(store)})UI 只做三件事展示数据 接收输入 触发行为不再写业务逻辑 管理复杂状态 控制流程九、对比一下“升级前 vs 升级后”页面驱动Page 状态 逻辑 请求 流程结果页面爆炸 逻辑复制 维护困难System 驱动Store数据 System规则 Engine流程 UI展示结果结构清晰 逻辑集中 可复用 可测试十、一个你必须跨过的认知门槛很多人卡在这里“我只是写个 App有必要这么复杂吗”答案是不是你想复杂而是业务一定会复杂你现在不拆未来一定重构 而且更痛十一、一个更本质的理解当你完成这次架构升级之后你会发现你写的已经不是页面逻辑而是一个“业务状态机系统”整个 App 的运行本质是用户输入 ↓ System 处理 ↓ Store 变化 ↓ UI 自动更新十二、和游戏架构的统一你会突然发现一件很有意思的事情App 和游戏本质一样都是状态系统 都是规则驱动 都是 UI 响应所以鸿蒙的最佳架构本质是“System 驱动的一致架构”总结当你的鸿蒙 App 开始变复杂时必须完成这次升级从页面驱动 到System 驱动最终结构统一为Store唯一状态源 System业务规则 Engine流程调度 UI纯展示层如果用一句话总结鸿蒙 App 的终极形态不是“页面集合”而是一个“由 System 驱动的状态流系统”。