鸿蒙 PC 多窗口系统：一次讲透实现原理

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

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

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

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

展菲：您的前沿技术领航员

👋 大家好，我是展菲！

📱 全网搜索"展菲"，即可纵览我在各大平台的知识足迹。

每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

文章目录

- 引言
- [一、传统 PC 多窗口：本质是"多个独立应用"](#一、传统 PC 多窗口：本质是“多个独立应用”)
- [二、鸿蒙 PC 最大的变化：Window 不再是核心](#二、鸿蒙 PC 最大的变化：Window 不再是核心)
- [三、什么是 Workspace？](#三、什么是 Workspace？)
- 四、多窗口真正的实现原理
- 五、为什么"窗口持有状态"一定会出问题
- [六、真正正确的结构：Window 无状态化](#六、真正正确的结构：Window 无状态化)
- 七、多窗口同步的真正原理
- 八、焦点系统：为什么会越来越复杂
- - 正确做法：FocusCenter
- [九、多窗口真正难的，不是 UI，而是"状态隔离"](#九、多窗口真正难的，不是 UI，而是“状态隔离”)
- - 例如：
- [十、多窗口 + AI：为什么传统架构会瞬间崩](#十、多窗口 + AI：为什么传统架构会瞬间崩)
- - [Workspace 模型下](#Workspace 模型下)
- 十一、真正稳定的多窗口架构
- [十二、为什么鸿蒙 PC 本质更像"系统"](#十二、为什么鸿蒙 PC 本质更像“系统”)
- 十三、总结

引言

很多人第一次做鸿蒙 PC 多窗口时，都会觉得：

text 复制代码

不就是"再开一个窗口"吗？

于是项目很容易这样设计：

text 复制代码

WindowA
WindowB
WindowC

每个窗口：

自己维护状态
自己管理生命周期
自己处理输入

刚开始看起来没问题。

但只要项目稍微复杂一点，很快就会出现这些现象：

多窗口状态不同步
焦点乱跳
数据覆盖
窗口切换后 UI 错乱
AI 修改了错误窗口
一个窗口关闭，另一个直接崩

最后团队会发现：

真正困难的，从来不是"开窗口"。

而是：

如何让多个窗口，仍然属于"同一个系统"。

因为在鸿蒙 PC 上：

text 复制代码

多窗口不是 UI 能力
而是状态系统能力

一、传统 PC 多窗口：本质是"多个独立应用"

先理解传统 Windows / macOS 模型。过去桌面系统里的多窗口，本质上是：

text 复制代码

Window = 独立上下文

例如：

一个窗口一个生命周期
一个窗口一份状态
一个窗口一套逻辑

典型结构：

text 复制代码

Window
 ├── UI
 ├── State
 ├── Event
 └── Lifecycle

这种模式最大的问题：

窗口之间天然隔离。

所以后面一定会出现：

状态同步
数据共享
焦点竞争
生命周期冲突

二、鸿蒙 PC 最大的变化：Window 不再是核心

这是最关键的一步，很多人以为：

text 复制代码

Window 是系统核心

但在鸿蒙 PC：

真正的核心，其实是 Workspace。

Window 只是：

text 复制代码

Workspace 的可视化投影

三、什么是 Workspace？

你可以把它理解成：

text 复制代码

一个"运行中的状态空间"

例如：

ts 复制代码

class Workspace {
  state: WorkspaceState
  focus: FocusState
  tasks: TaskState
  layout: LayoutState
}

这里最关键的一点：

Window 不拥有状态。

真正拥有状态的是：

text 复制代码

Workspace

四、多窗口真正的实现原理

很多人以为：

text 复制代码

多窗口 = 创建多个 Window

其实真正结构更像：

text 复制代码

GlobalState
      ↓
Workspace
      ↓
Window
      ↓
ArkUI

也就是说：

1、GlobalState

负责：

用户
登录态
分布式数据
AI 上下文
设备状态

例如：

ts 复制代码

globalStore.user

2、Workspace

负责：

当前任务
当前文档
当前焦点
当前布局
当前窗口组

例如：

ts 复制代码

workspace.activeDocument

3、Window

只负责：

text 复制代码

状态显示

本身不应该：

持有核心业务状态
管理系统逻辑
保存长期数据

五、为什么"窗口持有状态"一定会出问题

这是很多项目后期崩掉的根源，很多人会写：

ts 复制代码

class EditorWindow {
  currentDoc: Doc
}

短期没问题。但后面一定出现：

WindowA 改状态
WindowB 不同步
多窗口冲突
AI 更新错误实例

最终：

text 复制代码

状态开始分裂

这是最危险的。

六、真正正确的结构：Window 无状态化

正确模型：

text 复制代码

Window 只负责 UI
Workspace 才拥有状态

例如：

ts 复制代码

class EditorWindow {

  constructor(
    private workspace: Workspace
  ) {}

}

Window 永远通过：

ts 复制代码

workspace.state

获取数据。而不是：

ts 复制代码

this.state

自己维护。

七、多窗口同步的真正原理

很多人会问：

多窗口为什么能实时同步？

原因其实很简单：

text 复制代码

它们根本不是"同步"

而是：

text 复制代码

共享同一个状态源

例如：

ts 复制代码

workspace.currentFile = file

所有窗口：

text 复制代码

自动响应

因为：

text 复制代码

UI = State Projection

八、焦点系统：为什么会越来越复杂

一旦进入多窗口：

text 复制代码

焦点问题会指数级上升

因为 PC 存在：

键盘焦点
输入法焦点
Workspace 焦点
Window 激活焦点
Panel 焦点

传统项目：

text 复制代码

每个窗口自己管理

后期一定崩。

正确做法：FocusCenter

真正稳定的结构：

ts 复制代码

class FocusCenter {
  activeWorkspace: string
  focusedComponent: string
}

所有窗口：

text 复制代码

共享同一个焦点系统

九、多窗口真正难的，不是 UI，而是"状态隔离"

很多人误以为：

text 复制代码

多窗口难在布局

其实真正难的是：

text 复制代码

哪些状态共享
哪些状态隔离

例如：

应该共享：

text 复制代码

用户
权限
文档
AI 上下文

应该隔离：

text 复制代码

窗口布局
焦点
滚动位置
临时 UI 状态

如果不分层：

text 复制代码

系统一定混乱

十、多窗口 + AI：为什么传统架构会瞬间崩

传统页面系统：

text 复制代码

AI 不知道当前真正上下文

因为：

页面太多
Router 太复杂
状态分散

AI 很容易：

text 复制代码

改错窗口

Workspace 模型下

AI 可以直接：

ts 复制代码

workspace.currentTask
workspace.currentDocument
workspace.currentSelection

然后：

text 复制代码

精准修改状态

所有窗口自动刷新。

十一、真正稳定的多窗口架构

后来很多成熟项目都会逐渐演变成：

text 复制代码

GlobalState
   ↓
WorkspaceCenter
   ↓
FocusCenter
   ↓
WindowManager
   ↓
ArkUI

GlobalState

负责：

text 复制代码

全局系统状态

WorkspaceCenter

负责：

text 复制代码

任务上下文

FocusCenter

负责：

text 复制代码

输入路由

WindowManager

负责：

text 复制代码

窗口生命周期

十二、为什么鸿蒙 PC 本质更像"系统"

因为：

text 复制代码

Window 已经不是核心单位

真正核心的是：

状态流
Workspace
Focus
Task
Intent

这已经不是：

text 复制代码

传统 App 架构

而是：

text 复制代码

系统级运行模型

十三、总结

如果用一句话总结鸿蒙 PC 多窗口：

窗口只是表象，真正运行的是"状态系统"。

很多项目后期崩掉，不是因为：

Window 太多
ArkUI 太复杂
PC 太难

真正原因只有一个：

text 复制代码

系统没有统一状态中心

真正稳定的鸿蒙 PC 多窗口架构，一定具备：

Workspace 中心化
Window 无状态化
Focus 集中化
状态分层
Task 驱动
UI 投影化

因为：

text 复制代码

Window 可以有很多个
但状态中心只能有一个

最终你会发现：

鸿蒙 PC 多窗口真正改变的，不是"窗口数量"。

而是：

应用开始从"页面系统"，进化成"状态运行系统"。