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

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

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

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

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

引言

很多人第一次接触鸿蒙 PC 多屏协同时，最容易产生一种误解：

多屏协同
=
屏幕投屏

于是会觉得：

• 手机画面显示到 PC
• 平板画面显示到 PC
• 拖个文件过去

好像事情就结束了，但真正做过鸿蒙项目后你会发现：

投屏只是最表层的能力。

鸿蒙多屏协同真正厉害的地方其实是：

设备之间共享状态

而不是：

设备之间共享画面

这两者看起来差不多，实际上完全不是一个东西。因为：

• 共享画面是显示层能力
• 共享状态是系统层能力

而鸿蒙 PC 的多屏协同，本质上属于后者。

一、先理解一个问题：为什么传统投屏做不到真正协同

传统方案：

手机
 ↓
视频流
 ↓
PC

例如：

• AirPlay
• Miracast
• Chromecast

本质都是：

传输画面

PC 看到的是：

视频

而不是：

应用

所以：

• 无法共享状态
• 无法共享组件
• 无法共享任务

更无法做到：

手机继续运行
PC 接管操作

二、鸿蒙多屏协同真正传输的是什么

很多人以为：

传输的是画面

实际上：

传输的是 Ability Context

也就是：

应用运行上下文

例如，手机上：

订单页面

当前状态：

{
  orderId: 1001,
  userId: 888,
  selectedProducts: [...]
}

当用户拖到 PC，真正同步的是：

OrderContext

而不是：

页面截图

因此：PC 能直接继续操作。

三、多屏协同的核心架构

整体结构大概如下：

Device A
   ↓
Distributed Runtime
   ↓
Distributed Scheduler
   ↓
Device B

内部实际上包含：

设备发现
设备认证
能力同步
状态同步
任务调度
生命周期管理

所以：

鸿蒙多屏协同本质是一个分布式系统。

而不是：

投屏系统

四、设备发现机制

首先需要找到周围设备，鸿蒙提供：

import distributedDeviceManager

设备发现：

import { deviceManager } from '@kit.DistributedServiceKit'

async function discoverDevices() {
  const manager =
    deviceManager.createDeviceManager("demo")

  manager.startDeviceDiscovery(
    deviceManager.DiscoverMode.DISCOVER_MODE_ACTIVE,
    {
      discoverTargetType:
        deviceManager.DiscoverTargetType
          .DISCOVER_TARGET_TYPE_ALL
    }
  )
}

发现后：

手机
平板
PC
智慧屏

都会出现在设备列表。

五、设备认证

发现设备不代表能直接通信，鸿蒙会建立：

Trust Relationship

即：

可信设备关系

流程：

发现设备
 ↓
认证
 ↓
授权
 ↓
建立连接

建立成功后：

Device ID

会加入分布式网络。

六、状态同步架构

这是整个系统最关键的一层，很多项目会这样写：

@State userInfo: User

如果要跨设备，必须进入：

Distributed Data Layer

例如：

import distributedKVStore

创建数据库：

const manager =
  distributedKVStore.createKVManager(config)

获取 Store：

manager.getKVStore(
  {
    storeId: "user_store",
    securityLevel:
      distributedKVStore.SecurityLevel.S1
  },
  callback
)

写入：

store.put("user", userInfo)

读取：

store.get("user")

此时：

手机更新
 ↓
PC同步
 ↓
平板同步

状态保持一致。

七、一个完整同步流程

例如，用户修改昵称。

手机：

store.put(
  "nickname",
  "OpenHarmony"
)

同步：

Phone
 ↓
KV Store
 ↓
Distributed Runtime
 ↓
PC
 ↓
Pad

UI：

@State nickname = ""

aboutToAppear() {
  loadNickname()
}

自动刷新：

无需手动同步

八、跨设备拖拽是怎么实现的

这是大家最感兴趣的功能。例如，手机图片拖到 PC。

表面：

拖拽

实际上：

Context Transfer

流程：

Drag Start
 ↓
Context Serialize
 ↓
Distributed Transport
 ↓
Drop Target
 ↓
Context Restore

示例：

onDragStart(() => {
  return {
    data: this.fileInfo
  }
})

PC：

onDrop((event) => {
  const file = event.data
})

体验：

像本地拖拽一样

九、Workspace 才是真正未来

未来不会是：

手机应用
PC应用
平板应用

而是：

Workspace

例如，当前工作区：

会议纪要
AI助手
邮件
文档

状态：

统一保存

当你从手机切到 PC，恢复的是：

Workspace

而不是：

页面

这才是鸿蒙协同真正厉害的地方。

十、多屏协同与 AI 的结合

这里会出现一个非常大的变化。

过去：

设备同步状态

未来：

AI同步上下文

例如，手机：

帮我整理会议记录

AI 已经完成：

• 会议分析
• 待办生成
• 日程规划

当用户来到 PC，AI Runtime 直接恢复：

当前上下文

无需重新开始，本质：

同步的是 AI Context

而不是：

同步聊天记录

十一、推荐项目架构

不要这样：

page/

全部塞页面，推荐：

src
├── workspace
├── store
├── distributed
├── system
├── ai
├── task
└── ui

其中：

Workspace

管理工作区状态

Store

管理业务状态

Distributed

负责同步

System

处理业务逻辑

Task

跨设备任务流转

这样未来扩展：

• PC
• 手机
• 平板
• AI Agent

都会轻松很多。

十二、实际开发最容易踩的坑

坑一：同步 UI 状态

错误：

@State showDialog

同步到其它设备，结果：

状态混乱

应该同步：

业务状态

而不是：

UI状态

坑二：全量同步

错误：

store.put("all", bigObject)

结果：

同步性能下降

应该：

增量同步

坑三：把协同当投屏

结果：

架构完全走偏

因为：

多屏协同本质是状态同步。

不是画面同步。

十三、总结

如果一句话总结：

鸿蒙 PC 多屏协同的核心，不是“多个屏幕”。

而是：

多个设备共享同一个状态世界

过去：

一个设备
一个应用
一个状态

未来：

多个设备
一个Workspace
一个Runtime

这是根本变化。

很多人第一次看到鸿蒙多屏协同时，关注的是：

• 拖文件
• 拖窗口
• 投屏

但这些都只是表象，真正重要的是：

分布式状态
+
Workspace Runtime
+
跨设备 Context

未来的软件很可能不再是：

我在哪个设备打开应用

而是：

我在哪个设备进入同一个工作空间

而鸿蒙 PC 的多屏协同，正是在为这种软件形态提供底层基础设施。