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

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

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

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

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

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

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

引言

如果你有传统游戏开发经验，你几乎会本能写出这段代码：

while (true) {
  update()
  render()
}

或者在前端里：

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

你会觉得：

这就是游戏的“心跳”

但当你把这套写法搬到鸿蒙（尤其是 ArkUI）里，很快会出现各种问题：

UI 不稳定
性能波动
状态更新异常
多端不同步

于是你开始怀疑：

是不是我哪里写错了？

其实不是。

问题在于：鸿蒙游戏，本来就不应该用传统 Game Loop

一、传统 Game Loop 在解决什么问题？

在 Unity、Unreal Engine 这类引擎中，Game Loop 的核心作用是：

控制时间
驱动逻辑
触发渲染

结构是：

输入 → update → render → 下一帧

关键点：

开发者必须“主动推动世界运行”

二、鸿蒙里，这个前提已经不存在了

在鸿蒙 + ArkUI 中：

UI 是声明式的
渲染由系统驱动
状态变化自动触发 UI 更新

也就是说：

错误 你不再需要调用 render()
错误 你不再控制帧刷新

系统已经帮你做了：

调度
合并更新
渲染优化

三、Game Loop 在鸿蒙中会产生什么问题？

1、双重调度冲突

你写：

setInterval(update, 16)

系统内部也在做：

UI 调度 + 渲染调度

结果：

两个“时钟”同时驱动系统

表现为：

卡顿
抖动
不一致

2、状态更新被“合并”或“丢弃”

store.hp -= 1 // 每帧执行

但 ArkUI 可能会：

合并多次更新
只渲染一次

结果：

逻辑执行 60 次
UI 只更新 20 次

3、性能浪费

即使没有变化
你也在不停 update()

这在鸿蒙里是反模式：

没有状态变化，就不应该有计算

4、多端同步彻底失控

手机 60fps
平板 90fps
TV 30fps

如果每个设备都有自己的 Game Loop：

状态一定漂移

四、一个关键认知：鸿蒙不是“帧驱动”，而是“状态驱动”

你必须完成这个转变：

传统思维

每一帧：
  更新世界

鸿蒙思维

当状态变化：
  更新世界

一句话总结：

没有变化，就不执行

五、正确模型：System 驱动，而不是 Loop 驱动

在鸿蒙游戏中，真正的驱动核心是：

System

而不是：

Game Loop

示例

onUserInput(() => {
  battleSystem.attack(store)
})

onAIEvent(() => {
  aiSystem.decide(store)
})

系统变成：

事件 → System → 状态变化 → UI 更新

六、那“时间驱动”的逻辑怎么办？

有些逻辑确实需要“时间”：

冷却
持续伤害
动画

这时候你不需要 Game Loop，而是：

“时间事件”

setTimeout(() => {
  skillSystem.cooldownEnd(store)
}, 3000)

“调度器”

scheduler.schedule({
  delay: 1000,
  action: () => damageSystem.tick(store)
})

关键点：

用“离散时间事件”，代替“连续帧循环”

七、进阶方案：轻量 Tick（但不是 Loop）

在某些情况下（比如挂机、战斗推进），你可以使用：

setInterval(() => {
  engine.tick(store)
}, 500)

但注意：

这是“低频逻辑推进”
不是“帧循环”

八、为什么鸿蒙更适合这种模式？

因为 ArkUI 的设计本质是：

响应式
声明式
状态驱动

它优化的是：

变化

而不是：

帧

九、一个更深层的理解

传统 Game Loop 是：

“时间驱动模拟世界”

而鸿蒙 System 架构是：

“规则驱动状态变化”

对比一下：

传统

时间 → 推动变化

鸿蒙

变化 → 触发更新

十、开发者最常见误区

误区 1：强行 60fps

setInterval(..., 16)

结果：

性能差
不稳定
无收益

误区 2：用帧推进业务

hp -= 1 // 每帧扣血

问题：

不可控
不同步
难调试

误区 3：把 Loop 当核心

结果：

忽略 System
忽略状态
架构混乱

十一、一个终极认知

当你真正理解这一点之后，你会发现你写的系统，本质是：

一个“事件 + 状态”的响应系统

而不是：

一个“帧循环驱动系统”

总结

鸿蒙游戏不能用传统 Game Loop 的原因只有一个：

因为它根本不需要你来驱动“帧”

正确模式是：

事件（输入 / AI / 时间）
        ↓
System（规则执行）
        ↓
Store（状态变化）
        ↓
ArkUI（自动渲染）

如果用一句话总结：

在鸿蒙里，世界不是“每一帧被推动”，而是“在变化时被重构”。