网罗开发 （小红书、快手、视频号同名）

  大家好，我是 展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
📣 公众号“Swift社区”，每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。
💬 微信端添加好友“fzhanfei”，与我直接交流，不管是项目瓶颈的求助，还是行业趋势的探讨，随时畅所欲言。
📅 最新动态：2025 年 3 月 17 日
快来加入技术社区，一起挖掘技术的无限潜能，携手迈向数字化新征程！

引言

很多人在写鸿蒙游戏时，会有一种“说不清哪里不对”的感觉：

功能能跑，但代码越写越乱，Bug 越来越难查。

本质原因只有一个：

你没有搞清楚“数据是怎么流动的”

在 HarmonyOS 中，尤其是基于 ArkUI 的游戏开发：

数据流，才是整个架构的核心。

一、先给结论

鸿蒙游戏的数据流，本质是：

Input（输入）
   ↓
Service（逻辑）
   ↓
Store（状态）
   ↓
UI（渲染）

如果加上 AI：

Agent（AI）
   ↓
Store

一句话总结：

所有数据变化，最终都必须落到 Store。

二、最简单的数据流

场景：玩家点击“移动”

1、UI 触发事件

Button("→")
  .onClick(() => gameService.moveRight())

UI 不做逻辑，只做“触发”。

2、Service 处理逻辑

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

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

Service：

读取状态 → 计算 → 写回状态

3、Store 更新状态

update(partial) {
  this.state = { ...this.state, ...partial }
}

状态发生变化。

4、UI 自动更新

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

ArkUI 自动刷新。

完整链路

点击按钮
   ↓
Service
   ↓
Store
   ↓
UI 更新

这就是最小数据流闭环

三、复杂一点的数据流

场景：加载排行榜

1、页面触发

aboutToAppear() {
  this.loadRank()
}

2、Service 请求数据

async loadRank() {
  const data = await rankService.fetchRank()

  gameStore.update({
    rankList: data
  })
}

3、UI 渲染

ForEach(this.state.rankList, item => {
  Text(item.name)
})

数据流

生命周期 → Service → API → Store → UI

本质没变：

所有数据最终都进入 Store

四、加入 AI 后的数据流

场景：玩家和 NPC 对话

1、玩家输入

Button("发送")
  .onClick(() => npcAgent.talk(this.input))

2、Agent 调用 AI

async talk(input: string) {
  const reply = await aiService.chat(input)

  gameStore.update({
    messages: [...gameStore.state.messages, reply]
  })
}

3、UI 更新聊天记录

ForEach(this.state.messages, msg => {
  Text(msg)
})

数据流

用户输入
   ↓
Agent
   ↓
AI
   ↓
Store
   ↓
UI

本质：

AI 也是数据流中的一个节点

五、多端场景的数据流

场景：手机控制，TV 显示

1、手机更新状态

gameStore.update({
  player: { x: 200, y: 100 }
})

2、同步到其他设备

distributedSync.send(gameStore.state)

3、TV 渲染

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

数据流

手机 → Store → 分布式同步 → TV → UI

核心变化：

数据流不再局限于一个设备

六、完整数据流模型

我们把所有场景统一起来：

标准模型

Input（用户 / AI / 网络 / 设备）
        ↓
Service / Agent（处理）
        ↓
Store（唯一状态源）
        ↓
UI（自动渲染）

输入来源可以是：

• 用户点击
• 网络请求
• AI 决策
• 其他设备

但最终：

必须进入 Store

七、为什么必须这样设计？

1、可维护性

如果没有统一数据流：

UI 改数据
Service 改数据
AI 也改数据

结果：

状态混乱

2、可调试性

统一数据流：

所有状态变化都有来源

Debug：

查 Service / Agent 即可

3、可扩展性

你可以轻松加：

• AI
• 多端
• 网络

因为数据流已经统一。

八、一个很关键的原则

所有修改必须通过 Store

错误

this.state.score++

正确

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

原因：

只有 Store 才是“真实状态”

九、常见错误

1、数据绕过 Service：UI 直接改 Store。

2、多个状态源：页面自己维护一份 state。

3、AI 直接改 UI：跳过 Store。

4、跨设备不同步：忘记分布式同步。

总结

鸿蒙游戏的数据流，本质可以总结为：

输入（用户 / AI / 网络 / 多端）
        ↓
处理（Service / Agent）
        ↓
状态（Store）
        ↓
渲染（UI）

在 HarmonyOS 中，这种数据流带来的最大变化是：

游戏不再是“函数调用”
而是“状态流动”

数据从哪里来不重要，重要的是它必须流经 Store。