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

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

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

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

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

引言

如果你已经用 ArkUI 写过一个小游戏，大概率会有一种“理所当然”的想法：

游戏 = 一个设备上的体验

比如：

手机游戏 → 就在手机上玩

但在 HarmonyOS 里，这个前提是错的。

因为鸿蒙的设计目标从一开始就不是“单设备系统”，而是：

一个跨设备的分布式操作系统（HarmonyOS）

这意味着一件事：

你的游戏，从第一天开始，就不应该只属于一个设备。

很多人忽略这一点，结果就是：

功能能跑
体验割裂
扩展困难

一、结论

在 HarmonyOS 生态中：

多端 ≠ 扩展能力
多端 = 基础能力

你不考虑多端，不是“暂时不做”，而是：

从架构上就已经限制了你的游戏上限

二、传统游戏的“设备假设”

在传统开发中（比如 Unity / Cocos）：

设备 = 容器
游戏 = 运行在容器里

你默认：

一个屏幕
一个输入
一个用户

所以你的代码天然是：

Player = 单实例
Input = 当前设备
Render = 当前屏幕

这在 iOS / Android 是成立的。

但在 HarmonyOS 中：

这个假设直接失效

三、鸿蒙的本质：设备是可以组合的

HarmonyOS 提供的是一种能力：

多个设备 = 一个“超级终端”

比如：

手机 + 平板 + TV + 手表

可以变成：

一个逻辑上的“游戏环境”

这时候：

能力	变化
屏幕	多屏
输入	多来源
计算	可分布
状态	可同步

所以问题来了：

你的游戏，是否支持这种“组合态”？

四、不考虑多端，会发生什么？

1、UI 直接崩掉

你写死：

Column() {
  Text("Score")
}

在手机 OK，但在：

TV → 太小
平板 → 太空
折叠屏 → 布局断裂

问题本质：

你假设了“唯一屏幕尺寸”

2、输入模型不成立

传统输入：

点击 / 触摸

但在鸿蒙：

遥控器（TV）
手势（平板）
语音（AI）

如果你写死：

Button.onClick()

那你已经丢掉了一半用户。

3、体验不连续

一个典型场景：

手机玩到一半 → 切到 TV

如果你没有设计多端：

进度丢失
状态不同步
重新开始

用户直接流失。

五、多端的本质：状态必须“可迁移”

回到 ArkUI 的核心：

状态驱动 UI

那多端问题，本质变成：

状态能不能跨设备同步？

错误写法

@State score = 0

状态只存在当前页面。

正确思路

class GameStore {
  score = 0
  hp = 100
}

然后：

状态 → 可同步
UI → 只是展示

你开始从：

UI 驱动逻辑

变成：

状态驱动多端 UI

六、一个典型多端游戏架构

我们抽象一下：

          ┌──────────────┐
          │  Game Store  │
          └──────┬───────┘
                 │
     ┌───────────┼───────────┐
     │           │           │
 手机 UI     平板 UI      TV UI

关键点：

状态唯一
UI 多个

这就是鸿蒙游戏的核心架构。

七、如何设计“多端友好”的游戏？

1、UI 必须自适应

不要写死：

width: 300

而是：

百分比 / Flex 布局

核心原则：

UI 是“流动的”，不是“固定的”

2、输入要抽象

不要直接写：

onClick()

而是抽象成：

handleAction("attack")

然后：

点击 → attack
遥控器 → attack
语音 → attack

本质：

输入统一为“行为”

3、状态必须中心化

不要：

状态分散在多个页面

要：

统一 Store / 全局状态

否则你做不了：

跨设备同步

4、支持“设备切换”

设计一个能力：

设备 A → 设备 B

你要保证：

状态一致
UI 无缝切换

这才是鸿蒙体验。

八、一个简单示例：多端分数同步

Store

class GameStore {
  score = 0

  addScore() {
    this.score += 1
  }
}

手机 UI

Button("点击 +1")
  .onClick(() => store.addScore())

TV UI

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

当你把状态同步出去后：

手机点一下 → TV 立即变化

这就是：

真正的鸿蒙游戏体验

九、多端带来的“新玩法”

一旦你支持多端，游戏设计会完全不一样：

1、设备分工

手机 → 操作
TV → 显示

2、多人协作

多个设备 → 多玩家

3、AI 融入

语音控制游戏

4、跨场景体验

家里 → 车上 → 办公室

游戏不再“中断”。

总结

为什么鸿蒙游戏必须考虑多端？

因为：

系统本身就是多端的

最终你会发现：

游戏 ≠ 一个设备
游戏 = 一个跨设备的状态系统

最后一句话：

在 HarmonyOS 里，不做多端设计，本质上是在“逆着系统写代码”。