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

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

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

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

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

引言

很多人第一次看到鸿蒙 PC 的跨设备拖拽时，都会觉得特别震撼。

比如：

• 手机图片直接拖到 PC
• 平板文件拖进鸿蒙 Workspace
• 跨设备文本直接流转
• 多设备之间“像同一个系统”

第一反应通常是：

这是不是系统黑科技？

然后很多人会自然认为：

跨设备拖拽，本质就是“文件传输”。

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

拖拽
 ↓
上传文件
 ↓
另一端下载

短期看能跑，但真正做复杂场景后，很快就会遇到：

• 大文件卡顿
• Workspace 状态丢失
• 焦点错乱
• AI Task 无法接续
• 拖拽过程中 UI 不一致
• 多窗口上下文丢失

最后你会发现：

鸿蒙跨设备拖拽，真正传递的从来不只是“文件”。

而是：

状态上下文

因为在鸿蒙 PC 上：

拖拽本质不是“数据移动”。

而是：

Task Context 的跨设备迁移

一、为什么传统拖拽模型在鸿蒙 PC 上不够用了

传统桌面系统里的拖拽：

鼠标拖动
 ↓
传文件
 ↓
目标接收

本质是：

单机文件操作

但鸿蒙 PC 不一样，因为现在拖拽的可能是：

• AI Task
• Workspace
• 富文本上下文
• 多设备会话
• 分布式状态

也就是说：

拖拽对象已经不再只是“文件”

二、鸿蒙跨设备拖拽真正传递的是什么

很多人最开始理解：

拖拽 = 数据复制

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

真正重要的是：

上下文连续性

例如：

手机用户

编辑一份 AI 会议总结

PC 用户

用户拖过去后：

• 不只是文档内容

• 还包括：

  • 当前光标
  • AI Task
  • Workspace
  • Focus Context

这才是真正复杂的地方。

三、真正的核心：拖拽的是“Task”

后来我们整个架构彻底改了。

从：

Drag File

变成：

Drag Task Context

这一步极其关键。

四、跨设备拖拽的完整架构

后来我们最终稳定下来的模型：

Drag Source
     ↓
Context Snapshot
     ↓
Distributed Runtime
     ↓
Target Projection
     ↓
Workspace Recovery

这里：

真正传输的不是 UI

而是：

状态快照

五、第一个关键点：DragItem 不能只是文件

很多项目：

dragItem = file

短期没问题，但后面：

• AI
• Workspace
• 多窗口

一进来：

系统立刻失控

后来统一：

interface DragContext {
  taskId: string
  workspaceId: string
  payload: any
  focusState?: any
}

真正拖拽的是：

上下文

六、ArkUI 基础拖拽实现

先看一个最基础的拖拽。

拖拽源

Text("拖拽文件")
  .draggable(true)
  .onDragStart(() => {

    const dragData = {
      type: 'text',
      content: 'HarmonyOS PC'
    }

    return {
      builder: () => {
        Text("正在拖拽")
      },
      extraInfo: JSON.stringify(dragData)
    }
  })

这里：

extraInfo

可以理解为：

跨设备状态载体

七、目标区域接收

Column()
  .onDrop((event) => {

    const data = JSON.parse(event.extraInfo)

    console.info(data.content)

  })

这个阶段：

已经可以完成基础跨设备数据传递

但这只是最浅层。

八、真正复杂的部分：Workspace 恢复

很多团队会忽略：

拖拽结束之后
系统怎么恢复上下文

例如：

错误做法

接收到数据
 ↓
直接打开页面

结果：

• 焦点错乱
• Task 丢失
• Workspace 不一致

正确做法

恢复 Workspace Snapshot

例如：

workspaceManager.restore(snapshot)

包括：

• 当前任务
• Focus
• Layout
• Task 状态

一起恢复。

九、第二个关键点：Focus 永远本地化

这是特别容易踩的大坑，很多人：

同步拖拽前焦点

结果：

• PC 抢手机输入
• 键盘事件漂移
• 输入法崩

后来统一规则：

Focus 永远不跨设备同步。

只恢复：

逻辑上下文

而不是：

输入所有权

十、第三个关键点：拖拽的是“引用”而不是“实体”

很多项目：

直接传整个文件

后面：

• 大文件卡死
• 网络阻塞
• 内存暴涨

后来改成：

Context Reference

例如：

{
  taskId: 'task_001',
  resourceId: 'doc_001'
}

真正内容：

后台渐进同步

体验会自然很多。

十一、第四个关键点：拖拽期间 UI 必须“去状态化”

很多项目：

拖拽过程中疯狂更新状态

例如：

• hover
• dragPosition
• layoutState

结果：

ArkUI 持续重建

后来：

DragOverlay Layer

拖拽过程：

完全脱离业务状态

性能会稳定很多。

十二、第五个关键点：跨设备拖拽必须“Task 化”

后来我们整个模型：

从：

拖文件

变成：

拖任务

例如：

拖一个 AI 会话

真正同步：

• Prompt Context
• Message State
• Workspace Snapshot

而不是：

聊天页面

拖一个文档

真正同步：

• 编辑状态
• 当前选区
• 协作 Context

而不是：

单纯文件

十三、为什么鸿蒙拖拽和 Windows 完全不是一个层级

Windows 传统拖拽：

文件操作

鸿蒙跨设备拖拽：

分布式状态迁移

这是本质区别，因为鸿蒙真正想实现的是：

用户“工作世界”的连续性。

而不是：

文件复制

十四、AI 会让拖拽彻底升级

未来最重要的一层：

AI Context Drag

例如：

手机用户

正在分析会议记录

PC 用户

拖过去后：AI 不只是继续聊天。而是：

• 保留推理上下文
• 保留任务状态
• 保留工具调用链

这时候真正迁移的是：

AI Runtime Context

这会是未来最重要的方向。

十五、完整实战结构

最终推荐的跨设备拖拽结构：

drag/
 ├── DragContext.ts
 ├── DragSnapshot.ts
 ├── DragRuntime.ts
 ├── WorkspaceProjection.ts
 ├── DistributedTransfer.ts
 └── DragOverlay/

核心原则：

拖拽只负责“上下文迁移”

而不是：

页面复制

十六、总结

如果一句话总结鸿蒙 PC 跨设备拖拽：

真正被拖动的，不是文件。

而是：

状态上下文

包括：

• Task
• Workspace
• AI Context
• Runtime State
• Layout Projection

这些：

才是真正的系统核心

后来我们终于意识到：

鸿蒙跨设备拖拽
不是“传文件”

而是：

分布式 Runtime 的上下文迁移

所以真正重要的，不是：

• 文件怎么传
• UI 怎么拖

而是：

• Workspace 如何恢复
• Task 如何连续
• Context 如何迁移
• Runtime 如何协同

最终你会发现：

真正未来的应用：

用户拖动的
已经不是“数据”

而是：

整个工作状态世界