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

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

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

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

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

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

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

引言

很多人刚开始做鸿蒙游戏时，架构都很简单：

pages
components
utils

甚至一个页面就把逻辑全写完：

UI + 状态 + 网络 + 游戏逻辑

一开始没问题，甚至开发很快。但只要项目一变大，你就会遇到这些情况：

• 一个页面上千行代码
• 改一个功能，影响一大片
• 新需求加不进去
• 多端适配越来越混乱

最后你会发现：

不是你不会写代码，而是架构已经“卡死”了。

在 HarmonyOS 的多端 + 分布式 + AI 场景下：

架构如果不可扩展，项目一定会崩。

一、先说结论

一个“可扩展架构”，必须具备 4 个能力：

1、模块可拆（Modular）
2、状态可控（State）
3、逻辑可复用（Service）
4、能力可扩展（Plugin / AI）

如果缺一个：

你迟早会重构

二、最常见错误架构

巨型页面模式

@Entry
@Component
struct GamePage {

  @State score: number = 0

  aboutToAppear() {
    this.initGame()
  }

  initGame() {
    // 初始化逻辑
  }

  update() {
    // 游戏逻辑
  }

  renderEnemy() {
    // UI
  }

  requestData() {
    // 网络请求
  }

  build() {
    // UI 渲染
  }
}

问题：

• UI + 逻辑 + 网络混在一起
• 无法复用
• 无法扩展

一句话：

写得快，死得也快

三、正确思路：分层 + 模块化

推荐基础结构

entry
 ├─ pages        页面层（UI）
 ├─ components   UI组件
 ├─ store        状态管理
 ├─ services     业务逻辑
 ├─ systems      游戏系统
 ├─ models       数据结构
 └─ utils

分层职责

Page        → 展示
Component   → UI复用
Store       → 状态
Service     → 业务逻辑
System      → 游戏机制
Model       → 数据结构

核心原则：

UI、状态、逻辑彻底分离

四、核心一：状态驱动

为什么一定要状态层？

没有状态层：

数据到处传
逻辑分散
不可控

示例

class GameStore {
  score: number = 0
  playerHP: number = 100
}

export const gameStore = new GameStore()

页面使用

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

好处：

统一数据源
状态可追踪
易扩展

五、核心二：Service 层

职责

业务逻辑
网络请求
AI 调用

示例

export class BattleService {

  attack(player, enemy) {
    enemy.hp -= player.attack
  }

}

页面不再写逻辑：

Page → 调 Service

六、核心三：System

这是很多人忽略的重点。

System 的作用

统一管理游戏机制

示例

export class CombatSystem {

  update(state) {
    this.handleCollision(state)
    this.handleDamage(state)
  }

}

游戏运行：

systems.forEach(system => system.update(gameStore))

优势：

高扩展
可插拔
可复用

七、核心四：组件拆分

错误

一个页面所有 UI

正确

Player
Enemy
HUD

示例

@Component
export struct PlayerView {
  @Prop hp: number

  build() {
    Text(`HP: ${this.hp}`)
  }
}

页面：

PlayerView({ hp: gameStore.playerHP })

八、核心五：插件化 / AI 扩展

未来游戏一定会变化：

AI
新玩法
新系统

插件架构

interface GamePlugin {
  init(): void
  update(): void
}

示例

class AIPlugin implements GamePlugin {
  update() {
    // AI 行为
  }
}

注册：

plugins.push(new AIPlugin())

优势：

随时扩展
不改核心代码

九、多端适配

在 HarmonyOS 中：

架构必须支持：

不同 UI
不同输入
不同性能

示例

if (device === 'tv') {
  useRemoteControl()
} else {
  useTouch()
}

核心：

设备差异在“适配层”，而不是业务层

十、完整架构图

UI（Page / Component）
        ↓
State（Store）
        ↓
Service（业务逻辑）
        ↓
System（游戏机制）
        ↓
Plugin（扩展 / AI）

数据流：

用户操作 → 更新 State → System 计算 → UI 渲染

十一、架构演进路径

阶段 1：Demo

一个页面

阶段 2：分层

Page + Service

阶段 3：状态化

引入 Store

阶段 4：系统化

System + Plugin

目标：

可持续扩展

十二、常见错误

1、所有逻辑写在页面

2、没有状态层

3、没有 System 层

4、多端逻辑混乱

5、AI 直接写死在页面

总结

鸿蒙游戏可扩展架构核心：

分层（UI / State / Service）
+ 系统化（System）
+ 插件化（Plugin / AI）
+ 多端适配

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

游戏不再是一个页面，而是一个“可演进系统”。

记住一句话：

写代码是实现功能，设计架构是决定你能走多远。
架构不是为了“现在能跑”，而是为了“未来能改”。