HarmonyOS 为何用 Ability 约束游戏？

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

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

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

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

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

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

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

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

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

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

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

持续写作，持续进阶。

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

文章目录

- 引言
- 一个很容易误判的前提
- [Activity 的隐含假设](#Activity 的隐含假设)
- [但 HarmonyOS 面对的世界不一样了](#但 HarmonyOS 面对的世界不一样了)
- [Ability 的第一层约束：运行权不等于可见性](#Ability 的第一层约束：运行权不等于可见性)
- - [Ability 直接拆掉了这个等式](#Ability 直接拆掉了这个等式)
- 第二层约束：把"长期运行"变成一种能力申请
- - 这不是刁难，是系统建模
- 第三层约束：生命周期被拆成"阶段"，不是"回调"
- - 错误用法：在生命周期里堆逻辑
  - 正确理解：生命周期只做"状态切换"
- [第四层约束：Ability 不鼓励"页面即世界"](#第四层约束：Ability 不鼓励“页面即世界”)
- - [Ability 明确反对这种设计](#Ability 明确反对这种设计)
- [正确姿势：世界模型独立于 Ability](#正确姿势：世界模型独立于 Ability)
- 为什么这些约束，偏偏对游戏这么狠？
- 一个开发者视角的现实结论
- 一个快速自检清单
- 总结

引言

如果你从 Android 游戏开发转到 HarmonyOS，第一次看到 Ability，大概率会有点不适应：

生命周期好像更复杂了，不能随便拉起页面，后台限制明显更多。

第一反应：这也太"管得多"了吧？

于是你可能会觉得：

"以前 Activity 跑得好好的，为什么非要换这一套？"

但真正把游戏做到长时间运行、多场景切换、系统打断频繁之后，你会慢慢发现一件事：

Ability 不是为了方便你，而是为了约束你。

一个很容易误判的前提

很多开发者会下意识认为：

Activity → Ability只是名字换了、接口换了

但这个前提本身就是错的。

Activity 的隐含假设

Activity 模型背后，其实默认了几件事：

页面 = 运行单元
前台 = 可执行
生命周期 = UI 生命周期
系统"尽量不打断你"

这些假设，在早期手机游戏里勉强成立。

但 HarmonyOS 面对的世界不一样了

HarmonyOS 从一开始就假设：

多设备
多窗口
多任务并行
强后台管控
资源统一调度

在这个前提下：

"我在前台，所以我可以一直跑"
这件事，本身就是不成立的。

Ability 的第一层约束：运行权不等于可见性

在 Activity 模型里，很多游戏逻辑是这么写的：

java 复制代码

@Override
protected void onResume() {
  resumeGame()
}

潜台词是：

"我可见了，我就可以继续跑。"

Ability 直接拆掉了这个等式

在 HarmonyOS 里：

Ability 可见 ≠ 可长期运行
Ability 激活 ≠ 资源不受限
Ability 存在 ≠ 拥有执行权

你必须明确声明你为什么要跑。

第二层约束：把"长期运行"变成一种能力申请

这对游戏开发者来说，是最明显的不适点。

以前的思路是：

"我需要跑，所以我就跑。"

Ability 的思路是：

"你要跑多久？跑来干嘛？"

这不是刁难，是系统建模

比如：

音乐播放
导航
游戏对战

它们的共性不是"重要"，而是：

用户明确感知到它们在运行。

HarmonyOS 要求你把这件事说清楚。

第三层约束：生命周期被拆成"阶段"，不是"回调"

Activity 的生命周期，开发者往往当成"事件"。

Ability 的生命周期，更像是：

状态机的阶段切换。

这意味着什么？

错误用法：在生命周期里堆逻辑

ts 复制代码

onForeground() {
  loadAssets()
  connectServer()
  startMatch()
}

这在 HarmonyOS 里，风险极高。

正确理解：生命周期只做"状态切换"

ts 复制代码

onForeground() {
  runtime.enterForeground()
}

onBackground() {
  runtime.enterBackground()
}

真正的逻辑，在 Runtime / Session 模型里。

第四层约束：Ability 不鼓励"页面即世界"

很多游戏在 Activity 时代，会默认：

一个 Activity = 一个世界

切页面 = 切场景

Ability 明确反对这种设计

在 HarmonyOS 的模型里：

Ability 是系统调度单元
游戏世界是你自己的模型

如果你把世界绑在 Ability 上：

多窗口直接崩
任务切换状态丢失
后台恢复不可控

正确姿势：世界模型独立于 Ability

ts 复制代码

class GameSession {
  state: GameState
  frameClock: FrameClock
}

ts 复制代码

class GameAbility {
  session?: GameSession

  onCreate() {
    this.session = sessionManager.restore()
  }
}

Ability 只是：

世界的"宿主"，不是"本体"。

为什么这些约束，偏偏对游戏这么狠？

因为游戏是：

长时间占用资源
高频调度
对延迟极其敏感
最容易破坏系统公平性的应用形态

HarmonyOS 选择的不是：

"让游戏更爽"

而是：

"让系统能长期跑下去。"

一个开发者视角的现实结论

如果你发现：

游戏一切换就被暂停
后台跑不稳
生命周期频繁触发

不要急着骂系统，先问自己一句：

"我有没有明确告诉系统，我为什么要占用资源？"

一个快速自检清单

如果你的 HarmonyOS 游戏：

把核心逻辑写在 Ability 里
把前后台当成 resume / pause
默认前台就能一直跑
没有独立的运行态模型

那你遇到的所有"限制"，几乎都是必然的。

总结

Ability 不是 Activity 的替代品，而是 HarmonyOS 强行加上的"安全阀"。

它强迫你：

把运行理由说清楚
把世界模型抽出来
把生命周期当成状态迁移
接受系统统一调度

这对短期开发来说是成本，但对一个能长期活着的游戏来说，是必要条件。