Store + System：鸿蒙游戏黄金分层

网罗开发小红书、快手、视频号同名大家好我是展菲目前在上市企业从事人工智能项目研发管理工作平时热衷于分享各种编程领域的软硬技能知识以及前沿技术包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。图书作者《ESP32-C3 物联网工程开发实战》图书作者《SwiftUI 入门进阶与实战》超级个体COC上海社区主理人特约讲师大学讲师谷歌亚马逊分享嘉宾科技博主华为HDE/HDG我的博客内容涵盖广泛主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告同时也会提供产品优缺点分析、横向对比并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。展菲您的前沿技术领航员 大家好我是展菲 全网搜索“展菲”即可纵览我在各大平台的知识足迹。每周定时推送干货满满的技术长文从新兴框架的剖析到运维实战的复盘助您技术进阶之路畅通无阻。文章目录引言一、先说结论二、为什么必须拆分三、Store 的唯一职责承载状态四、System 的唯一职责定义规则五、黄金分层的核心价值1、复杂度被“切断”2、逻辑可以复用3、天然可测试4、多端天然一致六、一个非常关键的误区正确方式七、进阶让 System 变“无状态”错误写法正确写法八、黄金分层的运行流程九、如何落地到真实项目Engine 示例十、为什么这是“黄金分层”1、稳定性2、扩展性3、可控性十一、开发者最容易踩的坑坑 1Store 写逻辑坑 2System 太大坑 3UI 改状态十二、一个终极认知总结引言当你把鸿蒙游戏越做越复杂你一定会撞上一堵墙逻辑开始混乱 状态开始失控 修改一个功能牵一发而动全身很多人会以为问题是代码不够优雅 命名不够规范 文件拆得不够细但真正的问题只有一个你没有做好“分层”我们把鸿蒙游戏里最重要的一条架构原则讲清楚Store System黄金分层一、先说结论Store 只负责“存什么”System 只负责“怎么变”这两个职责必须绝对分离。二、为什么必须拆分我们先看一个“很常见但有毒”的写法classGameStore{hp100exp0attack(){this.hp-10}levelUp(){if(this.exp100){this.exp0}}}看起来没问题但本质是状态 规则 混在一起结果就是无法复用 无法测试 无法扩展一句话总结Store 一旦写逻辑就会变成“上帝对象”三、Store 的唯一职责承载状态正确的 Store 应该是exportclassGameStore{hp100exp0level1}特点没有复杂逻辑 没有业务规则 没有副作用你可以把它理解为游戏世界的“当前快照”四、System 的唯一职责定义规则所有“状态如何变化”必须写在 System 里exportclassBattleSystem{attack(store:GameStore){store.hp-10if(store.hp0){store.hp0}}}exportclassLevelSystem{addExp(store:GameStore,exp:number){store.expexpif(store.exp100){store.level1store.exp0}}}一句话总结System 是“规则引擎”五、黄金分层的核心价值1、复杂度被“切断”Store不会变复杂 System按领域拆分复杂度不会再集中爆炸。2、逻辑可以复用battle.attack(store)可以在战斗 AI 自动战斗中复用。3、天然可测试battle.attack(mockStore)不需要 UI不需要环境。4、多端天然一致因为Store 是唯一状态源 System 是纯规则所以只要 Store 一致所有设备表现一致六、一个非常关键的误区很多人会这样写store.hp-10直接在 UI 或其他地方改状态。问题是你绕过了 System结果逻辑分散 不可追踪 无法维护正确方式battleSystem.attack(store)七、进阶让 System 变“无状态”一个高级但非常重要的原则System 不持有状态错误写法classBattleSystem{store:GameStore}问题生命周期混乱 多端难同步 耦合增加正确写法attack(store:GameStore){...}System只接收状态 不保存状态八、黄金分层的运行流程整个游戏运行其实就是一条链路输入点击 / AI ↓ System执行规则 ↓ Store状态变化 ↓ UI自动更新你会发现UI 不再是核心System 才是核心九、如何落地到真实项目推荐结构/store └── GameStore.ts /system ├── BattleSystem.ts ├── LevelSystem.ts ├── DropSystem.ts ├── AISystem.ts /engine └── GameEngine.ts /ui └── pages...Engine 示例classGameEngine{battlenewBattleSystem()levelnewLevelSystem()update(store:GameStore){this.battle.attack(store)this.level.addExp(store,1)}}十、为什么这是“黄金分层”因为它满足三个核心目标1、稳定性Store 很稳定2、扩展性System 可无限扩展3、可控性所有变化都经过 System十一、开发者最容易踩的坑坑 1Store 写逻辑→ 直接崩架构坑 2System 太大一个 GameSystem 管全部坑 3UI 改状态绕过规则层十二、一个终极认知当你真正理解这套分层之后你会发现系统本质是一个“状态变换系统”而不是一堆页面 一堆逻辑总结鸿蒙游戏最核心的架构原则Store只存数据 System只写规则所有复杂系统最终都可以还原为System → 改变 Store → UI 自动更新如果用一句话总结Store 决定“现在是什么”System 决定“接下来会变成什么”。