网罗开发 （小红书、快手、视频号同名）

  大家好，我是 展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

引言

很多开发者第一次开发 HarmonyOS 游戏时，都会觉得整个项目其实很简单。

一个按钮：

Button("攻击")
  .onClick(() => {
    store.attackEnemy()
  })

一次状态更新：

store.enemyHp -= 10

ArkUI 自动刷新页面，整个流程结束。

于是很多 Demo 都是这样写出来的。

但是，当项目逐渐从 Demo 变成真正的游戏时，你会发现代码开始发生变化。

项目里面不断出现新的 System：

PhysicsSystem
AISystem
BattleSystem
AnimationSystem
ParticleSystem
AudioSystem
NetworkSystem

每个 System 都拥有自己的 update()。例如：

physics.update()

ai.update()

battle.update()

animation.update()

particle.update()

新的问题马上出现：

谁先执行？

谁后执行？

多久执行一次？

多个 System 如何通信？

如何保证状态一致？

很多开发者把这些逻辑全部写进 Store，或者全部塞进 GamePage。

结果就是：

页面越来越大

System 越来越多

调用关系越来越乱

真正的问题，并不是 System 太多。而是：

整个游戏缺少一个真正的运行时（System Runtime）。

它不是一个工具类，也不是一个普通的 Manager。而是：

整个游戏引擎真正的内核（Runtime Kernel）。

一、为什么现代游戏一定需要 Runtime？

先来看一个没有 Runtime 的项目，很多人都会这样写：

setInterval(() => {
    physics.update()
}, 16)

setInterval(() => {
    ai.update()
}, 16)

setInterval(() => {
    animation.update()
}, 16)

setInterval(() => {
    particle.update()
}, 16)

网络同步：

setInterval(() => {
    network.sync()
}, 100)

技能：

setInterval(() => {
    skill.update()
}, 16)

随着功能增加：

几十个 Timer

几十个 update()

几十个事件入口

整个项目最后变成：

AI 调 Physics

Physics 调 Animation

Animation 调 UI

UI 再通知 Store

最终：

执行顺序不可控

重复计算

状态竞争

CPU 开销越来越高

问题不是 Timer，真正的问题是：

没有统一调度所有 System。

现代游戏都会有一个 Runtime。负责统一管理：

所有 System

所有 Tick

所有生命周期

二、Runtime 本质不是循环，而是 Scheduler

很多教程都会写这样一段代码：

while (true) {

    update();

    render();

}

很多人认为：

这就是 Runtime。

实际上不是，这只是：

Game Loop

真正的 Runtime 长这样：

                 Runtime
                    │
              Scheduler
                    │
 ┌──────────┬──────────┬──────────┐
 │          │          │          │
Physics     AI     Animation   Audio

Runtime 最重要的职责不是：

不停循环

而是：

任务调度（Task Scheduling）

它需要决定：

哪些任务本帧执行？

哪些任务后台执行？

哪些任务可以并行？

哪些任务需要等待？

所以：

Game Loop 只是 Runtime 的入口，而 Scheduler 才是 Runtime 的核心。

三、Game Loop 如何驱动 Runtime？

整个游戏每一帧都会收到一次 VSync 信号，形成：

Display

↓

VSync

↓

Game Loop

↓

Runtime.tick()

真正开始工作的，是 Runtime。例如：

export class SystemRuntime {

    tick(deltaTime: number) {

        scheduler.run(deltaTime)

    }

}

Scheduler 再去执行所有 System。例如：

scheduler.run() {

    physics.update()

    ai.update()

    battle.update()

    animation.update()

    particle.update()

}

所以：

GameLoop
      ↓
Runtime
      ↓
Scheduler
      ↓
Systems

真正驱动整个游戏世界的，不是 Game Loop，而是 Runtime。

四、为什么 System 必须按照固定顺序执行？

很多开发者容易忽略这一点。System 的执行顺序，本身就是游戏逻辑的一部分。

推荐顺序：

Input

↓

AI

↓

Physics

↓

Animation

↓

Particle

↓

Audio

↓

Render

为什么？例如，AI：

决定下一步移动

Physics：

计算新的坐标

Animation：

播放新的动作

Render：

把最新状态绘制出来

如果 Render 提前执行：

Render

↓

Physics

那么，屏幕显示的永远都是：

上一帧的位置

表现出来就是：

人物抖动

动作延迟

碰撞错位

因此，Runtime 最大的职责之一，就是保证：

Execution Order（执行顺序）

永远正确。

五、System 生命周期应该如何设计？

真正的 Runtime，不仅管理 update。还应该管理生命周期。

建议统一接口：

export interface GameSystem {

    onInit(): void

    onStart(): void

    update(deltaTime: number): void

    onPause(): void

    onResume(): void

    onDestroy(): void

}

Runtime：

runtime.register(new PhysicsSystem())

runtime.register(new AISystem())

runtime.register(new BattleSystem())

启动：

runtime.start()

Runtime：

