鸿蒙游戏Runtime解析：Store如何驱动整个游戏世界？

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

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

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

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

展菲：您的前沿技术领航员

👋 大家好，我是展菲！

📱 全网搜索"展菲"，即可纵览我在各大平台的知识足迹。

每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

文章目录

- 引言
- [一、为什么游戏一定会走向 Store？](#一、为什么游戏一定会走向 Store？)
- - 小游戏阶段
- 二、Store解决的到底是什么问题？
- 三、游戏中的Store与前端Store有什么区别？
- 四、游戏Runtime中的Store架构
- 五、Store如何驱动整个游戏世界？
- 六、鸿蒙游戏中的Store实现
- 七、Store拆分：大型项目最佳实践
- [八、AI时代Store正在升级为World Model](#八、AI时代Store正在升级为World Model)
- 九、未来游戏Runtime长什么样？
- 总结

引言

很多开发者刚开始做鸿蒙游戏时，都会觉得：

text 复制代码

角色移动
怪物攻击
背包管理
任务系统

不就是写几个对象、几个数组吗？例如：

ts 复制代码

let playerHp = 100

let coins = 1000

let currentMission = "新手任务"

项目初期似乎完全没问题。但是当游戏规模逐渐扩大以后，你会发现一个非常现实的问题：

text 复制代码

数据越来越多
系统越来越多
模块越来越多

最终整个项目开始变成：

text 复制代码

Player.ts
Monster.ts
Mission.ts
Bag.ts
Skill.ts

彼此互相引用、状态到处修改、Bug越来越难查。很多鸿蒙游戏项目后期出现的问题并不是：

text 复制代码

性能不足

而是：

text 复制代码

状态失控

而解决这个问题的核心，其实不是 UI，也不是 ArkUI。而是：

Store。

很多人把 Store 理解成：

text 复制代码

状态管理工具

但对于大型游戏来说：

Store 本质上是整个游戏 Runtime 的状态中心。

甚至可以说：

text 复制代码

没有 Store
就没有真正意义上的游戏 Runtime

今天我们就从架构角度聊聊：

text 复制代码

Store
↓
Game Runtime
↓
World Runtime

是如何一步步演化出来的。

一、为什么游戏一定会走向 Store？

先看最原始写法。

小游戏阶段

ts 复制代码

class Player {

  hp: number = 100

  gold: number = 1000
}

界面直接读取：

ts 复制代码

Text(`金币:${player.gold}`)

看起来很简单。但很快就会出现：

text 复制代码

背包系统
任务系统
商城系统
排行榜系统

此时：

text 复制代码

多个模块
同时修改同一份数据

例如：

ts 复制代码

player.gold += 100

你根本不知道：

text 复制代码

谁修改的
什么时候修改的
为什么修改的

于是项目开始进入混乱状态。

二、Store解决的到底是什么问题？

很多人认为：

text 复制代码

Store = 状态存储

其实不是。

Store真正解决的是：

text 复制代码

状态流向

即：

text 复制代码

谁能修改状态？
谁能读取状态？
状态如何传播？

例如：

text 复制代码

玩家击败Boss

会触发：

text 复制代码

经验增加

金币增加

任务更新

成就更新

排行榜更新

如果每个系统都直接修改数据：

text 复制代码

PlayerSystem
MissionSystem
AchievementSystem

互相耦合，最终会形成：

text 复制代码

网状依赖

而 Store 的核心思想是：

text 复制代码

所有状态修改
统一入口

例如：

ts 复制代码

store.dispatch({
  type: "ADD_GOLD",
  value: 100
})

所有系统只关心：

text 复制代码

事件

而不是彼此，这就是解耦的开始。

三、游戏中的Store与前端Store有什么区别？

很多人学过：

text 复制代码

Redux
MobX
Vuex

于是认为：

text 复制代码

游戏Store
=
前端Store

实际上差别非常大，前端Store管理：

text 复制代码

页面状态

例如：

text 复制代码

登录状态

主题颜色

列表数据

而游戏Store管理：

text 复制代码

世界状态

例如：

text 复制代码

玩家

怪物

地图

任务

技能

经济系统

规模完全不同，因此游戏中的 Store 更像：

text 复制代码

World State

而不是：

text 复制代码

UI State

四、游戏Runtime中的Store架构

在大型游戏项目中，Store通常位于整个 Runtime 的中心。

架构如下：

text 复制代码

                 Store

                    │

      ┌─────────────┼─────────────┐

      ▼             ▼             ▼

 PlayerSystem  MissionSystem  BattleSystem

      ▼             ▼             ▼

   ArkUI         ArkUI        ArkUI

所有系统：

text 复制代码

只读Store

状态变更：

text 复制代码

统一提交Store

例如：

ts 复制代码

class GameStore {

  player: Player

  mission: Mission

  battle: BattleState
}

所有数据都集中管理。

五、Store如何驱动整个游戏世界？

这是最关键的问题，很多开发者认为：

text 复制代码

Store存数据

结束了，实际上：

text 复制代码

Store驱动世界运行

例如，玩家升级：

ts 复制代码

store.dispatch({
  type: "LEVEL_UP"
})

Store更新：

ts 复制代码

player.level++

随后：

text 复制代码

技能系统
任务系统
商城系统
成就系统

全部收到通知。

text 复制代码

LEVEL_UP

成为：

text 复制代码

世界事件

整个游戏状态开始变化，所以真正的数据流是：

text 复制代码

Action

 ↓

Store

 ↓

World Update

 ↓

Render

而不是：

text 复制代码

System A

 ↓

System B

 ↓

System C

六、鸿蒙游戏中的Store实现

ArkTS本身已经具备，状态驱动的能力。例如：

ts 复制代码

@State gold: number = 100

状态变化：

ts 复制代码

this.gold += 100

界面自动刷新，但大型游戏不能把：

text 复制代码

全局状态

全部放在页面中，正确做法：

ts 复制代码

export class PlayerStore {

  @Observed
  player: Player = {
    level: 1,
    gold: 1000
  }

  addGold(value: number) {
    this.player.gold += value
  }
}

统一管理，页面订阅：

ts 复制代码

@ObjectLink
playerStore: PlayerStore

这样：

text 复制代码

状态变化
↓
Store更新
↓
UI刷新

形成完整闭环。

七、Store拆分：大型项目最佳实践

很多项目后期会出现：

ts 复制代码

GameStore

超过：

text 复制代码

5000行

最终变成：

text 复制代码

上帝对象

解决方案是：

text 复制代码

Store Domain化

例如：

text 复制代码

PlayerStore

MissionStore

BattleStore

BagStore

MapStore

每个领域单独管理，统一注册：

ts 复制代码

class RootStore {

  playerStore

  battleStore

  missionStore
}

形成 Root Store 架构，这也是目前大型项目主流方案。

八、AI时代Store正在升级为World Model

这里才是真正值得关注的地方，传统游戏：

text 复制代码

Store

管理的是：

text 复制代码

数据

而 AI 游戏：

text 复制代码

Agent

需要的是：

text 复制代码

世界认知

因此：

text 复制代码

Store
↓
World State
↓
World Model

开始演化。，例如：

ts 复制代码

interface WorldState {

  players: Player[]

  npcs: NPC[]

  regions: Region[]

  events: Event[]
}

Agent读取：

ts 复制代码

worldState

而不是：

ts 复制代码

playerStore

此时 Store 已经不是：

text 复制代码

状态管理器

而是：

text 复制代码

数字世界模型

九、未来游戏Runtime长什么样？

未来鸿蒙游戏很可能会形成如下架构：

text 复制代码

                 World Model

                       │

      ┌────────────────┼────────────────┐

      ▼                ▼                ▼

 NPC Agent      Quest Agent      Story Agent

                       │

                       ▼

                 Game Store

                       │

                       ▼

             Harmony Runtime

                       │

       Phone  Pad  PC  TV  Wearable

这里，Store负责：

text 复制代码

状态管理

Agent负责：

text 复制代码

行为决策

Harmony Runtime负责：

text 复制代码

跨设备同步

最终构成：

text 复制代码

World Runtime

总结

很多开发者第一次接触 Store 时，认为它只是：

text 复制代码

状态管理工具

但当项目规模达到一定程度以后你会发现，Store决定的并不是：

text 复制代码

数据怎么存

而是：

text 复制代码

游戏世界怎么运行

从技术演进角度看：

text 复制代码

变量
↓
Store
↓
Root Store
↓
World State
↓
World Model

这是游戏 Runtime 不断演化的过程，对于鸿蒙游戏开发而言。未来真正重要的或许已经不是：

如何设计一个页面。

而是：

如何设计一个能够驱动整个数字世界运行的 Store Runtime。

因为在 AI Agent 时代，Store 不再只是数据中心。它正在逐渐演化成：

text 复制代码

游戏世界的大脑。