HarmonyOS 游戏里的“假异步”，为什么会卡

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

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

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

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

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

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

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

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

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

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

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

持续写作，持续进阶。

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

文章目录

- "假异步"到底假在哪里？
- - [setTimeout ≠ 后台线程](#setTimeout ≠ 后台线程)
- 游戏里最常见的"假异步"场景
- - 初始化阶段的"异步切片"
  - 逻辑线程假象
- 为什么"假异步"在游戏里特别致命？
- - 主线程是刚性资源
  - 游戏逻辑具有"帧级耦合"
  - [Debug / Profile 下尤为明显](#Debug / Profile 下尤为明显)
- 真正的异步，游戏里该怎么做？
- - [方式一：Worker / TaskPool](#方式一：Worker / TaskPool)
  - 方式二：帧内预算切片
- 总结

"假异步"到底假在哪里？

先说一个很多 HarmonyOS 游戏里真实存在的写法。

ts 复制代码

// ArkTS
function loadLevelAsync() {
  setTimeout(() => {
    loadMap();
    initEnemies();
    preparePathFinding();
  }, 0)
}

开发者的心理预期是：

我把重活丢到 setTimeout 里了，

主线程可以先去跑一帧渲染。

但现实是：

你只是把工作推迟了一点点，
但它依然在同一个主线程上执行。

setTimeout ≠ 后台线程

在 HarmonyOS（包括 ArkTS Runtime）里：

setTimeout
Promise.then
async / await

都只是事件循环层面的调度。

它们的共同点是：

回调依然在 UI / 主线程执行。

这就意味着：

当前帧结束后
下一次事件循环开始
这堆"异步逻辑"会一次性砸回主线程

如果这一坨逻辑：

超过 16ms
或者和下一帧渲染挤在一起

结果只有一个：掉帧

游戏里最常见的"假异步"场景

初始化阶段的"异步切片"

ts 复制代码

async function initGame() {
  await loadAssets()
  await initMap()
  await initNPC()
  await initAI()
}

代码看起来非常优雅，问题在于：

await 不会拆分计算
它只是在 等待 Promise resolve

如果 initAI() 内部是：

ts 复制代码

function initAI() {
  for (let i = 0; i < 5000; i++) {
    buildNavGraph(i)
  }
}

那么：

这一整段逻辑，还是一次性跑在主线程。

只是你现在：

更晚卡
卡得更"突然"

逻辑线程假象

很多游戏会写类似这种代码：

ts 复制代码

gameLoop() {
  updateLogicAsync()
  renderFrame()
}

ts 复制代码

function updateLogicAsync() {
  Promise.resolve().then(() => {
    updatePhysics()
    updateAI()
    updateBuffs()
  })
}

从代码结构上看：

renderFrame() 先执行
逻辑更新是"异步的"

但在一帧内，真实顺序是：

当前调用栈跑完
UI 渲染准备
microtask queue 执行
逻辑更新插队执行
下一帧被挤爆

所以你会看到一个非常典型的现象：

帧不是均匀掉的，而是隔几帧突然爆红

为什么"假异步"在游戏里特别致命？

因为游戏有三个特点：

主线程是刚性资源

UI
输入
渲染提交
帧同步

全部绑定在主线程。

不像普通 App：

卡 30ms 用户只是觉得"慢一点"

游戏里：

卡 30ms = 掉一帧 = 操作延迟

游戏逻辑具有"帧级耦合"

很多逻辑必须在同一帧完成：

碰撞检测
技能判定
状态机流转

你无法像业务 App 一样随意拆散。

结果就是：

一旦你把这些逻辑

通过"假异步"推迟

它们会在某一帧集中爆发

Debug / Profile 下尤为明显

在 Debug / Profile 模式：

事件循环更"诚实"
调度抖动更明显
主线程耗时不会被隐藏

所以你会看到：

Debug 很卡

Release 好像还能跑

但这不是问题消失了，而是：

Release 帮你把问题压到了临界点

真正的异步，游戏里该怎么做？

先说结论：

不是所有"异步"都能解决卡顿，
只有"跨线程"的异步才算数。

方式一：Worker / TaskPool

ts 复制代码

// 主线程
const worker = new worker.Worker("logicWorker.ts")

worker.postMessage({
  type: 'initAI',
  data: mapData
})

ts 复制代码

// logicWorker.ts
self.onmessage = (e) => {
  if (e.data.type === 'initAI') {
    const result = buildNavMesh(e.data.data)
    self.postMessage(result)
  }
}

这里才是关键点：

AI 构图
路径预计算
数据解析

完全脱离主线程执行

方式二：帧内预算切片

有些逻辑必须在主线程，那就别想着"异步逃避"，而是：

ts 复制代码

function updateAIWithBudget(budgetMs: number) {
  const start = Date.now()

  while (hasMoreAI()) {
    processNextAI()

    if (Date.now() - start > budgetMs) {
      break
    }
  }
}

然后在每一帧：

ts 复制代码

onFrame() {
  updateAIWithBudget(3) // 只用 3ms
  render()
}

这才是游戏工程里真正可控的写法。

总结

"假异步"最危险的地方不在于它慢，而在于它：

给你一种已经优化过的错觉
把问题推迟到某一帧集中爆发
让卡顿变得不可预测

一句话总结这篇：

HarmonyOS 游戏里，
用事件循环做异步，
本质是在和主线程对赌。