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

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

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

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

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

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

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

引言

在传统游戏开发里，有一个默认前提：

一个设备
一个屏幕
一个玩家

不管是手游还是主机游戏，本质都是：

游戏运行在“一个终端”上

但在 HarmonyOS 中，这个前提被打破了：

多个设备
多个入口
一个游戏世界

也就是说：

游戏不再属于某个设备，而是属于“整个场景”

一、什么是“全场景游戏”？

很多人会误解为：

“就是多端适配”

但其实完全不是一回事。

1、单设备游戏

手机 → 输入 + 渲染 + 逻辑

2、多端适配

手机 / 平板 / TV → 各自运行

本质：多个版本

3、全场景游戏（鸿蒙）

多个设备 → 共同组成一个游戏系统

本质：一个系统，多端协作

二、核心变化：游戏的“运行位置”变了

这是最关键的一点。

传统模式

游戏 = App = 设备上的程序

鸿蒙全场景

游戏 = 状态 + 服务 + 多设备节点

代码层面变化：

传统

// 本地状态
this.player.x += 5

全场景

// 全局状态（可同步）
GameStore.update({
  player: { x: 5 }
})

本质：

游戏从“本地运行”，变成“分布式运行”

三、第一步：抽象“游戏状态中心”

要做全场景，第一件事不是 UI，而是：

把游戏变成“状态驱动系统”

1、统一状态

// models/GameState.ets
export interface GameState {
  player: { x: number; y: number }
  score: number
}

2、状态管理

// store/GameStore.ets
export class GameStore {

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

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

}

核心思想：

所有设备，只读写这一份状态

四、第二步：设备角色拆分

全场景的关键，不是“适配”，而是：

分工

典型角色设计

设备	角色
手机	控制器
TV	渲染器
平板	辅助信息
手表	通知

代码抽象

type Role = 'controller' | 'viewer' | 'assistant'

function getRole(device: string): Role {
  if (device === 'phone') return 'controller'
  if (device === 'tv') return 'viewer'
  return 'assistant'
}

本质：

设备不是“适配对象”，而是“系统节点”

五、第三步：输入与渲染解耦

传统游戏：

输入 + 渲染 + 逻辑 = 一体

全场景：

输入（手机） → 状态 → 渲染（TV）

示例

手机端

onClickLeft() {
  GameStore.update({
    player: { x: this.player.x - 5 }
  })
}

TV 端

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

本质：

输入和渲染被拆到不同设备

六、第四步：状态同步机制

全场景的核心难点：

怎么保证所有设备看到的是同一个世界？

1、基本同步思路

设备 A 更新状态
      ↓
同步到中心
      ↓
广播到其他设备

2、代码抽象

class SyncService {

  broadcast(state) {
    // 同步到其他设备
  }

  onReceive(newState) {
    GameStore.update(newState)
  }

}

核心：

状态是唯一真相（Single Source of Truth）

七、第五步：AI 作为“场景调度者”

当设备多了之后，一个问题出现：

谁来协调？

答案是：

AI Agent

示例

agent.decide({
  phoneInput,
  tvState,
  tabletData
})

AI 可以做什么？

• 分配任务
• 调整难度
• 协调设备

本质：

AI 从“参与者”变成“调度者”

八、一个完整场景示例

假设一个游戏：

场景

玩家用手机控制角色
TV 显示大画面
平板显示地图
AI 控制敌人

数据流

手机输入 → GameStore
             ↓
        TV 渲染
             ↓
        AI 决策
             ↓
        更新状态

这是一个：

完整的“全场景系统”

九、和传统手游的本质区别

对比一下：

手游

一个设备
一个玩家
一个循环

鸿蒙全场景

多个设备
多个角色（人 + AI）
一个状态系统

本质变化：

从“程序” → “系统”

十、落地建议

1、先做“单设备 + 状态中心”

不要一开始就多端。

2、再拆输入与渲染

手机控制
TV 显示

3、最后做多设备协同

逐步扩展。

4、预留 AI 接口

agent.decide(state)

总结

鸿蒙游戏从“单设备”到“全场景”，本质是一次彻底的范式升级。

可以总结为四个变化：

1、运行位置变了

设备 → 系统

2、结构变了

App → 分布式状态系统

3、角色变了

玩家 → 玩家 + AI + 多设备

4、目标变了

做一个游戏 → 构建一个世界

最后一句话总结：

在 HarmonyOS 中，游戏不再是“安装在设备上的应用”，而是“运行在多个设备之间的系统”。

而这，正是“全场景”的真正含义。