onInit()

↓

onStart()

↓

update()

↓

onPause()

↓

onResume()

↓

onDestroy()

以后增加任何新的 System。无需修改 Runtime，真正做到：

开放扩展

关闭修改

六、Runtime 如何管理不同频率的任务？

并不是所有 System 都需要 60FPS。

例如，Render：

60FPS

Physics：

60FPS

Particle：

60FPS

但是 AI：

10FPS

网络同步：

5FPS

天气系统：

1FPS

如果全部：

60FPS

CPU 将浪费大量资源，因此 Runtime 应该支持：

runtime.register(aiSystem, 100)

runtime.register(networkSystem, 200)

runtime.register(weatherSystem, 1000)

表示：

100ms

200ms

1000ms

执行一次，Runtime 自动完成调度。

这也是现代游戏降低 CPU 占用的重要方式。

七、为什么 AI 时代更需要 Runtime？

传统 NPC：

Behavior Tree

↓

Move()

几十微秒即可完成，但是 AI Agent 完全不同。

一次完整流程可能是：

观察环境

↓

Planner

↓

Memory

↓

Tool

↓

生成行为

↓

更新状态

整个过程：

100~500ms

而 Render：

16.67ms

如果：

Render

等待

Agent

那么 FPS：

60

↓

10

整个游戏都会卡住，正确做法是：

Runtime

↓

Task Queue

↓

Worker Thread

↓

Agent Runtime

↓

Store

Render 继续：

16ms

16ms

16ms

AI 后台慢慢完成，最后：

Agent

↓

Store

↓

ArkUI

UI 自动更新，整个游戏仍然保持：

60FPS

所以：

AI 必须成为 Runtime 调度的一部分，而不能直接运行在 UI 或主线程。

八、Runtime 如何与 ArkUI 协同工作？

很多开发者认为：

Runtime

↓

直接修改 UI

实际上，这是错误的设计。推荐的数据流应该是：

Runtime

↓

System

↓

Store

↓

ArkUI

↓

RenderThread

↓

GPU

例如 Physics：

store.player.position = nextPosition

ArkUI：

Player({
    x: store.player.position.x,
    y: store.player.position.y
})

整个过程中：Runtime 不关心 UI、ArkUI 不关心 Physics。两者通过 Store 解耦。

形成真正的：

状态驱动 UI

这也是 HarmonyOS 游戏最推荐的架构。

九、HarmonyOS 游戏 Runtime 推荐架构

当项目逐渐变大之后，可以按照下面的方式组织：

                  Game Loop
                      │
               System Runtime
                      │
        ┌─────────────┼─────────────┐
        │             │             │
   Scheduler      EventBus     ResourceMgr
        │
 ┌──────┼──────────┬───────────┐
 │      │          │           │
Input Physics   AI System  Animation
 │      │          │           │
 └──────┴──────────┴───────────┘
                │
              Store
                │
              ArkUI
                │
          RenderThread
                │
               GPU

其中：

Scheduler 负责：

任务调度

Tick 管理

优先级控制

EventBus 负责：

System 通信

消息派发

事件广播

ResourceManager 负责：

纹理

模型

音频

缓存

整个 Runtime 成为真正意义上的：

游戏引擎内核

十、AI 时代的 Runtime，将越来越像一个操作系统

过去的 Runtime：

Update()

↓

Render()

未来的 Runtime：

Task Scheduler

↓

Job Queue

↓

Worker Thread

↓

Agent Runtime

↓

Resource Manager

↓

Store

↓

ArkUI

它负责的不再只是：

Tick

而是：

多线程调度

资源管理

生命周期管理

AI 推理调度

跨设备状态同步

事件派发

对于 HarmonyOS 来说，还可以进一步结合：

手机

PC

平板

智慧屏

统一驱动：

分布式状态

跨设备输入

多端渲染

AI Agent

未来的 Runtime，更像是整个游戏世界的"操作系统"。

总结

很多开发者认为：

游戏循环就是一个 update()。

实际上，在现代游戏引擎中，真正驱动整个游戏世界的，并不是某一个 update() 方法，而是 System Runtime。

它不仅负责 Tick 驱动，更负责整个引擎的任务调度、生命周期管理、执行顺序控制以及多线程协同。

整个调用链可以总结为：

Game Loop
      │
System Runtime
      │
 Scheduler
      │
 Systems
      │
   Store
      │
   ArkUI
      │
RenderThread
      │
    GPU

可以看到，Runtime 位于整个架构的中心，它向上连接 Game Loop，向下连接 Store、ArkUI 与 RenderThread，同时横向协调 Physics、AI、Animation、Audio 等所有 System。

最后一句话总结：

在 AI 时代，System Runtime 已经不只是一个游戏循环，而是整个 HarmonyOS 游戏引擎的调度内核。它决定了游戏世界如何运行、AI 如何协同、RenderThread 如何高效工作，也是游戏从"页面开发"迈向"引擎开发"最关键的一步。