鸿蒙游戏 Store 设计（AI + 多端）

子玥酱 （掘金 / 知乎 / CSDN / 简书同名）

大家好，我是子玥酱，一名长期深耕在一线的前端程序媛 👩‍💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案，

在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

技术方向： 前端 / 跨端 / 小程序 / 移动端工程化 内容平台： 掘金、知乎、CSDN、简书 创作特点： 实战导向、源码拆解、少空谈多落地 **文章状态：**长期稳定更新，大量原创输出

我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在"API 怎么用"，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。

子玥酱 · 前端成长记录官 ✨

👋 如果你正在做前端，或准备长期走前端这条路

📚 关注我，第一时间获取前端行业趋势与实践总结

🎁 可领取 11 类前端进阶学习资源 （工程化 / 框架 / 跨端 / 面试 / 架构）

💡 一起把技术学"明白"，也用"到位"

持续写作，持续进阶。

愿我们都能在代码和生活里，走得更稳一点 🌱

文章目录

- 引言
- 一、先说结论
- [二、最小 Store（先从简单开始）](#二、最小 Store（先从简单开始）)
- - 错误写法
  - 正确基础写法
- [三、第一步升级：模块化 Store](#三、第一步升级：模块化 Store)
- - 模块化结构
  - [对应 Store 更新](#对应 Store 更新)
- [四、第二步升级：Action 机制](#四、第二步升级：Action 机制)
- - [引入 Action](#引入 Action)
  - Reducer
  - 使用方式
- [五、第三步升级：支持 AI](#五、第三步升级：支持 AI)
- - 问题
  - [正确方式：AI → Action](#正确方式：AI → Action)
  - 执行
- 六、第四步升级：支持多端
- - 问题
  - [方案：Store → 分布式同步](#方案：Store → 分布式同步)
  - 同步逻辑
  - 其他设备接收
- 七、第五步升级：支持网络
- - 场景
  - 统一入口
  - 示例
- [八、完整 Store 架构](#八、完整 Store 架构)
- 九、为什么这样设计？
- - 1、可控性
  - 2、可扩展性
  - 3、可调试性
- 十、常见错误
- - [1、直接改 state](#1、直接改 state)
  - [2、UI 调用多个逻辑](#2、UI 调用多个逻辑)
  - 3、不同设备不同逻辑
  - [4、AI 绕过 Store](#4、AI 绕过 Store)
- 总结

引言

如果你已经写过几天鸿蒙游戏，大概率会遇到一个问题：

一开始一切正常，后面越写越乱。

具体表现：

状态到处都是
多端同步很难搞
AI 加进来之后彻底失控

最后你会发现：

问题不在功能，而在 Store 设计。

在 HarmonyOS 中：

Store，不只是"状态管理"，而是整个系统的"中枢"。

一、先说结论

一个"正确"的 Store，必须满足 3 个能力：

复制代码

1 单一状态源（Single Source of Truth）
2 可扩展数据结构
3 可控的数据流（谁能改状态）

如果缺任何一个：

小项目还能跑
大项目一定崩

二、最小 Store（先从简单开始）

错误写法

ts 复制代码

export class GameStore {
  score = 0
  playerX = 0
}

问题：

状态分散
无法扩展
无法统一更新

正确基础写法

ts 复制代码

export interface GameState {
  player: { x: number; y: number }
  score: number
}

export class GameStore {

  state: GameState = {
    player: { x: 0, y: 0 },
    score: 0
  }

  update(partial: Partial<GameState>) {
    this.state = { ...this.state, ...partial }
  }

}

export const gameStore = new GameStore()

核心：

所有状态必须集中在一个对象里

三、第一步升级：模块化 Store

当游戏变大，你不能再用一个"平铺 state"。

模块化结构

ts 复制代码

export interface GameState {
  player: PlayerState
  ui: UIState
  task: TaskState
}

export interface PlayerState {
  x: number
  y: number
  hp: number
}

export interface UIState {
  dialog: string[]
}

export interface TaskState {
  current: string
}

好处：

分层清晰
易扩展
易维护

对应 Store 更新

ts 复制代码

updatePlayer(partial: Partial<PlayerState>) {
  this.state.player = {
    ...this.state.player,
    ...partial
  }
}

不再直接操作顶层。

四、第二步升级：Action 机制

问题来了：谁都可以 update()，会发生什么？

答案：状态失控

引入 Action

ts 复制代码

type Action =
  | { type: 'MOVE'; payload: { x: number } }
  | { type: 'ADD_SCORE'; payload: number }

Reducer

ts 复制代码

dispatch(action: Action) {

  switch (action.type) {

    case 'MOVE':
      this.state.player.x += action.payload.x
      break

    case 'ADD_SCORE':
      this.state.score += action.payload
      break
  }

}

核心：

所有状态修改必须通过 dispatch

使用方式

ts 复制代码

gameStore.dispatch({
  type: 'ADD_SCORE',
  payload: 10
})

好处：

所有变更可追踪
Debug 简单
AI / 多端更安全

五、第三步升级：支持 AI

AI 会成为"状态输入源"。

问题

如果 AI 直接改状态：

ts 复制代码

gameStore.state.score = 999

完全失控。

正确方式：AI → Action

ts 复制代码

class NPCAgent {

  decide(state) {
    if (state.player.x > 100) {
      return { type: 'ADD_SCORE', payload: 5 }
    }
    return null
  }

}

执行

ts 复制代码

const action = agent.decide(gameStore.state)

if (action) {
  gameStore.dispatch(action)
}

本质：

AI 也是一个"合法的数据输入源"

六、第四步升级：支持多端

问题

多设备：

复制代码

手机 + TV + 平板

状态如何同步？

方案：Store → 分布式同步

ts 复制代码

dispatch(action: Action) {

  this.reduce(action)

  this.sync(action)

}

同步逻辑

ts 复制代码

sync(action: Action) {
  distributedSync.send(action)
}

其他设备接收

ts 复制代码

onReceive(action: Action) {
  this.reduce(action)
}

核心：

同步 Action，而不是同步 State

好处：

更轻量
可回放
可调试

七、第五步升级：支持网络

场景

排行榜 / 多人游戏。

统一入口

ts 复制代码

dispatch(action: Action) {

  this.reduce(action)

  this.syncToDevices(action)

  this.syncToServer(action)

}

示例

ts 复制代码

syncToServer(action: Action) {
  fetch('/api/action', {
    method: 'POST',
    body: JSON.stringify(action)
  })
}

本质：

所有数据变化统一出口

八、完整 Store 架构

复制代码

Input（UI / AI / 网络 / 多端）
           ↓
        Action
           ↓
       Store.dispatch
           ↓
        Reducer
           ↓
        State
           ↓
          UI

扩展：

复制代码

dispatch
  ↓
本地更新
  ↓
多端同步
  ↓
服务端同步

九、为什么这样设计？

1、可控性

复制代码

所有状态变化都有入口

2、可扩展性

轻松支持：

AI
多端
网络

3、可调试性

ts 复制代码

console.log(action)

可回放。

十、常见错误

1、直接改 state

ts 复制代码

state.score++

2、UI 调用多个逻辑

数据流混乱。

3、不同设备不同逻辑

状态不一致。

4、AI 绕过 Store

失控。

总结

一个支持 AI + 多端 + 网络 的鸿蒙游戏 Store，本质是：

复制代码

State（数据）
Action（变化）
Reducer（规则）

核心原则：

复制代码

所有变化必须走 Action
所有数据集中在 Store

在 HarmonyOS 中，这种 Store 设计带来的不是"代码优化"，而是：

从"写逻辑"，升级为"设计系统"。

你的游戏能走多远，取决于你的 Store 能撑多复杂。