HarmonyOS 游戏架构升级：从 Store 到 Runtime
大家好，我是 展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。
图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG
我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。
展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。
文章目录
引言
很多开发者学习 HarmonyOS 游戏开发时，都会经历三个阶段。
第一阶段，觉得 ArkUI 就是一切。
Button
Image
Column
Row
写几个组件，一个小游戏就出来了。
后来开始接触状态管理，于是发现：
Store
比 UI 更重要，所有数据都开始放进 Store。
项目瞬间清晰了很多。很多人到了这里就认为：
游戏架构已经设计完成了。
其实并没有。因为当项目继续扩大之后，你会发现新的问题又来了。
例如：
PhysicsSystem
AISystem
AnimationSystem
ParticleSystem
AudioSystem
NetworkSystem
这些 System 都需要运行。于是问题来了：
Store 谁来更新？
System 谁来调度？
AI 谁来执行？
Render 谁先谁后？
如果没有新的架构层。Store 很快又会变成：
新的 God Object（上帝类）
所以，大型游戏都会继续完成一次架构升级：
Store
↓
Runtime
今天，我们就来聊聊：
为什么现代 HarmonyOS 游戏，最终都会从 Store 走向 Runtime。
一、Store 为什么解决不了所有问题？
Store 的职责非常明确。例如：
export class GameStore {
playerHp = 100
enemyHp = 100
}
Store 保存：
状态（State）
例如：
玩家位置
敌人位置
金币数量
任务状态
它回答的是：
游戏世界现在是什么样子？
但是，它回答不了另一个问题：
游戏世界为什么会变成这样？
例如，玩家移动：
Player.x += 10
是谁改的？可能是：
输入系统
AI
技能系统
网络同步
Store 根本不知道。
因此 Store 应该保持纯粹。只负责：
State
而不是：
Logic
二、为什么越来越多逻辑不能放在 Store？
很多项目最后都会变成这样：
class GameStore {
move()
jump()
attack()
useSkill()
updatePhysics()
updateAnimation()
updateAI()
}
刚开始几十行代码；后来几百行；最后几千行。
Store：
既保存状态
又负责 AI
又负责物理
又负责网络
真正变成：
God Store
它违反了：
单一职责原则（SRP）
所以现代游戏越来越倾向于：
Store
+
System
Store：
保存状态
System：
修改状态
职责彻底分离。
三、System 出现以后，又为什么需要 Runtime？
当项目继续扩大，System 越来越多：
InputSystem
PhysicsSystem
BattleSystem
AnimationSystem
AudioSystem
ParticleSystem
新的问题马上来了。例如：
physics.update()
battle.update()
animation.update()
audio.update()
到底：
谁先执行？
谁后执行？
多久执行一次？
如果每个 System 自己：
setInterval()
Timer()
Thread()
整个项目马上失控。
于是 Runtime 出现了。它统一管理：
所有 System
而不是：
每个 System 管自己。
四、Runtime 到底升级了什么？
以前整个游戏：
UI
↓
Store
↓
UI
这是：
状态驱动
已经很好了，但是现代游戏真正运行方式是：
Runtime
↓
System
↓
Store
↓
ArkUI
可以看到 Store 已经不是最核心的一层。真正驱动整个游戏的是：
Runtime
Store 只是：
世界状态
五、Runtime 如何驱动整个游戏世界？
可以把 Runtime 理解成：
CPU
System 就是：
指令
Store 就是：
内存
ArkUI 就是：
显示器
整个调用流程：
Runtime.tick()
↓
PhysicsSystem.update()
↓
BattleSystem.update()
↓
Store 更新
↓
ArkUI 自动刷新
↓
RenderThread
↓
GPU
整个世界开始不断运行。而不是：
等待用户点击。
这就是：游戏和普通 App 最大区别。
六、Runtime 为什么比 Store 更重要？
因为 Store 只保存：
结果
例如：
HP = 80
但是 Runtime 决定：
为什么 HP 会变成 80。
例如：
玩家受到攻击
↓
Physics 检测碰撞
↓
BattleSystem 计算伤害
↓
Store.hp = 80
Store：不知道原因；Runtime：知道整个执行链。
因此现代引擎，真正核心都是：
Runtime
而不是：
Store
七、AI 时代，Runtime 的价值会越来越大
过去 NPC：
固定脚本
今天 NPC：
Planner
Memory
Tool
LLM
整个过程可能：
200ms
Render 只有：
16ms
如果 Render 等待 AI，整个游戏立即掉帧。
因此 Runtime 必须支持：
Task Queue
Worker Thread
Priority
Scheduler
例如：
Runtime
↓
AI Task
↓
后台线程
↓
Store
↓
ArkUI
Render 继续：
60FPS
AI 后台完成，这就是下一代 Runtime。
八、HarmonyOS 游戏推荐架构
最终，一个可扩展的 HarmonyOS 游戏架构可以设计为：
Game Loop
│
System Runtime
│
┌─────────────────┼─────────────────┐
│ │ │
Scheduler EventBus ResourceManager
│
┌────┼────┬────────┬─────────┬─────────┐
│ │ │ │ │ │
Input AI Physics Animation Battle Network
│
▼
Store
│
▼
ArkUI
│
▼
RenderThread
│
▼
GPU
在这个架构中：
- Store 是唯一状态源（Single Source of Truth），负责保存游戏世界的数据。
- System 负责业务规则，每个 System 聚焦单一职责，例如 Physics、AI、Battle、Animation。
- Runtime 负责统一调度所有 System，控制 Tick、执行顺序、生命周期以及任务优先级。
- ArkUI 只负责根据 Store 渲染界面，不直接参与业务逻辑。
- RenderThread 将渲染命令提交给 GPU，完成最终绘制。
整个数据流形成了清晰的单向链路：
Game Loop
│
System Runtime
│
Systems
│
Store
│
ArkUI
│
RenderThread
│
GPU
这种分层不仅让项目更容易维护，也为后续加入多线程、Agent、跨设备协同和高性能渲染打下基础。
总结
很多开发者在学习 HarmonyOS 游戏时，会认为：
有了 Store，架构就已经足够完善。
事实上，Store 只是解决了状态管理的问题。
随着游戏规模不断扩大，真正需要解决的是：
- 谁来驱动所有 System？
- 谁来统一管理 Tick？
- 谁来控制执行顺序？
- 谁来调度 AI、Physics、Animation 等多个模块？
答案就是 System Runtime。
整个架构的演进过程可以概括为：
UI 驱动
↓
Store 驱动
↓
System 驱动
↓
Runtime 驱动
可以看到，HarmonyOS 游戏开发已经从"页面开发"逐渐演变为"引擎开发"。
最后一句话总结：
Store 决定游戏世界"是什么"，而 Runtime 决定游戏世界"如何运转"。真正的大型 HarmonyOS 游戏，核心早已不是页面，而是 Runtime。
讨论HarmonyOS开发技术，专注于API与组件、DevEco Studio、测试、元服务和应用上架分发等。
更多推荐
14
0- 0
已为社区贡献151条内容
所有评论(0)