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

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

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

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

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

引言

很多人第一次接触 HarmonyOS 分布式能力时，都会觉得特别“未来”。

比如：

• 手机继续 PC 上的任务
• 平板拖内容到电脑
• 多设备共享状态
• 一个任务跨设备流转

看起来像：

“系统魔法”

于是很多团队第一反应是：

太高级了，先不用。

还有一些团队会觉得：

“是不是把数据同步一下就叫分布式？”

结果真正做项目之后，很快就会发现：

• 状态同步越来越乱
• 多设备冲突越来越多
• Workspace 完全无法恢复
• 焦点系统直接崩
• AI Task 不知道在哪个设备执行

最后大家会慢慢意识到：

分布式真正难的，从来不是“通信”。

而是：

状态世界如何跨设备存在

因为在鸿蒙 PC 上：

分布式能力，本质上不是“设备互联”。

而是：

多设备状态 Runtime

一、很多人理解错了“分布式”

很多团队最开始理解：

分布式
=
设备之间传数据

例如：

deviceA.send(data)

但真正大型鸿蒙项目后期会发现：

数据同步只是最浅的一层。

真正复杂的是：

• Workspace
• Focus
• Task
• 状态流
• Runtime 生命周期

这些东西：

才是真正的“系统状态”

二、传统同步模型为什么会崩

很多项目最开始：

手机改数据
 ↓
同步给 PC
 ↓
PC 更新 UI

看起来没问题，但后面：

• 多窗口
• AI Task
• 多 Workspace
• 多用户动作

一进来：

整个系统直接混乱

因为：

你同步的是“数据”。

但真正需要同步的是：

状态上下文

三、鸿蒙 PC 的真正分布式核心：Workspace

做到后面我们终于发现：

分布式最核心的单位，不应该是“页面”。

而应该是：

Workspace

因为用户真正连续使用的是：

• 当前任务
• 当前布局
• 当前焦点
• 当前上下文

而不是：

某一个页面

四、为什么“页面同步”一定会失败

很多团队：

手机打开 PageA
PC 打开 PageA

觉得这叫：

多端同步

但问题马上出现：

• PC 是多窗口
• 手机是单窗口
• 焦点系统完全不同
• 布局结构完全不同

结果：

同步逻辑越来越诡异

因为：

页面根本不是稳定抽象。

真正稳定的是：

任务状态

五、真正正确的模型：同步“任务世界”

后来我们整个架构改成：

Task
 ↓
Workspace
 ↓
UI Projection

而不是：

Page
 ↓
Page

这一步非常关键。

六、第一个关键能力：分布式状态层

很多项目：

本地 Store

和：

远程同步

完全耦合，结果：

• 状态覆盖
• 冲突失控
• Workspace 崩坏

后来我们拆成：

LocalState

负责：

• UI
• Focus
• Layout

DistributedState

负责：

• 用户数据
• Task
• 会话上下文

ProjectionState

负责：

不同设备上的 UI 映射

之后系统稳定很多。

七、第二个关键能力：设备不是“主从关系”

很多团队会天然这样设计：

手机是主设备
PC 是副设备

或者：

PC 才是核心

但真正做大之后会发现：

这种设计一定会崩。

因为：

• 用户会切设备
• AI 会跨设备执行
• Workspace 会迁移
• Task 会漂移

所以真正合理的模型应该是：

设备只是 Runtime 节点

而不是：

系统中心

八、第三个关键能力：Task 才是分布式核心

这是后来最大的认知变化，以前：

同步页面

后来：

同步任务

例如：

手机

开始写文档

PC

继续：

编辑 Workspace

平板

继续：

手写批注

这里真正连续的是：

Task Context

不是：

页面

九、第四个关键能力：Focus 不允许跨设备同步

这个坑特别大，很多团队最开始：

同步当前焦点

结果：

• 手机输入抢走 PC 焦点
• 键盘输入漂移
• Workspace 输入错乱

后来我们彻底定规则：

Focus 永远是“设备本地状态”。

不能：

全局同步

这是非常关键的一步。

十、第五个关键能力：Layout 必须设备投影化

很多人最开始：

所有设备共享布局

结果：

• 手机直接崩
• 平板布局错乱
• PC Workspace 失控

后来：

Layout Projection

例如，同一个 Task：

• PC
• 手机
• 平板

拥有不同 UI 投影

但共享：

同一状态世界

这才是真正合理的分布式。

十一、第六个关键能力：AI Runtime 分布式化

这是未来最重要的一层，很多人以为：

AI 只能本地跑

实际上真正未来会变成：

手机

负责：

轻交互

PC

负责：

复杂 Workspace

云端

负责：

大模型推理

整个 AI Runtime：

天然分布式

所以鸿蒙分布式真正未来不是：

多设备同步

而是：

多 Runtime 协同

十二、为什么很多分布式项目后期会崩

因为大家同步的是：

• 页面
• UI
• ViewState

但真正应该同步的是：

• Task
• Workspace
• 状态上下文
• Runtime 生命周期

否则：

系统一定越来越混乱

十三、后来我们彻底改变了分布式架构

从：

Device A
 ↕
Device B

变成：

Distributed Runtime
 ↓
Workspace
 ↓
Task Context
 ↓
Device Projection

之后：

• 多设备稳定很多
• Workspace 更自然
• AI 更容易协同
• UI 不再互相污染

整个系统开始真正：

像“系统”
而不是“同步工具”

十四、鸿蒙分布式真正厉害的地方

很多人觉得：

分布式 = 文件共享

其实完全不是，真正厉害的是：

它允许“状态世界”跨设备存在。

也就是说：

用户的“工作上下文”

不再属于：

• 手机
• PC
• 平板

而属于：

整个 Runtime 世界

这是一个非常大的变化。

十五、总结

如果一句话总结：

鸿蒙分布式真正同步的，不是“页面”，而是“状态世界”。

包括：

• Workspace
• Task
• Context
• Runtime
• AI State

这些：

才是真正的系统核心

后来我们终于意识到：

鸿蒙分布式
不是“设备互联”

而是：

多设备状态 Runtime

所以真正重要的，不是：

• 页面同步
• UI 同步

而是：

• Workspace 连续性
• Task 流转
• Runtime 协同
• 状态上下文共享
• 多设备状态投影

最终你会发现：

真正的未来应用：

不再属于某一个设备

而是：

存在于整个分布式状态系统之中