鸿蒙游戏需要 GameEngine 吗？

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

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

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

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

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

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

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

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

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

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

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

持续写作，持续进阶。

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

文章目录

- 引言
- 一、先说结论
- [二、为什么很多人感觉"不需要 Engine"？](#二、为什么很多人感觉“不需要 Engine”？)
- [三、ArkUI 解决了什么？](#三、ArkUI 解决了什么？)
- [四、ArkUI 没解决什么？](#四、ArkUI 没解决什么？)
- 五、问题出现了
- [六、Engine 本质是什么？](#六、Engine 本质是什么？)
- [七、一个最简单的 Engine](#七、一个最简单的 Engine)
- [八、为什么 System 不应该互相调用？](#八、为什么 System 不应该互相调用？)
- [九、鸿蒙多端为什么更需要 Engine？](#九、鸿蒙多端为什么更需要 Engine？)
- [十、Engine 与 Store 的关系](#十、Engine 与 Store 的关系)
- - [Store 负责：](#Store 负责：)
  - [Engine 负责：](#Engine 负责：)
- [十一、Engine 与 ArkUI 的关系](#十一、Engine 与 ArkUI 的关系)
- 十二、一个真实项目的演化过程
- [十三、什么时候必须引入 Engine？](#十三、什么时候必须引入 Engine？)
- 总结

引言

当我们聊到游戏开发时，几乎绕不开一个词：

GameEngine（游戏引擎）

无论是 Unity、Unreal 还是 Cocos，背后都有一套完整的 Engine。

所以很多开发者刚开始做鸿蒙游戏时，也会自然产生一个问题：

鸿蒙游戏需要自己做一个 GameEngine 吗？

尤其是当你已经写出：

text 复制代码

Store
System
UI

之后，很容易继续往下想：

text 复制代码

是不是还差一个 Engine？

答案其实很有意思：

小型游戏不一定需要 Engine，但大型游戏一定会逐渐演化出 Engine。

而且这里的 Engine，和 Unity 的 Engine 还不是一回事。

我们就聊清楚：

鸿蒙游戏到底需不需要 GameEngine？

一、先说结论

对于鸿蒙游戏：

小项目

text 复制代码

Store + System + UI

已经够用。

中型项目

text 复制代码

Store + System + Engine + UI

开始有价值。

大型项目

text 复制代码

Engine 成为核心

甚至：

整个游戏最终都会围绕 Engine 运转。

二、为什么很多人感觉"不需要 Engine"？

因为 ArkUI 天然帮你做了很多事情，比如：

ts 复制代码

@State hp = 100

状态变化：

ts 复制代码

hp -= 10

UI 自动刷新，你不需要：

text 复制代码

Render Loop
Scene Manager
UI Renderer

这些传统引擎里的东西，所以很多人会觉得：

ArkUI 已经是引擎了。

这句话：

text 复制代码

对一半
错一半

三、ArkUI 解决了什么？

ArkUI 解决的是：

text 复制代码

UI 渲染
状态更新
组件生命周期

比如：

ts 复制代码

Text(`${store.hp}`)

你不需要：

ts 复制代码

render()
refresh()
draw()

所以：

text 复制代码

UI Engine

ArkUI 已经帮你做好了。

四、ArkUI 没解决什么？

真正的游戏复杂度不在 UI，而在：

text 复制代码

规则执行
系统调度
事件流转
状态同步

例如：

text 复制代码

战斗系统
掉落系统
AI 系统
Buff 系统
任务系统

这些：

ArkUI 完全不会帮你处理。

于是你会开始写：

ts 复制代码

battleSystem.update()

然后：

ts 复制代码

levelSystem.update()

接着：

ts 复制代码

dropSystem.update()

慢慢地：

text 复制代码

System 越来越多

五、问题出现了

假设你已经有：

text 复制代码

BattleSystem
AISystem
DropSystem
LevelSystem
BuffSystem

现在有个问题：

谁先执行？

比如：

text 复制代码

AI 攻击
↓
玩家死亡
↓
掉落奖励
↓
经验增加

顺序错一点：

text 复制代码

经验先加
再死亡

结果完全不同。

于是：

你需要一个统一调度者。

这就是 Engine 的雏形。

六、Engine 本质是什么？

很多人以为：

text 复制代码

Engine = 渲染引擎

其实不是，对于鸿蒙游戏：

Engine 更像"游戏世界调度中心"

职责通常包括：

text 复制代码

System 调度
事件派发
生命周期管理
状态同步

结构：

text 复制代码

Engine
 ├── BattleSystem
 ├── AISystem
 ├── DropSystem
 ├── BuffSystem
 └── LevelSystem

七、一个最简单的 Engine

例如：

ts 复制代码

class GameEngine {

  systems = []

  addSystem(system) {
    this.systems.push(system)
  }

  update(store) {
    this.systems.forEach(system => {
      system.update(store)
    })
  }

}

启动：

ts 复制代码

const engine = new GameEngine()

engine.addSystem(new BattleSystem())
engine.addSystem(new AISystem())
engine.addSystem(new DropSystem())

循环：

ts 复制代码

setInterval(() => {
  engine.update(store)
}, 16)

此时：

text 复制代码

Engine 开始接管整个游戏

八、为什么 System 不应该互相调用？

这是很多项目后期崩掉的原因，例如：

ts 复制代码

BattleSystem
  ↓
调用
  ↓
DropSystem

然后：

ts 复制代码

DropSystem
  ↓
调用
  ↓
LevelSystem

最后：

text 复制代码

依赖网状爆炸

正确方式：

text 复制代码

System 不互相认识

全部交给：

text 复制代码

Engine 调度

结构：

text 复制代码

Battle
   ↑
Engine
   ↓
Drop

而不是：

text 复制代码

Battle → Drop

九、鸿蒙多端为什么更需要 Engine？

在一下子设备同时进行时：

text 复制代码

手机
平板
TV

这时候：

text 复制代码

事件同步
状态同步
顺序同步

都需要统一入口，例如：

text 复制代码

手机点击攻击

事件进入：

text 复制代码

Engine

然后：

text 复制代码

Engine
 ↓
BattleSystem
 ↓
Store
 ↓
同步到其他设备

所以：

多端游戏实际上比单端更依赖 Engine。

十、Engine 与 Store 的关系

很多人会混淆。

Store 负责：

text 复制代码

保存状态

例如：

ts 复制代码

playerHp
enemyHp
gold
exp

Engine 负责：

text 复制代码

改变状态

例如：

text 复制代码

攻击
升级
掉落
同步

关系：

text 复制代码

Store = 世界数据

Engine = 世界规则

十一、Engine 与 ArkUI 的关系

这也是关键，很多人会写成：

text 复制代码

UI
 ↓
System
 ↓
Store

导致：

text 复制代码

UI 成为控制中心

正确结构：

text 复制代码

Engine
 ↓
System
 ↓
Store
 ↓
ArkUI

ArkUI 只负责：

text 复制代码

显示结果

不负责：

text 复制代码

业务规则

十二、一个真实项目的演化过程

大部分鸿蒙游戏都会经历：

第一阶段

text 复制代码

ArkUI 页面

第二阶段

text 复制代码

Store

第三阶段

text 复制代码

System

第四阶段

text 复制代码

Engine

第五阶段

text 复制代码

事件驱动 Engine

第六阶段

text 复制代码

分布式 Engine

支持：

text 复制代码

手机
平板
TV

同步运行。

十三、什么时候必须引入 Engine？

有一个简单标准，如果你的项目出现：

text 复制代码

超过 3 个 System

或者：

text 复制代码

开始出现执行顺序问题

或者：

text 复制代码

需要跨设备同步

那么：

Engine 已经不是优化项，而是必需品。

总结

鸿蒙游戏需要 GameEngine 吗？答案是：

text 复制代码

简单游戏：
不一定需要

复杂游戏：
一定会需要

但这里的 Engine 不是传统意义上的渲染引擎，它更像：

text 复制代码

游戏世界调度器

负责：

text 复制代码

System 调度
事件流转
状态同步
生命周期管理

最终形成这样一个架构：

text 复制代码

Engine
   ↓
System
   ↓
Store
   ↓
ArkUI

最后一句话：

在鸿蒙游戏里，ArkUI 负责"看见世界"，Store 负责"记录世界"，而 Engine 负责"推动世界运转"。