企业官网建设流程全解析

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

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

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

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

子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”

持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱

引言

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

GameEngine（游戏引擎）

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

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

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

尤其是当你已经写出：

Store System UI

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

是不是还差一个 Engine？

答案其实很有意思：

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

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

我们就聊清楚：

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

一、先说结论

对于鸿蒙游戏：

小项目

Store + System + UI

已经够用。

中型项目

Store + System + Engine + UI

开始有价值。

大型项目

Engine 成为核心

甚至：

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

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

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

@Statehp=100

状态变化：

hp-=10

UI 自动刷新，你不需要：

Render Loop Scene Manager UI Renderer

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

ArkUI 已经是引擎了。

这句话：

对一半 错一半

三、ArkUI 解决了什么？

ArkUI 解决的是：

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

比如：

Text(`${store.hp}`)

你不需要：

render()refresh()draw()

所以：

UI Engine

ArkUI 已经帮你做好了。

四、ArkUI 没解决什么？

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

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

例如：

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

这些：

ArkUI 完全不会帮你处理。

于是你会开始写：

battleSystem.update()

然后：

levelSystem.update()

接着：

dropSystem.update()

慢慢地：

System 越来越多

五、问题出现了

假设你已经有：

BattleSystem AISystem DropSystem LevelSystem BuffSystem

现在有个问题：

谁先执行？

比如：

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

顺序错一点：

经验先加 再死亡

结果完全不同。

于是：

你需要一个统一调度者。

这就是 Engine 的雏形。

六、Engine 本质是什么？

很多人以为：

Engine = 渲染引擎

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

Engine 更像“游戏世界调度中心”

职责通常包括：

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

结构：

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

七、一个最简单的 Engine

例如：

classGameEngine{systems=[]addSystem(system){this.systems.push(system)}update(store){this.systems.forEach(system=>{system.update(store)})}}

启动：

constengine=newGameEngine()engine.addSystem(newBattleSystem())engine.addSystem(newAISystem())engine.addSystem(newDropSystem())

循环：

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

此时：

Engine 开始接管整个游戏

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

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

BattleSystem ↓ 调用 ↓ DropSystem

然后：

DropSystem ↓ 调用 ↓ LevelSystem

最后：

依赖网状爆炸

正确方式：

System 不互相认识

全部交给：

Engine 调度

结构：

Battle ↑ Engine ↓ Drop

而不是：

Battle → Drop

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

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

手机 平板 TV

这时候：

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

都需要统一入口，例如：

手机点击攻击

事件进入：

Engine

然后：

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

所以：

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

十、Engine 与 Store 的关系

很多人会混淆。

Store 负责：

保存状态

例如：

playerHp enemyHp gold exp

Engine 负责：

改变状态

例如：

攻击 升级 掉落 同步

关系：

Store = 世界数据 Engine = 世界规则

十一、Engine 与 ArkUI 的关系

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

UI ↓ System ↓ Store

导致：

UI 成为控制中心

正确结构：

Engine ↓ System ↓ Store ↓ ArkUI

ArkUI 只负责：

显示结果

不负责：

业务规则

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

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

第一阶段

ArkUI 页面

第二阶段

Store

第三阶段

System

第四阶段

Engine

第五阶段

事件驱动 Engine

第六阶段

分布式 Engine

支持：

手机 平板 TV

同步运行。

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

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

超过 3 个 System

或者：

开始出现执行顺序问题

或者：

需要跨设备同步

那么：

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

总结

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

简单游戏： 不一定需要 复杂游戏： 一定会需要

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

游戏世界调度器

负责：

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

最终形成这样一个架构：

Engine ↓ System ↓ Store ↓ ArkUI

最后一句话：

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