企业官网建设流程全解析

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

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

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

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

引言

很多开发者第一次接触鸿蒙分布式能力的时候，会有一种错觉：

文件共享 = 网络传输

于是第一反应往往是：

HTTP WebSocket FTP NAS

但如果你真正体验过鸿蒙 PC 的跨设备协同，就会发现它和传统文件传输完全不是一个东西。

例如：你正在鸿蒙 PC 上编辑文档，突然想把图片插进去。

过去：

打开手机 ↓ 找到图片 ↓ 发送到电脑 ↓ 保存本地 ↓ 插入文档

而鸿蒙 PC 上：

手机图片 ↓ 直接拖到电脑 ↓ 完成

用户甚至感觉不到：

文件正在传输

仿佛文件本来就存在于同一个系统里。这背后真正发生的事情，其实是鸿蒙最核心的能力之一：

Distributed File Runtime

也就是：

文件不再属于设备，而属于分布式状态空间。

而这，正是鸿蒙 PC 文件共享体验远超传统方案的根本原因。

一、传统文件共享为什么体验差

过去几十年里，文件共享本质都是：

设备 A ↓ 网络 ↓ 设备 B

例如：

微信传文件 AirDrop 网盘 FTP NAS

底层逻辑几乎一致：

Copy

即：

复制一份数据

所以用户总会遇到：

文件版本混乱

方案.doc 方案(最终版).doc 方案(最终版2).doc 方案(最终版终极版).doc

重复存储

手机一份 电脑一份 平板一份

同步延迟

修改完成 ↓ 等待上传 ↓ 等待同步

本质原因在于：

文件属于设备

设备才是中心。

二、鸿蒙文件共享为什么不一样

鸿蒙从设计之初就没有把设备当核心，它真正的核心是：

分布式状态

所以文件共享变成：

设备A \ \ Distributed Runtime / / 设备B

此时：

文件属于 Runtime

而不是：

文件属于某台设备

因此用户感知到的是：

一个统一文件空间

而不是：

多个设备之间传文件

三、分布式文件机制的核心架构

从架构角度看：

Application ↓ Distributed File Service ↓ Device Manager ↓ SoftBus ↓ Remote Device

其中：

Device Manager

负责发现设备

例如：

手机 平板 PC 智慧屏

上线后自动加入设备网络。

SoftBus

鸿蒙最重要的底层能力之一。

负责：

发现 连接 认证 传输

开发者无需关心：

WiFi 蓝牙 NFC P2P

统一由 SoftBus 调度。

Distributed File Service

负责：

文件映射 同步 状态管理

用户看到的是：

一个文件

系统看到的是：

分布式资源

四、跨设备拖拽到底发生了什么

很多人以为：

拖拽 = 复制文件

实际上远比这复杂，例如：

手机图片 ↓ 拖到鸿蒙PC

系统内部大概会经历：

发现资源 ↓ 生成资源描述 ↓ 建立设备连接 ↓ 传输数据流 ↓ 映射到目标设备 ↓ 更新状态

即：

Resource ↓ Runtime ↓ Projection

这里共享的已经不仅是：

文件

而是：

文件状态

五、Demo：发现远程设备

下面通过一个简化版 Demo 理解流程。

获取设备列表

importdeviceManagerfrom'@ohos.distributedDeviceManager';asyncfunctiongetDevices(){constmanager=deviceManager.createDeviceManager("com.demo.fileshare");constdevices=manager.getAvailableDeviceList();devices.forEach(device=>{console.info(device.deviceName);});}

运行后：

Huawei MatePad Huawei Phone HarmonyOS PC

即可获取在线设备。

六、Demo：建立设备连接

设备发现以后：

importrpcfrom'@ohos.rpc';asyncfunctionconnectRemote(deviceId:string){console.info(`connect device :${deviceId}`);}

实际项目通常通过：

DeviceManager + SoftBus

建立可信连接。

七、Demo：发送文件任务

例如：

interfaceFileTask{sourcePath:string;targetDeviceId:string;}

创建任务：

consttask:FileTask={sourcePath:"/data/image.png",targetDeviceId:"device001"};

提交：

asyncfunctionsendFile(task:FileTask){console.info(`send file${task.sourcePath}`);}

虽然这里进行了简化，但真实鸿蒙架构中：

文件传输 = 任务调度

而不是：

单纯上传

八、为什么未来会从 File 变成 Resource

这是鸿蒙非常重要的一个趋势。

过去：

File

未来：

Resource

例如，一张图片：

图片文件

AI Runtime 看来却是：

图片 + 标签 + 来源 + 上下文 + 用户状态

于是共享的不再只是：

image.png

而是：

完整 Context

九、AI Runtime 下的文件共享

未来用户可能这样说：

把今天会议资料发给平板

AI Runtime 自动：

找到文档 ↓ 找到录音 ↓ 找到截图 ↓ 找到待办 ↓ 打包 Workspace ↓ 同步到平板

这里用户根本不会关心：

哪些文件被传输了

因为共享对象已经变成：

Workspace

而不是：

File

十、鸿蒙 PC 文件共享的终极形态

做到后面你会发现，过去：

文件共享 = 设备之间复制文件

鸿蒙：

文件共享 = 多个设备访问同一个状态空间

过去：

Device First

未来：

Runtime First

过去：

文件属于设备

未来：

文件属于 Workspace

十一、总结

如果一句话总结鸿蒙 PC 文件共享：

它真正共享的不是文件，而是分布式状态。

很多人第一次看到：

手机图片 ↓ 拖到PC

会认为只是：

传输更快

但本质上完全不同，传统方案：

File Transfer

鸿蒙方案：

Distributed Resource Runtime

传统思维：

设备中心

鸿蒙思维：

状态中心

而随着 AI Runtime 的到来，这种能力还会进一步演进。

未来用户不会再说：

把文件传给电脑

而会说：

把今天工作的内容同步过去

此时同步的已经不是某个文件，而是：

Workspace Task Context State

最终你会发现：

鸿蒙 PC 文件共享最重要的价值，不是“跨设备传文件”。

而是：

让多个设备共同运行同一个状态世界。

这也是鸿蒙分布式能力真正区别于传统文件共享方案的地方。