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

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

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

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

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
📣 公众号“Swift社区”，每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。
💬 微信端添加好友“fzhanfei”，与我直接交流，不管是项目瓶颈的求助，还是行业趋势的探讨，随时畅所欲言。
📅 最新动态：2025 年 3 月 17 日
快来加入技术社区，一起挖掘技术的无限潜能，携手迈向数字化新征程！

引言

很多团队第一次把鸿蒙应用做成 PC 形态时，都会下意识地这样理解：

“无非就是窗口多一点、交互复杂一点。”

于是架构策略通常是：

• 在原有 App 架构上继续加层
• 给页面补多窗口能力
• 给状态补跨窗口同步
• 给交互补键盘与焦点

短期确实能跑。

但只要项目继续增长，你一定会撞上一面非常硬的墙：

• 窗口越来越多，却没有真正的“主线”
• 状态越来越全，却越来越难保证一致
• 生命周期越来越细，却越来越难预测行为

直到某个阶段你才真正意识到：

问题不是 PC 更复杂，而是你还在用“App 的世界观”构建 PC。

而 PC 架构真正的起点，从来不是窗口系统，也不是页面系统——

而是任务系统。

第一层误区：把“窗口”当成系统核心

很多 PC 适配项目，最先重构的是窗口层：

windowManager.open('editor')
windowManager.open('chat')
windowManager.open('preview')

看起来已经很像桌面应用，但很快问题出现：

• 同一个文件在不同窗口状态不同
• 关闭窗口后任务直接消失
• 后台运行逻辑无法归属
• 焦点切换影响业务流程

这说明一件事：

窗口只是显示容器，并不是系统真正的运行单位。

第二层断裂：App 生命周期无法描述 PC 行为

移动端生命周期是线性的：

Create → Foreground → Background → Destroy

但 PC 完全不同：

• 多窗口可同时存在
• 部分窗口可后台运行
• 任务可能长期驻留
• 系统可能随时回收视图

于是你会发现：

传统 Ability / Page 生命周期，根本无法表达 PC 的真实运行状态。

缺的不是更多回调，而是：

一个更高维度的抽象。

第三层核心：什么才叫“任务系统”

任务系统并不是简单的任务列表，而是一套描述系统正在做什么的最小结构。

它至少包含三件事：

任务身份

type TaskId = string

系统必须回答：

现在有哪些长期存在的运行单元？

例如：

• 编辑任务
• 下载任务
• 聊天会话任务

任务上下文

interface TaskContext {
  data: object
  createdAt: number
}

关键点：

状态属于任务，而不是窗口或页面。

这一步一旦建立：

• 关窗口 ≠ 丢状态
• 切窗口 ≠ 重建流程

任务生命周期（独立于 UI）

enum TaskState {
  Active,
  Background,
  Suspended,
  Destroyed
}

注意这里最重要的设计：

UI 生命周期只是任务生命周期的“投影”。

而不是反过来。

第四层架构跃迁：从 UI 驱动 → 任务驱动

这是鸿蒙 PC 架构真正的分水岭。

旧世界（App 思维）

router.push('/editor')

隐含逻辑：

页面存在 → 业务存在
页面销毁 → 业务结束

新世界（PC 思维）

taskManager.start('editor', { fileId: '123' })

UI 只是附着其上的视图：

window.bind(taskId)

此时系统行为完全改变：

• 任务先存在，UI 后出现
• UI 可以消失，任务仍继续
• 多个 UI 可观察同一任务

这才是标准 PC 架构的运行方式。

第五层稳定性的真正来源

很多团队误以为 PC 稳定性来自：

• 更严格的状态管理
• 更复杂的生命周期控制
• 更完整的日志系统

但真正的稳定性只来自一件事：

系统行为是否以“任务”为最小单位收敛。

当任务系统成立后：

焦点问题自然收敛

焦点只属于 当前激活任务

多窗口问题自然收敛

窗口只是 任务视图

状态一致性自然收敛

状态绑定 任务上下文

生命周期混乱自然消失

生命周期属于 任务本身

这就是为什么：

任务系统一旦建立，整个 PC 架构会突然“安静下来”。

第六层现实门槛：为什么很少项目真正做到

因为任务系统有一个非常残酷的特点：

它几乎等同于重做一遍架构。

你需要：

• 重定义状态归属
• 重构路由模型
• 重写窗口关系
• 重建生命周期边界

这意味着：

它无法通过“局部优化”获得。

只能：

整体跃迁。

所以大多数项目会停在：

多窗口 + 状态补丁，而不是真正的 PC 架构。

总结

其实整条鸿蒙 PC 架构主线已经完全展开：

• 三层解耦 → 解决代码结构
• 焦点系统 → 解决交互控制
• 状态一致性 → 解决数据稳定
• 生命周期统一 → 解决运行边界
• 任务系统 → 定义系统本体

也就是说：

鸿蒙 PC 架构真正的起点，从来不是“把 App 做成窗口应用”，而是——让系统以任务为中心运行。

当这一层建立后，你才真正跨过那条隐形边界：

从 App，走向 PC 级软件。