网罗开发 （小红书、快手、视频号同名）

  大家好，我是 展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

引言

当你把鸿蒙游戏越做越复杂，你一定会撞上一堵墙：

逻辑开始混乱
状态开始失控
修改一个功能牵一发而动全身

很多人会以为问题是：

代码不够优雅
命名不够规范
文件拆得不够细

但真正的问题只有一个：

你没有做好“分层”

我们把鸿蒙游戏里最重要的一条架构原则讲清楚：

Store + System：黄金分层

一、先说结论

Store 只负责“存什么”
System 只负责“怎么变”

这两个职责，必须绝对分离。

二、为什么必须拆分？

我们先看一个“很常见但有毒”的写法：

class GameStore {

  hp = 100
  exp = 0

  attack() {
    this.hp -= 10
  }

  levelUp() {
    if (this.exp >= 100) {
      this.exp = 0
    }
  }

}

看起来没问题，但本质是：

状态 + 规则 混在一起

结果就是：

无法复用
无法测试
无法扩展

一句话总结：

Store 一旦写逻辑，就会变成“上帝对象”

三、Store 的唯一职责：承载状态

正确的 Store 应该是：

export class GameStore {
  hp = 100
  exp = 0
  level = 1
}

特点：

没有复杂逻辑
没有业务规则
没有副作用

你可以把它理解为：

游戏世界的“当前快照”

四、System 的唯一职责：定义规则

所有“状态如何变化”，必须写在 System 里：

export class BattleSystem {

  attack(store: GameStore) {
    store.hp -= 10

    if (store.hp < 0) {
      store.hp = 0
    }
  }

}

export class LevelSystem {

  addExp(store: GameStore, exp: number) {
    store.exp += exp

    if (store.exp >= 100) {
      store.level += 1
      store.exp = 0
    }
  }

}

一句话总结：

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 不持有状态

错误写法

class BattleSystem {
  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 示例

class GameEngine {

  battle = new BattleSystem()
  level = new LevelSystem()

  update(store: GameStore) {
    this.battle.attack(store)
    this.level.addExp(store, 1)
  }

}

十、为什么这是“黄金分层”？

因为它满足三个核心目标：

1、稳定性

Store 很稳定

2、扩展性

System 可无限扩展

3、可控性

所有变化都经过 System

十一、开发者最容易踩的坑

坑 1：Store 写逻辑

→ 直接崩架构

坑 2：System 太大

一个 GameSystem 管全部

坑 3：UI 改状态

绕过规则层

十二、一个终极认知

当你真正理解这套分层之后，你会发现系统本质是：

一个“状态变换系统”

而不是：

一堆页面 + 一堆逻辑

总结

鸿蒙游戏最核心的架构原则：

Store：只存数据
System：只写规则

所有复杂系统，最终都可以还原为：

System → 改变 Store → UI 自动更新

如果用一句话总结：

Store 决定“现在是什么”，System 决定“接下来会变成什么”。