鸿蒙游戏开发的正确分层方式
本文介绍了鸿蒙游戏开发的六层架构设计:Model(数据)、Store(状态)、Service(逻辑)、Component(UI)、Page(页面)和Agent(AI)。通过分层架构,可以控制复杂度、提高扩展性和可维护性。文章详细说明了每层的职责和实现方式,强调UI与业务逻辑分离、状态集中管理、逻辑分层处理的原则,并指出常见错误分层方式。该架构能有效解决游戏开发中状态混乱、逻辑耦合等问题,为构建可扩


大家好,我是 子玥酱,一名长期深耕在一线的前端程序媛 👩💻。曾就职于多家知名互联网大厂,目前在某国企负责前端软件研发相关工作,主要聚焦于业务型系统的工程化建设与长期维护。
我持续输出和沉淀前端领域的实战经验,日常关注并分享的技术方向包括 前端工程化、小程序、React / RN、Flutter、跨端方案,
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。
技术方向:前端 / 跨端 / 小程序 / 移动端工程化
内容平台:掘金、知乎、CSDN、简书
创作特点:实战导向、源码拆解、少空谈多落地
文章状态:长期稳定更新,大量原创输出
我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在“API 怎么用”,而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍,希望能帮你在实际工作中少走弯路。
子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端,或准备长期走前端这条路
📚 关注我,第一时间获取前端行业趋势与实践总结
🎁 可领取 11 类前端进阶学习资源(工程化 / 框架 / 跨端 / 面试 / 架构)
💡 一起把技术学“明白”,也用“到位”
持续写作,持续进阶。
愿我们都能在代码和生活里,走得更稳一点 🌱
文章目录
引言
很多人刚开始做鸿蒙游戏时,代码大概是这样的:
@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 / 多端)
否则,迟早会变成:
一个无法继续迭代的“巨型页面文件”。
更多推荐


所有评论(0)