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

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

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

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

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

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

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

引言

很多人第一次接触鸿蒙游戏开发时，都会有一个问题：

用 ArkUI 能不能写游戏？体验怎么样？

直觉上，ArkUI 更像是“做 App UI 的工具”，而不是“做游戏的引擎”。

但真正上手之后，你会发现：

• 能写，而且还挺顺手
• 但思路完全不一样
• 写法更像“做系统”，而不是“做画面”

最后你会得到一个很真实的结论：

ArkUI 不是不适合做游戏，而是你不能用“传统游戏开发思维”去用它。

在 HarmonyOS 的生态下：

游戏，本质上变成了一种“状态驱动的 UI 系统”。

一、结论

用 ArkUI 写游戏，有 3 个核心特点：

1、状态驱动（State Driven）
2、UI 即渲染（UI = Render）
3、逻辑与视图强绑定（但可解耦）

如果你习惯：

Unity / Cocos

那你会明显感觉：

范式完全不同

二、我们做一个最简单的小游戏

目标：点击加分游戏

规则：

点击按钮 → 分数 +1

ArkUI 实现

@Entry
@Component
struct ClickGame {

  @State score: number = 0

  build() {
    Column() {
      Text(`Score: ${this.score}`)
        .fontSize(30)

      Button("点击 +1")
        .onClick(() => {
          this.score += 1
        })
    }
  }
}

运行效果：

点击 → UI 自动更新

三、第一感受：写 UI = 写游戏？

在传统游戏开发中：

逻辑更新 → 手动刷新画面

但在 ArkUI 中：

状态变化 → UI 自动刷新

本质：

你不需要“渲染”，你只需要“改状态”

四、如果加一点“游戏逻辑”呢？

加入自动掉血

aboutToAppear() {
  setInterval(() => {
    this.score -= 1
  }, 1000)
}

运行：

每秒 -1
点击 +1

你会发现：

这已经是一个“实时游戏”了

五、问题开始出现了

当逻辑变复杂时：

状态混乱

@State score
@State hp
@State level

全在页面里。

逻辑越来越多

setInterval
点击逻辑
判断胜负

页面变成“巨型文件”，到这里你会意识到：

ArkUI 能写游戏，但需要架构

六、正确写法：引入 Store

把状态拿出来

class GameStore {
  score = 0
  hp = 100
}

export const store = new GameStore()

页面使用

Text(`Score: ${store.score}`)

好处：

状态集中
逻辑清晰
易扩展

七、再进阶：加入游戏系统

示例：战斗系统

class BattleSystem {

  update(store: GameStore) {
    if (store.hp <= 0) {
      console.log("Game Over")
    }
  }

}

游戏循环

setInterval(() => {
  battleSystem.update(store)
}, 16)

这时候：

你已经接近“真正的游戏架构”了

八、ArkUI 的优势

1、状态驱动

不需要手动刷新 UI

2、多端适配简单

在 HarmonyOS 中：

手机 / 平板 / TV

UI 自适应能力强。

3、和系统能力融合

通知
分布式
AI

游戏更容易接入系统能力。

九、ArkUI 的限制

1、不适合高性能 3D 游戏

没有完整游戏引擎能力

2、渲染控制有限

不像 Unity 那样细粒度控制

3、需要架构能力

否则很容易写乱

十、适合做什么游戏？

适合

轻量游戏
策略游戏
UI 驱动游戏
AI 互动游戏

不适合

大型 3D
高帧率动作游戏

十一、一个真实体验总结

用 ArkUI 写游戏，你会经历三个阶段：

阶段 1：

很简单，很爽

阶段 2：

开始混乱

阶段 3：

引入架构 → 变强

总结

用 ArkUI 写小游戏的体验是：

上手简单
思路不同
需要架构
适合新型游戏

在 HarmonyOS 的生态中，这意味着：

游戏不再只是“渲染画面”，而是“驱动状态”。

最后一句话：

用 ArkUI 写游戏，不是做“画面控制”，而是在做“状态系统”。