HarmonyOS：App、游戏、PC 架构能统一吗？

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

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

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括 前端工程化、小程序、React / RN、Flutter、跨端方案，

在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

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

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

子玥酱 · 前端成长记录官 ✨

👋 如果你正在做前端，或准备长期走前端这条路

📚 关注我，第一时间获取前端行业趋势与实践总结

🎁 可领取 11 类前端进阶学习资源 （工程化 / 框架 / 跨端 / 面试 / 架构）

💡 一起把技术学"明白"，也用"到位"

持续写作，持续进阶。

愿我们都能在代码和生活里，走得更稳一点 🌱

文章目录

• • 引言
  • 一个看起来很合理的起点
  • App：强业务驱动，状态是第一公民
  • • [一个典型的 App 架构关注点](#一个典型的 App 架构关注点)
  • [游戏：不是 UI 驱动，而是"循环驱动"](#游戏：不是 UI 驱动，而是“循环驱动”)
  • • 游戏里的"状态"是什么？
  • [PC 应用：窗口、输入、并行任务才是核心](#PC 应用：窗口、输入、并行任务才是核心)
  • 看起来统一，其实早就分叉的三条路
  • [HarmonyOS 真正适合"统一"的是什么？](#HarmonyOS 真正适合“统一”的是什么？)
  • • 可以统一的部分
    • 不该强行统一的部分
  • 为什么"强统一"项目，后期往往最痛苦？
  • 一个更现实的结论
  • 总结

引言

几乎每一个开始做 HarmonyOS 的团队，都会在某个阶段被问到同一个问题：

App、游戏、PC 应用，能不能共用一套架构？

从发布会、宣传资料到技术解读，得到的答案往往是：

"可以，HarmonyOS 是一次真正的统一。"

但真正决定项目走向的，从来不是"能不能统一"，而是：

你统一的是哪一层？
又愿意为统一付出多少工程代价？

站在架构视角看，HarmonyOS 并不是"不能统一"，而是------
它对统一的容忍边界，比很多人想象得要清晰得多。

一个看起来很合理的起点

很多团队在立项时，都会有一个非常自然的想法：

既然都是 HarmonyOS，

那 App、游戏、PC，是不是可以共用一套技术栈？

于是你会看到类似的规划：

统一语言：ArkTS
统一 UI：ArkUI
统一状态模型
统一业务逻辑

从 PPT 上看，这几乎是"必然正确"的选择。

但真正的问题在于------这些层级，并不是等价的。

App：强业务驱动，状态是第一公民

先看最常见的 HarmonyOS App。

一个典型的 App 架构关注点

• 页面跳转
• 表单状态
• 列表与分页
• 登录态 / 权限
• 网络请求生命周期

你写的核心代码，往往围绕状态展开：

@State user: User | null = null
@State loading: boolean = false

if (this.user) {
  HomeView()
} else {
  LoginView()
}

这里有几个非常明显的特征：

• UI = 状态投影
• 页面切换是主路径
• 状态变化频繁
• 生命周期跟着用户行为走

这是一套标准的"应用模型"。

游戏：不是 UI 驱动，而是"循环驱动"

再看 HarmonyOS 游戏。

哪怕你用的是 ArkTS，很多核心逻辑完全不同。

游戏里的"状态"是什么？

class Player {
  position: Vector
  velocity: Vector
  hp: number
}

这些状态的特点是：

• 高频变化（每帧）
• 强时序依赖
• 与渲染强绑定
• 不通过 UI rebuild 驱动

你的核心循环可能是：

update(deltaTime) {
  player.update(deltaTime)
  physics.step(deltaTime)
  render()
}

这里有一个本质差异：

游戏的状态不是"给 UI 看的"，
而是"给引擎跑的"。

即使最终画面显示在屏幕上，它也不是通过声明式 UI diff 出来的。

PC 应用：窗口、输入、并行任务才是核心

再看 HarmonyOS PC 应用。

PC 应用的第一优先级，往往不是 UI 精致度，而是：

• 多窗口
• 多任务
• 键盘 / 鼠标输入
• 文件系统
• 长时间运行稳定性

你会更关心：

窗口状态
 ├─ 当前激活窗口
 ├─ 多文档状态
 ├─ 拖拽 / 选区
 ├─ 后台任务

代码结构往往是：

openFile(path)
createWindow()
attachController()

这里的状态有明显特征：

• 生命周期极长
• 与系统资源强绑定
• 不适合频繁 rebuild
• 强调可恢复性

这已经完全不是"移动 App 的状态模型"了。

看起来统一，其实早就分叉的三条路

把三者放在一起看，会非常清楚：

维度	App	游戏	PC
驱动模型	状态驱动 UI	主循环驱动	事件 / 窗口驱动
状态频率	中	极高	低但持久
UI 地位	核心	表现层	外壳
生命周期	页面级	帧级	进程级

这意味着一件事：

你可以统一"工具"，
但很难统一"架构重心"。

HarmonyOS 真正适合"统一"的是什么？

如果你硬要找一个合理的统一层级，其实只有这几类：

可以统一的部分

• 语言（ArkTS）
• 基础工具链
• 通用工具库
• 网络 / 数据解析
• 日志、监控、埋点

class Logger {
  log(event: string) {}
}

这些东西：

• 与 UI 无关
• 与交互模型弱相关
• 生命周期独立

不该强行统一的部分

• 状态管理模型
• UI 结构组织方式
• 生命周期设计
• 性能假设

一旦你试图把：

App 的状态模型
硬套到游戏或 PC

你会很快遇到结构性冲突。

为什么"强统一"项目，后期往往最痛苦？

很多失败案例都有一个共同特征：

统一得太早，分叉得太晚。

初期你可能会看到：

shared/
 ├─ state/
 ├─ ui/
 ├─ logic/

半年后变成：

shared/
 ├─ app_state/
 ├─ game_state/
 ├─ pc_state/

再过一段时间：

• 改一处，三端全测
• 状态模型为了兼容而变形
• 抽象层越来越厚，但没人敢删

这不是 HarmonyOS 的问题，而是：

架构目标选错了。

一个更现实的结论

HarmonyOS 并不是不能统一架构，而是：

• 不值得全层统一
• 不适合过早统一
• 不应该统一"行为模型"

真正成熟的做法往往是：

底层能力统一，
上层模型分治。

总结

如果你问：

HarmonyOS 上，App / 游戏 / PC 能不能共用一套架构？

工程答案是：

可以共用一部分，但绝不该共用全部。

如果你非要一句更现实的话：

HarmonyOS 给你的是"工具统一"的可能性，
而不是"产品形态统一"的承诺。

真正做得好的团队，关注的从来不是：

• "我能不能统一？"

而是：

• "我该在哪一层停下？"

这，才是 HarmonyOS 架构设计里，最重要的一道分界线。