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

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

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

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

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

引言

很多人做鸿蒙游戏时，第一反应是：

fetch("https://api.xxx.com/data")

简单、直接、能跑。

但只要项目稍微复杂一点，你很快就会发现：

• 请求到处都是
• 错误处理混乱
• 状态不同步
• 多端直接崩

最后你会意识到：

问题不是 fetch 不好，而是你缺少“网络层设计”。

在 HarmonyOS 的游戏架构中：

网络层，必须是 Store 体系的一部分，而不是工具函数。

一、为什么不能直接用 fetch？

我们先看一个典型“错误写法”。

页面直接请求

async loadData() {
  const res = await fetch("/api/score")
  const data = await res.json()

  this.score = data.score
}

看起来没问题，但问题非常多：

问题 1：状态绕过 Store

API → UI

Store 完全失效。

问题 2：逻辑分散

• A 页面请求一次
• B 页面再请求一次

无法复用。

问题 3：无法多端同步

手机请求了
TV 不知道

问题 4：无法接入 AI

AI 想用数据怎么办？没入口。

本质问题一句话总结：

fetch 是“调用工具”，不是“架构方案”。

二、正确思路：网络层 = 数据流的一部分

在鸿蒙游戏中，正确的数据流是：

UI → Action → Service → Network → Store → UI

注意：

网络请求不能直接改 UI，必须进入 Store

三、第一步：封装 Network 层

基础封装

// network/HttpClient.ets
export class HttpClient {

  async get(url: string) {
    const res = await fetch(url)
    return res.json()
  }

}

export const httpClient = new HttpClient()

目的：

• 统一入口
• 可扩展

四、第二步：引入 Service

错误

UI → fetch

正确

UI → Service → Network

示例

// services/ScoreService.ets
import { httpClient } from '../network/HttpClient'
import { gameStore } from '../store/GameStore'

export class ScoreService {

  async fetchScore() {
    const data = await httpClient.get("/api/score")

    gameStore.dispatch({
      type: 'SET_SCORE',
      payload: data.score
    })
  }

}

export const scoreService = new ScoreService()

核心：

网络请求 → 转换成 Action

五、第三步：统一进入 Store

dispatch(action) {
  this.reduce(action)
}

case 'SET_SCORE':
  this.state.score = action.payload

数据流变成：

API → Action → Store → UI

六、第四步：支持多端同步

如果你直接用 fetch：每个设备都要请求。

正确方案

dispatch(action) {

  this.reduce(action)

  this.syncToDevices(action)

}

同步

syncToDevices(action) {
  distributedSync.send(action)
}

结果：

一个设备请求 → 所有设备更新

本质：

同步 Action，而不是重复请求

七、第五步：支持 AI

AI 需要数据怎么办？

错误

ai.fetch("/api/score")

AI 和系统脱离。

正确

const score = gameStore.state.score

AI 直接读 Store。

AI 触发请求

agent.decide() {
  return { type: 'FETCH_SCORE' }
}

Service 处理

if (action.type === 'FETCH_SCORE') {
  scoreService.fetchScore()
}

本质：

AI 通过 Action 触发网络

八、第六步：统一错误处理

fetch 分散处理

try { } catch {}

到处都是。

Network 层统一处理

async get(url: string) {
  try {
    const res = await fetch(url)
    return res.json()
  } catch (e) {
    throw new Error("Network Error")
  }
}

Store 统一响应

case 'FETCH_ERROR':
  this.state.error = action.payload

UI 统一处理。

九、完整网络架构

UI
 ↓
Action
 ↓
Service
 ↓
HttpClient（fetch封装）
 ↓
API
 ↓
Service（处理）
 ↓
Action
 ↓
Store
 ↓
UI

扩展：

Store
 ↓
多端同步
 ↓
其他设备

十、为什么这个架构是必须的？

1、可维护性

所有请求集中在 Service

2、可扩展性

轻松支持：

• AI
• 多端
• 缓存

3、性能优化

可以加：

cache.get(url)

4、数据一致性

所有设备数据一致

十一、常见错误

1、UI 直接 fetch：架构崩。

2、多个地方请求同一接口：数据不一致。

3、AI 直接请求 API：系统割裂。

4、不同设备重复请求：性能浪费。

总结

鸿蒙游戏网络层设计的核心结论：

你不能直接用 fetch，是因为它不在数据流里。

正确架构是：

fetch 只是底层工具
Service 才是业务入口
Store 才是数据中心

完整链路：

UI → Action → Service → Network → Store → UI

在 HarmonyOS 中，这种设计带来的不是“代码规范”，而是：

从“请求数据”，升级为“管理数据流”。

不用 fetch 的本质，不是不用 API，而是不让它“绕开系统”。