网罗开发小红书、快手、视频号同名大家好我是展菲目前在上市企业从事人工智能项目研发管理工作平时热衷于分享各种编程领域的软硬技能知识以及前沿技术包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。图书作者《ESP32-C3 物联网工程开发实战》图书作者《SwiftUI 入门进阶与实战》超级个体COC上海社区主理人特约讲师大学讲师谷歌亚马逊分享嘉宾科技博主华为HDE/HDG我的博客内容涵盖广泛主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告同时也会提供产品优缺点分析、横向对比并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。展菲您的前沿技术领航员 大家好我是展菲 全网搜索“展菲”即可纵览我在各大平台的知识足迹。每周定时推送干货满满的技术长文从新兴框架的剖析到运维实战的复盘助您技术进阶之路畅通无阻。文章目录引言一、Store 为什么解决不了所有问题二、为什么越来越多逻辑不能放在 Store三、System 出现以后又为什么需要 Runtime四、Runtime 到底升级了什么五、Runtime 如何驱动整个游戏世界六、Runtime 为什么比 Store 更重要七、AI 时代Runtime 的价值会越来越大八、HarmonyOS 游戏推荐架构总结引言很多开发者学习 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 的职责非常明确。例如exportclassGameStore{playerHp100enemyHp100}Store 保存状态State例如玩家位置 敌人位置 金币数量 任务状态它回答的是游戏世界现在是什么样子但是它回答不了另一个问题游戏世界为什么会变成这样例如玩家移动Player.x 10是谁改的可能是输入系统 AI 技能系统 网络同步Store 根本不知道。因此 Store 应该保持纯粹。只负责State而不是Logic二、为什么越来越多逻辑不能放在 Store很多项目最后都会变成这样classGameStore{move()jump()attack()useSkill()updatePhysics()updateAnimation()updateAI()}刚开始几十行代码后来几百行最后几千行。Store既保存状态 又负责 AI 又负责物理 又负责网络真正变成God Store它违反了单一职责原则SRP所以现代游戏越来越倾向于Store SystemStore保存状态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 已经不是最核心的一层。真正驱动整个游戏的是RuntimeStore 只是世界状态五、Runtime 如何驱动整个游戏世界可以把 Runtime 理解成CPUSystem 就是指令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 80Store不知道原因Runtime知道整个执行链。因此现代引擎真正核心都是Runtime而不是Store七、AI 时代Runtime 的价值会越来越大过去 NPC固定脚本今天 NPCPlanner Memory Tool LLM整个过程可能200msRender 只有16ms如果 Render 等待 AI整个游戏立即掉帧。因此 Runtime 必须支持Task Queue Worker Thread Priority Scheduler例如Runtime ↓ AI Task ↓ 后台线程 ↓ Store ↓ ArkUIRender 继续60FPSAI 后台完成这就是下一代 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。