本文基于 OpenHarmony 开源仓库 communication_dsoftbus 的实际源码整理,覆盖 3700+ 文件的核心脉络。
适合想入门分布式软总线、又被源码量劝退的开发者。


一、一个被忽略的问题

你有没有想过,鸿蒙的"超级终端"里,手机和智慧屏是怎么连上的?

不是蓝牙配对那么简单。也不是 Wi-Fi 直连那么粗暴。

背后有一套叫分布式软总线(DSoftBus)的东西在默默工作——它屏蔽了 Wi-Fi、蓝牙、BLE、WiFi Direct 等链路差异,向上提供统一的发现 → 组网 → 传输能力。

听起来像不像一个"通信瑞士军刀"?

但问题来了:这个仓库有 3700+ 文件。打开源码目录的那一刻,我和大多数人一样——关掉了。

后来我发现了一个秘密:不用逐行读源码。仓库自带了一套领域知识文档(docs/knowledge/),那是比源码更高效十倍的学习入口。

这篇文章,就是我把那 3700+ 文件"嚼碎"后,给你留的一条路。


二、软总线到底干了什么

一句话:让业务"不感知链路、不感知介质"即可跨设备通信。

三大能力,对应三个你一定见过的场景:

能力做什么你见过的场景
发现多介质设备发现手机搜索附近的智慧屏
组网统一拓扑、节点上下线超级终端设备列表
传输跨设备消息/字节/流多屏协同、跨设备拖拽

分层架构很清晰:

应用层 → SDK → core(服务层)→ adapter(适配层)→ OS

每一层职责分明。你不需要一开始就搞懂所有层,先记住这条主干就够了。


三、发现:四种媒介,一个策略

发现模块是我觉得设计得最优雅的部分。

它支持四种媒介:BLE / CoAP / USB / NFC,但上层完全不需要知道底下用的是哪种。

怎么做到的?策略模式。

四层架构,逐层递进:

L1 管理器(统一调度)
  → L2 媒介实现(BLE/CoAP/USB/NFC 各干各的)
    → L3 通道池(广播/扫描资源管理)
      → L4 OS 适配(对接系统蓝牙/Wi-Fi)

这里有个有趣的细节:BLE 发现用的是能力位图——把设备能力编码成 bit 位,塞进广播包里。别人扫到你的广播,就知道你支持什么能力,不用建立连接。

想想看,这就像你胸前挂了个牌子,上面用图标标明了你会的技能——路过的人一眼就知道能不能找你合作。

关键 API 就两个:PublishLNN(发布)和 RefreshLNN(发现)。


四、组网:认证才是重头戏

发现到设备只是第一步。要真正"组网",还有一道绕不过去的坎——认证。

组网的核心 API 是 JoinLNN。但很多人不知道,JoinLNN 内部有一个必须的前置步骤:

JoinLNN → 认证(必须先通过)→ 拓扑同步 → 节点上线

认证由一个 4 状态有限状态机驱动:

SYNC_NEGOTIATION → SYNC_DEVICE_ID → DEVICE_AUTH → SYNC_DEVICE_INFO
   认证参数协商      设备ID同步       设备认证        设备信息同步

这个状态机对接了一个叫 HiChain 的安全引擎(来自 security_device_auth 仓库),支持三种认证协议:

协议PIN 码要求特点
EC-SPEKE≥ 6 bit椭圆曲线 SPEKE,最常用
DL-SPEKE≥ 6 bit离散对数 SPEKE
ISO≥ 128 bitISO 标准协议

你不需要记住这些协议的数学原理。你只需要知道:没配对过的设备,组网会失败。这是分布式通信的安全基石。


五、配对:比你想的更复杂

"配对"听起来很简单——输入个 PIN 码嘛。但背后的流程,涉及两个角色和三个弹窗。

两个角色

角色职责通俗理解
source主动发起配对你手机上点"添加设备"
sink被动接受配对智慧屏上弹出"是否允许"

三个弹窗

  1. 授权确认(sink 端):“是否允许与该设备建立可信关系?”
  2. PIN 码显示(sink 端):显示 6 位 PIN 码
  3. PIN 码输入(source 端):用户输入 PIN 码

这就像你去别人家做客:先敲门(授权确认),主人开门给你看门牌号(PIN 显示),你对照门牌号输入(PIN 输入),对了就让你进。

