鸿蒙游戏开发的正确分层方式

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

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

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

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

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

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

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

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

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

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

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

持续写作，持续进阶。

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

文章目录

• • 引言
  • 一、为什么"分层"这么重要？
  • • 不分层的结果
    • 分层之后
  • 二、推荐分层结构（核心）
  • 三、第一层：Model（数据结构）
  • • 作用
    • 示例
  • 四、第二层：Store（状态层）
  • • 作用
    • 示例
  • 五、第三层：Service（业务逻辑）
  • • 作用
    • 示例
  • [六、第四层：Component（UI 组件）](#六、第四层：Component（UI 组件）)
  • • 作用
    • 示例
  • 七、第五层：Page（页面层）
  • • 作用
    • 示例
  • 八、第六层：Agent
  • • 作用
    • 示例
  • 九、完整调用链
  • • 用户点击
    • [Service 更新状态](#Service 更新状态)
    • [Store 通知 UI](#Store 通知 UI)
    • [UI 自动更新](#UI 自动更新)
    • [加上 AI：](#加上 AI：)
  • 十、为什么这个分层是"正确的"？
  • • 1、复杂度
    • 2、扩展性
    • 3、可维护性
  • 十一、常见错误分层
  • • [错误 1：页面写逻辑](#错误 1：页面写逻辑)
    • [错误 2：UI 直接改状态](#错误 2：UI 直接改状态)
    • [错误 3：没有 Store](#错误 3：没有 Store)
    • [错误 4：AI 写在 UI](#错误 4：AI 写在 UI)
  • 总结

引言

很多人刚开始做鸿蒙游戏时，代码大概是这样的：

@Entry
@Component
struct GamePage {

  @State playerX: number = 0
  @State score: number = 0

  move() {
    this.playerX += 10
  }

  addScore() {
    this.score++
  }

  build() {
    Column() {
      Text(`Score: ${this.score}`)
      Button("Move").onClick(() => this.move())
    }
  }
}

一开始没问题，但随着功能增加，很快就会出现：

• 页面越来越大
• 逻辑越来越乱
• 状态难以维护
• 无法扩展多端 / AI

最后你会发现：

问题不在功能，而在"分层"

一、为什么"分层"这么重要？

一句话总结：

分层 = 控制复杂度

不分层的结果

UI + 逻辑 + 状态 + AI 全混在一起

导致：

• 改一个地方，影响全局
• Bug 难定位
• 无法扩展

分层之后

UI（展示）
Service（逻辑）
Store（状态）
Agent（AI）

每一层职责清晰。

二、推荐分层结构（核心）

在 HarmonyOS 中，推荐的游戏架构是：

components（UI组件）
pages（页面）
services（业务逻辑）
store（状态管理）
models（数据模型）
agent（AI）

核心关系：

UI → Service → Store → Agent

三、第一层：Model（数据结构）

作用

定义"游戏世界的数据结构"

示例

// models/GameModel.ets
export interface Player {
  x: number
  y: number
}

export interface GameState {
  player: Player
  score: number
}

原则：

• 只定义结构
• 不写逻辑

四、第二层：Store（状态层）

作用

管理"唯一数据源"

示例

// store/GameStore.ets
import { GameState } from '../models/GameModel'

export class GameStore {

  state: GameState = {
    player: { x: 0, y: 0 },
    score: 0
  }

  update(partial: Partial<GameState>) {
    this.state = { ...this.state, ...partial }
    this.notify()
  }

  notify() {
    // 通知 UI 更新（简化）
  }

}

export const gameStore = new GameStore()

核心原则：

Single Source of Truth（唯一状态源）

五、第三层：Service（业务逻辑）

作用

处理"游戏规则"和"操作逻辑"

示例

// services/GameService.ets
import { gameStore } from '../store/GameStore'

export class GameService {

  moveLeft() {
    const player = gameStore.state.player

    gameStore.update({
      player: {
        ...player,
        x: player.x - 10
      }
    })
  }

  addScore() {
    gameStore.update({
      score: gameStore.state.score + 1
    })
  }

}

export const gameService = new GameService()

原则：

• 不直接操作 UI
• 只操作状态

六、第四层：Component（UI 组件）

作用

展示数据

示例

// components/Player.ets
@Component
export struct Player {

  @Prop x: number
  @Prop y: number

  build() {
    Image("player.png")
      .position({
        x: this.x,
        y: this.y
      })
  }

}

原则：

UI 不包含业务逻辑

七、第五层：Page（页面层）

作用

组合 UI + 调用 Service

示例

@Entry
@Component
struct GamePage {

  @State state = gameStore.state

  build() {
    Column() {

      Player({
        x: this.state.player.x,
        y: this.state.player.y
      })

      Text(`Score: ${this.state.score}`)

      Button("←").onClick(() => gameService.moveLeft())
      Button("+1").onClick(() => gameService.addScore())

    }
  }

}

页面职责：

展示 + 调用

八、第六层：Agent

作用

负责"决策"

示例

// agent/EnemyAgent.ets
import { gameStore } from '../store/GameStore'

export class EnemyAgent {

  decide() {
    const { player } = gameStore.state

    if (player.x > 100) {
      return 'moveRight'
    }

    return 'moveLeft'
  }

  act() {
    const action = this.decide()

    if (action === 'moveRight') {
      // 更新状态
    }
  }

}

本质：

Agent = 自动玩家 / NPC / AI 系统

九、完整调用链

把所有层串起来：

用户点击

Button("←").onClick(() => gameService.moveLeft())

Service 更新状态

gameStore.update({...})

Store 通知 UI

this.state = gameStore.state

UI 自动更新

Player({ x: this.state.player.x })

完整链路：

UI → Service → Store → UI

加上 AI：

Agent → Store → UI

十、为什么这个分层是"正确的"？

因为它解决了三个核心问题：

1、复杂度

每层只做一件事

2、扩展性

• 可以加 AI
• 可以加多端
• 可以加网络

3、可维护性

• Bug 容易定位
• 代码结构清晰

十一、常见错误分层

错误 1：页面写逻辑

this.score++

错误 2：UI 直接改状态

@State score++

错误 3：没有 Store

状态散落各处。

错误 4：AI 写在 UI

完全不可维护。

总结

鸿蒙游戏开发的正确分层，可以总结为六层：

Model（数据）
Store（状态）
Service（逻辑）
Component（UI）
Page（页面）
Agent（AI）

核心调用关系：

UI → Service → Store → UI
         ↑
       Agent

最后一句话总结：

在 HarmonyOS 中，写游戏不再是"堆功能"，而是"设计分层系统"。

而分层做好了，你的项目才有可能：

• 可扩展
• 可维护
• 可进化（AI / 多端）

否则，迟早会变成：

一个无法继续迭代的"巨型页面文件"。