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

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

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

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

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

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

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

“假异步”到底假在哪里？

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

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

开发者的心理预期是：

我把重活丢到 setTimeout 里了，
主线程可以先去跑一帧渲染。

但现实是：

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

setTimeout ≠ 后台线程

在 HarmonyOS（包括 ArkTS Runtime）里：

• setTimeout
• Promise.then
• async / await

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

它们的共同点是：

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

这就意味着：

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

如果这一坨逻辑：

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

结果只有一个：掉帧

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

初始化阶段的“异步切片”

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

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

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

如果 initAI() 内部是：

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

那么：

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

只是你现在：

• 更晚卡
• 卡得更“突然”

逻辑线程假象

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

gameLoop() {
  updateLogicAsync()
  renderFrame()
}

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

从代码结构上看：

• renderFrame() 先执行
• 逻辑更新是“异步的”

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

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

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

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

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

因为游戏有三个特点：

主线程是刚性资源

• UI
• 输入
• 渲染提交
• 帧同步

全部绑定在主线程。

不像普通 App：

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

游戏里：

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

游戏逻辑具有“帧级耦合”

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

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

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

结果就是：

一旦你把这些逻辑
通过“假异步”推迟
它们会在某一帧集中爆发

Debug / Profile 下尤为明显

在 Debug / Profile 模式：

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

所以你会看到：

Debug 很卡
Release 好像还能跑

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

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

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

先说结论：

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

方式一：Worker / TaskPool

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

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

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

这里才是关键点：

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

完全脱离主线程执行

方式二：帧内预算切片

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

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

  while (hasMoreAI()) {
    processNextAI()

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

然后在每一帧：

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

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

总结

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

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

一句话总结这篇：

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