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

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

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

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

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

引言

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

不就是“再开一个窗口”吗？

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

WindowA
WindowB
WindowC

每个窗口：

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

刚开始看起来没问题。

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

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

最后团队会发现：

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

而是：

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

因为在鸿蒙 PC 上：

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

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

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

Window = 独立上下文

例如：

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

典型结构：

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

这种模式最大的问题：

窗口之间天然隔离。

所以后面一定会出现：

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

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

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

Window 是系统核心

但在鸿蒙 PC：

真正的核心，其实是 Workspace。

Window 只是：

Workspace 的可视化投影

三、什么是 Workspace？

你可以把它理解成：

一个“运行中的状态空间”

例如：

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

这里最关键的一点：

Window 不拥有状态。

真正拥有状态的是：

Workspace

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

很多人以为：

多窗口 = 创建多个 Window

其实真正结构更像：

GlobalState
      ↓
Workspace
      ↓
Window
      ↓
ArkUI

也就是说：

1、GlobalState

负责：

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

例如：

globalStore.user

2、Workspace

负责：

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

例如：

workspace.activeDocument

3、Window

只负责：

状态显示

本身不应该：

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

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

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

class EditorWindow {
  currentDoc: Doc
}

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

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

最终：

状态开始分裂

这是最危险的。

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

正确模型：

Window 只负责 UI
Workspace 才拥有状态

例如：

class EditorWindow {

  constructor(
    private workspace: Workspace
  ) {}

}

Window 永远通过：

workspace.state

获取数据。而不是：

this.state

自己维护。

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

很多人会问：

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

原因其实很简单：

它们根本不是“同步”

而是：

共享同一个状态源

例如：

workspace.currentFile = file

所有窗口：

自动响应

因为：

UI = State Projection

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

一旦进入多窗口：

焦点问题会指数级上升

因为 PC 存在：

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

传统项目：

每个窗口自己管理

后期一定崩。

正确做法：FocusCenter

真正稳定的结构：

class FocusCenter {
  activeWorkspace: string
  focusedComponent: string
}

所有窗口：

共享同一个焦点系统

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

很多人误以为：

多窗口难在布局

其实真正难的是：

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

例如：

应该共享：

用户
权限
文档
AI 上下文

应该隔离：

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

如果不分层：

系统一定混乱

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

传统页面系统：

AI 不知道当前真正上下文

因为：

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

AI 很容易：

改错窗口

Workspace 模型下

AI 可以直接：

workspace.currentTask
workspace.currentDocument
workspace.currentSelection

然后：

精准修改状态

所有窗口自动刷新。

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

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

GlobalState
   ↓
WorkspaceCenter
   ↓
FocusCenter
   ↓
WindowManager
   ↓
ArkUI

GlobalState

负责：

全局系统状态

WorkspaceCenter

负责：

任务上下文

FocusCenter

负责：

输入路由

WindowManager

负责：

窗口生命周期

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

因为：

Window 已经不是核心单位

真正核心的是：

• 状态流
• Workspace
• Focus
• Task
• Intent

这已经不是：

传统 App 架构

而是：

系统级运行模型

十三、总结

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

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

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

• Window 太多
• ArkUI 太复杂
• PC 太难

真正原因只有一个：

系统没有统一状态中心

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

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

因为：

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

最终你会发现：

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

而是：

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