配对成功后,互信关系持久化存储,后续不用再配。但每次 JoinLNN 组网时,还会自动触发一次认证(基于已有互信关系协商会话密钥)。

两个层面,别搞混:

配对(一次性)→ 建立互信关系 → 持久化
认证(每次组网)→ 基于互信关系 → 协商会话密钥

六、三层接口:你该用哪层?

设备配对有三层接口,对应不同开发者:

JS/ArkTS 应用     →  @ohos.distributedDeviceManager    (三方应用)
C++ 系统工具      →  DeviceManager 类                  (系统服务、无界面)
C HiChain 引擎    →  DeviceGroupManager                (底层认证)

应用开发者:用 JS 接口

import { distributedDeviceManager } from '@kit.DistributedServiceKit';

let dm = distributedDeviceManager.createDeviceManager('com.example.myapp');
dm.startDiscovering(...);        // 发现
dm.bindTarget(deviceId, ...);    // 配对
dm.on('deviceStateChange', ...); // 监听上线

权限:ohos.permission.DISTRIBUTED_DATASYNC

系统开发者:用 C++ 接口

无界面设备(嵌入式、HEAD LESS)没有 UI 弹窗,需要用 C++ Native Inner API:

DeviceManager::GetInstance().InitDeviceManager(pkgName, callback);
DeviceManager::GetInstance().BindTarget(pkgName, targetId, bindParam, bindCb);
DeviceManager::GetInstance().SetUserOperation(pkgName, 5, "343434"); // PIN 输入

关键:需要通过 NativeToken 设置 system_core 权限等级 + 5 个权限。

⚠️ 版本提醒:如果你手上的 C++ 代码是 OpenHarmony 4.1 的,部署到 6.1/7.0 前要注意——PinHolderCallback 新增了 OnPinHolderEvent 纯虚函数,不实现会编译失败。好在 5.0 之后 API 就稳定了,6.1 和 7.0 完全一致。

底层开发者:用 HiChain C 接口

两组 API:

  • DeviceGroupManager(GetGmInstance()):群组管理,配对入口
  • GroupAuthManager(GetGaInstance()):群组认证,组网认证入口

应用开发者一般不需要直接调这层。


七、传输:两套接口,四种通道

组网成功后,就到了传输层。

两套接口:

  • Session:老接口,面向流
  • Socket:新接口,面向连接(推荐)

四种通道:

通道适用场景
TCP大数据量、可靠传输
UDP实时数据、允许丢包
Proxy小消息、控制信令
Auth加密通道

传输模块会根据数据类型和 QoS 要求自动选路——你不需要手动指定用 TCP 还是 UDP。

这就像寄快递:你只管填收件人地址,快递公司自己决定走空运还是陆运。


八、学习路线:别从源码开始

最后,给你一条不走弯路的路线:

阶段零  先搞懂配对(否则组网必失败)
        ↓
阶段一  建立主干认知(发现→组网→传输)
        ↓
阶段二  逐模块深读(先读知识文档,再看源码)
        ↓
阶段三  动手跑通 Demo
        ↓
阶段四  按需深入源码

最重要的建议

  1. 先读 docs/knowledge/,不要直接啃源码。每个模块都有 *_knowledge.md,包含架构、数据流、设计模式。
  2. 先理解 API 再看实现。源码最终服务于 API,先搞懂 API 用法,再回头看实现,事半功倍。
  3. 别跳过配对。很多人直接学软总线 API,然后 JoinLNN 失败——因为设备没配对。
  4. 选对分支。学习最新特性用 master,稳定学习用 OpenHarmony-6.1-LTS。

仓库推荐

仓库作用
communication_dsoftbus软总线主仓(本文核心)
security_device_auth设备互信认证引擎(HiChain)
distributedhardware_device_manager设备管理器(JS/C++ 接口)

写在最后

软总线的 3700+ 文件看着吓人,但核心脉络就一条线:

配对(建立互信)→ 发现(找到设备)→ 组网(JoinLNN)→ 传输(Socket)

每个环节都有知识文档做向导,不需要在源码里迷路。

如果你正在做鸿蒙分布式开发,希望这条路线能帮你少走几周弯路。


如果觉得有帮助,点赞收藏关注三连和加微信公众号(不定时分享),后续会继续分享鸿蒙源码学习笔记。

在这里插入图片描述

Logo

讨论HarmonyOS开发技术,专注于API与组件、DevEco Studio、测试、元服务和应用上架分发等。

更多推荐