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

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

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

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

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

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

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

引言

很多 HarmonyOS 游戏开发者，第一次真正“被 Ability 重建教育”，往往是在某个凌晨。

你明明只是：

• 切了一下后台
• 打开了别的窗口
• 拖动了一个浮窗

结果回来一看：

• 场景重置了
• 状态没了
• 日志顺序对不上
• 初始化又跑了一遍

你盯着日志发呆：

“我这又没崩，系统为什么要重建我？”

答案只有一个：
因为在系统视角里，你已经不再值得继续占着资源了。

先换个视角：系统眼里的游戏 Ability 是什么？

在 HarmonyOS 里，游戏 Ability 并不是一个“必须常驻的进程”。

更准确的描述是：

一个可以被随时回收、并且要求你能安全重建的运行单元

这意味着，你写的代码必须默认这一点。

// 错误假设
class GameAbility {
  static instance: GameAbility

  onCreate() {
    GameAbility.instance = this
  }
}

这种代码的潜台词是：

“我只会被创建一次”

而在 HarmonyOS 上，这个假设迟早会害你。

Ability 重建不是瞬时行为，而是一条决策链

你在日志里看到的是：

onBackground
onStop
onDestroy
onCreate

但系统内部，经历的是完整的一轮评估流程。

第一阶段：系统评估 Ability 的“生存价值”

系统并不会因为你在跑游戏逻辑，就自动给你高优先级。

它看的，是这些硬条件：

• 是否可见
• 是否有焦点
• 是否占用关键资源
• 是否可以安全恢复

当这些条件不满足时，Ability 会被标记为：

“可被回收”

你在代码层面是感知不到这个标签的，但你能感知到结果。

onWindowStageInactive() {
  // 窗口失活，但不一定立刻销毁
}

这一步，不是异常，只是系统在“观察你”。

第二阶段：运行态冻结，而不是立刻销毁

很多开发者会发现一个奇怪现象：

• 画面停了
• 定时器不准了
• update 不再跑
• 但进程还在

这就是运行态冻结。

setInterval(() => {
  // 在冻结阶段，这段逻辑可能不会再被可靠触发
  updateGame()
}, 16)

重点在于：

HarmonyOS 并不保证后台或失焦状态下的调度连续性。

如果你把“游戏活着”理解成：

只要进程没死 = 状态还安全

那你已经踩雷了。

第三阶段：Ability 被销毁，但不是异常退出

最容易被误判

onDestroy() {
  //  不要在这里试图续命
  saveAllRuntimeState()
  keepProcessAlive()
}

在 HarmonyOS 的语义里：

• onDestroy ≠ 崩溃
• onDestroy ≠ 异常
• onDestroy ≠ 失败

它只是系统在说：

“你这一轮运行结束了。”

你真正该做的是：

onDestroy() {
  // 只做一件事：释放
  releaseAudio()
  releaseRenderer()
  clearTempState()
}

不要在这里保存“即时运行态”。

第四阶段：Ability 被重新创建，是一个全新的实例

当用户再次回到游戏时：

onCreate() {
  // 注意：这是一个全新的 Ability
  initGameShell()
}

这意味着：

• 所有内存态都不可信
• 所有单例都可能失效
• 所有资源句柄都必须重建

正确的恢复入口，应该是业务级别的。

onCreate() {
  const progress = loadProgress() // 关卡、章节、结算点
  restoreFromProgress(progress)
}

而不是：

//  错误示例
restoreAnimationFrame()
restoreInputState()
restorePhysicsStep()

为什么系统宁可重建，也不帮你“续着跑”？

因为续跑意味着：

• 半失效的上下文
• 不完整的输入
• 不确定的资源状态

而重建意味着：

• 干净的生命周期
• 明确的初始化路径
• 可验证的一致性

从系统角度看：

重建，是唯一安全的选择。

那开发者真正该做的是什么？

不是阻止 Ability 重建，而是主动为重建设计结构。

一个健康的运行态分层，应该长这样：

// 可丢弃
RuntimeState {
  inputBuffer
  animationProgress
  tempPhysicsData
}

// 可重建
SessionState {
  currentLevel
  playerHP
  inventory
}

// 持久态
PersistentState {
  saveSlot
  achievements
}

Ability 重建时：

• RuntimeState 全部丢弃
• SessionState 从存档恢复
• PersistentState 永远可信

一个关键的认知转变

如果你只记住一句话：

Ability 不是“活着的实体”，而是“可以反复生成的容器”。

那你在写：生命周期逻辑、状态保存、Bug 定位时，思路会彻底变。

写在最后

在 HarmonyOS 上：

Ability 重建不是事故现场，而是系统替你兜住了最危险的一步。

真正成熟的游戏运行态设计，不是要求系统：

“别动我”

而是对系统说：

“你随时可以重建我，我已经把该丢的都丢了，该留的都留在对的地方。”