大家好，我是展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。
图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG
我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。
展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。
文章目录
- 引言
- 一、为什么游戏一定会走向 Store？
- 小游戏阶段
- 二、Store解决的到底是什么问题？
- 三、游戏中的Store与前端Store有什么区别？
- 四、游戏Runtime中的Store架构
- 五、Store如何驱动整个游戏世界？
- 六、鸿蒙游戏中的Store实现
- 七、Store拆分：大型项目最佳实践
- 八、AI时代Store正在升级为World Model
- 九、未来游戏Runtime长什么样？
- 总结
引言
很多开发者刚开始做鸿蒙游戏时，都会觉得：
角色移动 怪物攻击 背包管理 任务系统不就是写几个对象、几个数组吗？例如：
letplayerHp=100letcoins=1000letcurrentMission="新手任务"项目初期似乎完全没问题。但是当游戏规模逐渐扩大以后，你会发现一个非常现实的问题：
数据越来越多 系统越来越多 模块越来越多最终整个项目开始变成：
Player.ts Monster.ts Mission.ts Bag.ts Skill.ts彼此互相引用、状态到处修改、Bug越来越难查。很多鸿蒙游戏项目后期出现的问题并不是：
性能不足而是：
状态失控而解决这个问题的核心，其实不是 UI，也不是 ArkUI。而是：
Store。
很多人把 Store 理解成：
状态管理工具但对于大型游戏来说：
Store 本质上是整个游戏 Runtime 的状态中心。
甚至可以说：
没有 Store 就没有真正意义上的游戏 Runtime今天我们就从架构角度聊聊：
Store ↓ Game Runtime ↓ World Runtime是如何一步步演化出来的。
一、为什么游戏一定会走向 Store？
先看最原始写法。
小游戏阶段
classPlayer{hp:number=100gold:number=1000}界面直接读取：
Text(`金币:${player.gold}`)看起来很简单。但很快就会出现：
背包系统 任务系统 商城系统 排行榜系统此时：
多个模块 同时修改同一份数据例如：
player.gold+=100你根本不知道：
谁修改的 什么时候修改的 为什么修改的于是项目开始进入混乱状态。
二、Store解决的到底是什么问题？
很多人认为：
Store = 状态存储其实不是。
Store真正解决的是：
状态流向即：
谁能修改状态？ 谁能读取状态？ 状态如何传播？例如：
玩家击败Boss会触发：
经验增加 金币增加 任务更新 成就更新 排行榜更新如果每个系统都直接修改数据：
PlayerSystem MissionSystem AchievementSystem互相耦合，最终会形成：
网状依赖而 Store 的核心思想是：
所有状态修改 统一入口例如：
store.dispatch({type:"ADD_GOLD",value:100})所有系统只关心：
事件而不是彼此，这就是解耦的开始。
三、游戏中的Store与前端Store有什么区别？
很多人学过：
Redux MobX Vuex于是认为：
游戏Store = 前端Store实际上差别非常大，前端Store管理：
页面状态例如：
登录状态 主题颜色 列表数据而游戏Store管理：
世界状态例如：
玩家 怪物 地图 任务 技能 经济系统规模完全不同，因此游戏中的 Store 更像：
World State而不是：
UI State四、游戏Runtime中的Store架构
在大型游戏项目中，Store通常位于整个 Runtime 的中心。
架构如下：
Store │ ┌─────────────┼─────────────┐ ▼ ▼ ▼ PlayerSystem MissionSystem BattleSystem ▼ ▼ ▼ ArkUI ArkUI ArkUI所有系统：
只读Store状态变更：
统一提交Store例如：
classGameStore{player:Player mission:Mission battle:BattleState}所有数据都集中管理。
五、Store如何驱动整个游戏世界？
这是最关键的问题，很多开发者认为：
Store存数据结束了，实际上：
Store驱动世界运行例如，玩家升级：
store.dispatch({type:"LEVEL_UP"})Store更新：
player.level++随后：
技能系统 任务系统 商城系统 成就系统全部收到通知。
LEVEL_UP成为：
世界事件整个游戏状态开始变化，所以真正的数据流是：
Action ↓ Store ↓ World Update ↓ Render而不是：
System A ↓ System B ↓ System C六、鸿蒙游戏中的Store实现
ArkTS本身已经具备，状态驱动的能力。例如：
@Stategold:number=100状态变化：
this.gold+=100界面自动刷新，但大型游戏不能把：
全局状态全部放在页面中，正确做法：
exportclassPlayerStore{@Observedplayer:Player={level:1,gold:1000}addGold(value:number){this.player.gold+=value}}统一管理，页面订阅：
@ObjectLinkplayerStore:PlayerStore这样：
状态变化 ↓ Store更新 ↓ UI刷新形成完整闭环。
七、Store拆分：大型项目最佳实践
很多项目后期会出现：
GameStore超过：
5000行最终变成：
上帝对象解决方案是：
Store Domain化例如：
PlayerStore MissionStore BattleStore BagStore MapStore每个领域单独管理，统一注册：
classRootStore{playerStore battleStore missionStore}形成 Root Store 架构，这也是目前大型项目主流方案。
八、AI时代Store正在升级为World Model
这里才是真正值得关注的地方，传统游戏：
Store管理的是：
数据而 AI 游戏：
Agent需要的是：
世界认知因此：
Store ↓ World State ↓ World Model开始演化。，例如：
interfaceWorldState{players:Player[]npcs:NPC[]regions:Region[]events:Event[]}Agent读取：
worldState而不是：
playerStore此时 Store 已经不是：
状态管理器而是：
数字世界模型九、未来游戏Runtime长什么样？
未来鸿蒙游戏很可能会形成如下架构：
World Model │ ┌────────────────┼────────────────┐ ▼ ▼ ▼ NPC Agent Quest Agent Story Agent │ ▼ Game Store │ ▼ Harmony Runtime │ Phone Pad PC TV Wearable这里，Store负责：
状态管理Agent负责：
行为决策Harmony Runtime负责：
跨设备同步最终构成：
World Runtime总结
很多开发者第一次接触 Store 时，认为它只是：
状态管理工具但当项目规模达到一定程度以后你会发现，Store决定的并不是：
数据怎么存而是：
游戏世界怎么运行从技术演进角度看：
变量 ↓ Store ↓ Root Store ↓ World State ↓ World Model这是游戏 Runtime 不断演化的过程，对于鸿蒙游戏开发而言。未来真正重要的或许已经不是：
如何设计一个页面。
而是：
如何设计一个能够驱动整个数字世界运行的 Store Runtime。
因为在 AI Agent 时代，Store 不再只是数据中心。它正在逐渐演化成：
游戏世界的大脑。
