第一部分 层级通信

一、核心思想：架构延伸与范式统一

鸿蒙的通信架构可以被看作是Android Binder范式的一次大规模延伸与统一。它将Android成熟的单设备内IPC（进程间通信） 范式，通过一套新的中间层，扩展为了跨设备的RPC（远程过程调用） 范式，并致力于让开发者觉得这两种调用没有区别。

为了方便类比理解，下表是整个架构的对比概览：

通信层级 Android (类比) HarmonyOS (对应架构) 核心思想与关系
应用层 (逻辑单元) Activity, Service Ability (FA/PA) 从Android的组件模型演进而来，是调度和通信的基本单元。
框架层 (编程接口) Android SDK (Java/Kotlin API) ArkUI/Ability框架 (ArkTS/JS/Java API) 为应用开发者提供统一的编程接口，封装底层通信复杂性。
服务管理层 (服务目录) ServiceManager System Ability Manager (SAMgr) 架构核心类比点：功能完全对等，是系统的“服务电话簿”，负责系统服务的注册、发现和管理。
IPC/RPC 核心层 (通信机制) Binder 驱动 1. 单设备：Binder-like驱动 2. 跨设备：分布式软总线 (DSoftBus) 架构演进关键：在单设备保留高性能Binder-like机制；通过DSoftBus将“进程”概念扩展为“设备”，实现跨设备Binder式调用。
接口契约层 AIDL (Android Interface Definition Language) 鸿蒙 IDL 设计理念一致：用于严格定义服务接口，保证通信双方的类型安全，是生成Proxy/Stub代码的契约。

二、逐层深入：与Android的详细对比

1. 服务管理层：从ServiceManager到SAMgr

这是理解上下层通信的第一个枢纽，两者角色完全一致。

  • Android ServiceManager：系统启动时，所有关键服务（如ActivityManagerService, WindowManagerService）都向它注册。客户端要访问服务，首先查询ServiceManager获取该服务的Binder引用。

  • 鸿蒙 SAMgr：扮演完全相同的角色。所有“系统能力”（System Ability）都向SAMgr注册，并有一个唯一的SystemAbility ID。应用或服务通过GetSystemAbility()调用，向SAMgr查询并获取对应服务的远程对象代理。

2. IPC/RPC核心层：从Binder驱动到“Binder + 软总线”

这是架构演进的核心，鸿蒙在此分层。

  • 单设备内通信 (IPC)：鸿蒙使用了与Android Binder高度相似甚至优化的驱动机制（即“Binder-like”驱动）。它同样位于内核层，提供一次拷贝、高性能的进程间通信能力。

  • 跨设备通信 (RPC)：这是鸿蒙的创造。分布式软总线（DSoftBus） 在此核心作用。

    • 角色：它不是一个具体的驱动，而是一个位于系统服务层的“通信基座”子系统。它抽象了Wi-Fi、蓝牙等物理链路，实现设备的自动发现、安全组网和高效传输。

    • 与Binder的协同：当一次服务调用被判定为跨设备时（例如，手机应用调用智慧屏的摄像头服务），本地Binder驱动会将请求递交给分布式调度子系统。该子系统通过DSoftBus建立的安全通道，将请求发送到目标设备。对于目标设备而言，它收到的是一个标准的本地Binder调用请求。DSoftBus相当于在Binder通信路径中插入了一个透明的、跨设备的“扩展坞”。

3. 接口契约层：从AIDL到鸿蒙IDL

两者设计理念一脉相承，是实现安全、高效通信的保障。

  • 作用：无论是Android的AIDL还是鸿蒙的IDL，其核心作用都是定义客户端和服务端之间的通信接口（方法名、参数、返回值）。通过工具编译后，会自动生成客户端代理（Proxy）和服务端存根（Stub）代码。

  • 意义：这保证了通信双方的类型安全，并将复杂的序列化/反序列化、事务编组等操作自动化，让远程调用在代码层面看起来如同本地函数调用。

4. 轻量级设备的补充：LiteIPC

对于运行LiteOS-A内核的资源受限设备（如某些IoT设备），鸿蒙提供了LiteIPC作为一种更轻量的选择。其思想也是服务化，有类似于ServiceManager的ServiceManager来管理服务（Service）和权限。可以将它理解为在这些设备上，Binder-like机制的一个简化实现。

三、总结：通信路径全景

综合以上，可以描绘出两条清晰的通信路径：

  1. 单设备内通信路径： 应用/服务 (客户端) → ArkTS/Java框架API → 查询 SAMgr 获取服务引用 → 通过内核 Binder-like驱动 → 系统服务 (服务端)

    • 此路径与Android的App → ServiceManager → Binder驱动 → System Service 几乎一致。

  2. 跨设备通信路径： 设备A上的应用 → 框架API → 查询本地SAMgr发现服务在远端 → 分布式调度子系统介入 → 通过 DSoftBus 安全网络通道 → 到达设备B → 在设备B内转为本地Binder调用 → 访问设备B上的目标服务

    • 此路径是鸿蒙的核心创新，它让跨设备调用复用设备内成熟的Binder模型，实现了范式统一。

总而言之，鸿蒙的通信架构并非抛弃了Android的验证，而是在深刻理解Binder + ServiceManager这一高效范式的基础上，通过引入分布式软总线（DSoftBus） 和系统能力管理（SAMgr），将通信的边界从单个设备的进程之间，成功地扩展到了网络中的多个设备之间，最终实现了“一次开发，多端部署”和“超级终端”的体验。

第二部分 分布组件

以下是基于官方文档和开源代码仓对这三个组件架构的整理分析，其中IDL和SAMgr的官方信息较为完整，而DSoftBus的协议细节更多依赖源码分析。

为便于快速对比理解，将它们的核心要素汇总如下表：

组件 核心架构/语法要点 代码仓/目录位置 官方依据
IDL (接口描述语言) 数据类型、接口定义、生成Proxy/Stub 开发工具链 (idl) 《OpenHarmony IDL工具规格及使用说明书》
分布式软总线 (DSoftBus) 统一通信基座、设备发现、连接、传输 /foundation/communication/dsoftbus 官方子系统简介
系统能力管理框架 (SAMgr) 服务注册、发现、生命周期管理 /foundation/systemabilitymgr/ 官方SAMGR子系统说明

一、 IDL接口描述语言

IDL用于严格定义跨进程或跨设备通信的服务接口，是实现RPC类型安全的基础。其核心架构和语法如下：

  • 1. 数据类型映射：IDL定义了与C++、TS等语言映射的基本类型（如int、String）、可序列化的sequenceable类型、interface类型以及容器类型（如List<T>, Map<KT,VT>）。

  • 2. 接口定义语法：采用类BNF范式。一个.idl文件定义一个接口，接口内声明方法。关键语法包括：

    • 接口属性：[oneway]表示异步，无返回值。

    • 方法属性：同上，但需注意异步方法不能有out/inout参数或返回值。

    • 参数方向：必须明确指定[in]、[out]或[inout]。

    • 示例：

      // 示例：IIdlTestService.idl
interface OHOS.IIdlTestService {
    int TestIntTransaction([in] int data); // 同步方法，输入参数
    oneway void TestStringTransaction([in] String data); // 异步方法
}

  • 3. 代码生成与使用：IDL工具（idl可执行文件）编译.idl文件，自动生成代理（Proxy） 和桩（Stub） 代码。

    • 服务端：实现Stub类，在onRemoteRequest中处理具体业务逻辑。

    • 客户端：通过Proxy类调用方法，如同本地调用。

二、 分布式软总线 (DSoftBus)

DSoftBus是鸿蒙分布式通信的“基座”，统一抽象底层网络差异，提供设备发现、连接和传输能力。由于详细的网络协议并未在公开文档中完全披露，其架构主要体现为设计思想和关键流程：

  • 1. 核心设计思想：

    • 统一抽象：将Wi-Fi、蓝牙等不同物理链路统一为逻辑通信通道。

    • 自发现与自组网：设备可自动发现并连接同一局域网内的其他信任设备。

    • 安全通道：通信过程经过加密和身份认证。

  • 2. 关键流程：

    • 组网（发现）：服务启动后，获取在线设备列表，注册监听以感知设备上下线变化。

    • 传输（会话）：

      1. 创建会话服务并注册监听。

      2. 指定设备上线后，主动建立会话。

      3. 会话建立成功后，通过该通道发送数据。

      4. 会话结束时关闭通道。

  • 3. 通信模式：支持点对点、发布/订阅等多种模式，适应不同业务场景。

  • 源码结构：核心实现位于OpenHarmony源码的 /foundation/communication/dsoftbus 目录下。

三、 系统能力管理框架 (SAMgr)

SAMgr是所有系统服务（System Ability）的注册、发现和生命周期管理中心，类似于一个服务电话簿和调度中心。

  • 1. 核心架构：SAMgr子系统包含几个关键模块：

    • safwk：定义系统能力的实现规范，提供启动、注册API。

    • samgr：提供系统能力的注册、查询等管理API。

    • safwk_lite / samgr_lite：为轻量/小型系统提供的轻量化实现。

  • 2. 核心工作机制：

    • 服务注册：每个系统服务（SA）启动时，向SAMgr注册一个唯一的整数ID和其远程对象。注册方式有静态（系统启动时）和动态（按需加载）两种。

    • 服务发现与调用：客户端（应用或其他服务）通过GetSystemAbility(SA_ID)向SAMgr查询。SAMgr返回一个代理对象，后续调用通过此代理进行，对开发者透明。

    • 生命周期管理：SAMgr负责服务的启动（OnStart）、停止（OnStop）以及崩溃后自动拉起。

    • 分布式扩展：在跨设备场景下，SAMgr可与分布式框架协同，使本地客户端能发现和调用远程设备上的系统能力。

  • 3. 源码结构：核心代码位于 /foundation/systemabilitymgr/ 目录下，对应上述模块。

四、 总结

IDL、DSoftBus、SAMgr三者紧密协作，构成了鸿蒙分布式通信的基石：

  1. IDL 定义了通信的契约（接口是什么），确保跨进程/设备调用的规范性。

  2. SAMgr 扮演了服务的总机（服务在哪里），管理者所有系统能力的目录和生命周期。

  3. DSoftBus 提供了通信的高速公路（数据怎么走），负责实际的数据传输，屏蔽网络复杂性。

第三部分 会话管理

一、 核心要点速览

组件 核心工作机制与关键源码结构 核心API与官方文档参考
IDL编译器 工作流程：解析.idl文件 → 校验语法 → 生成目标语言(TS/C++)的 Proxy 与 Stub 代码。 关键产出：_proxy (客户端)、_stub (服务端) 和接口文件。 工具链命令：idl -gen-ts -d dir -c file.idl。 语法定义：数据类型、接口、方法参数的BNF范式。
DSoftBus会话管理 源码目录：位于 /foundation/communication/dsoftbus/core/transmission。 核心对象：ISessionListener 回调结构体。 关键流程：创建会话服务(CreateSessionServer) → 打开会话(OpenSession) → 发送/接收数据 → 关闭清理。 核心API：CreateSessionServer, OpenSession, SendBytes, CloseSession, RemoveSessionServer。 架构说明：分布式通信子系统官方README。
SAMgr (系统能力管理框架) 模块构成：safwk (定义与启动)、samgr (注册与查询)、lite版本。 核心机制：基于唯一SA ID的服务注册表与查询机制。 核心API：AddSystemAbility (注册)， GetSystemAbility (发现/获取)。 官方介绍：SAMGR子系统架构文档。

二、 IDL编译器工作机制详解

IDL（接口描述语言）编译器的核心工作是充当“翻译官”和“代码生成器”，它将开发者定义的接口契约（.idl文件）转换为具体的、可编译的编程语言代码，实现跨进程/跨设备调用的自动化。

  1. 输入与解析

    • 输入：开发者编写的 .idl 文件。该文件严格遵循BNF范式定义，只能包含一个interface，且名称须与文件名相同。

    • 解析与校验：编译器首先解析文件，校验语法正确性（如接口属性、方法参数方向[in]、[out]、[inout]等）和类型合法性。

  2. 代码生成（以TS为例） 编译器根据 -gen-ts 或 -gen-cpp 等参数，生成三种核心文件：

    • 接口文件 (i_xxx.ts)：声明了IDL中定义的所有方法，是客户端和服务端共同遵守的TypeScript接口契约。

    • 代理端代码 (xxx_proxy.ts)：继承自 rpc.RemoteProxy。它实现了接口文件中的方法，内部将调用请求、参数序列化，并通过RPC通道发送给远端。对客户端而言，调用Proxy对象就像调用本地方法一样。

    • 桩端代码 (xxx_stub.ts)：继承自 rpc.RemoteObject。它接收来自Proxy的请求，反序列化参数，并调用开发者编写的实际服务实现，然后将结果序列化返回。

  3. 使用流程 开发者执行命令（如 idl -gen-ts -d ./output -c ./IIdlTestService.idl）生成代码后：

    • 服务端：实现具体的业务逻辑，并继承生成的Stub类。

    • 客户端：通过生成的Proxy类来调用远程服务。

三、 DSoftBus会话管理源码解析

DSoftBus的会话（Session）管理是实现设备间可靠数据传输的核心模块。其源码主要位于OpenHarmony代码仓的 /foundation/communication/dsoftbus/core/transmission 目录下。

  1. 核心数据结构：ISessionListener 会话的所有事件都通过此回调接口通知给上层业务。

    // 会话监听器定义
typedef struct {
    int (*OnSessionOpened)(int sessionId, int result); // 会话建立结果回调
    void (*OnSessionClosed)(int sessionId);           // 会话关闭回调
    void (*OnBytesReceived)(int sessionId, const void *data, unsigned int dataLen); // 收到字节流
    void (*OnMessageReceived)(int sessionId, const void *data, unsigned int dataLen); // 收到消息
} ISessionListener;

  2. 会话生命周期管理流程 一次完整的会话交互遵循以下典型流程：

    1. 创建会话服务 (CreateSessionServer)：业务进程首先调用此API，传入一个唯一的会话名称（sessionName）和ISessionListener回调，向DSoftBus注册自己为一个可被连接的服务端点。

    2. 打开会话 (OpenSession)：当需要与某个对端设备通信时，调用此API，指定本地会话名、对端会话名和对端设备网络ID。DSoftBus会负责建立安全的传输通道，成功后将返回一个用于后续通信的 sessionId。

    3. 数据传输 (SendBytes / SendMessage)：使用上一步获取的 sessionId，调用发送API进行数据传输。对端在其注册的OnBytesReceived或OnMessageReceived回调中接收数据。

    4. 关闭与清理 (CloseSession, RemoveSessionServer)：通信结束后，关闭指定会话。当业务不再需要该会话服务时，应调用RemoveSessionServer进行注销，释放资源。

四、 SAMgr详细API与工作机制

SAMgr（系统能力管理框架）是整个鸿蒙系统服务的“大管家”，所有系统能力（System Ability）都必须向其注册，并由其统一管理生命周期和提供查询。

  1. 架构与模块 SAMgr由以下几个核心模块构成，代码位于 /foundation/systemabilitymgr/ 目录下：

    • safwk：定义System Ability的实现规范，提供启动、注册等基础框架API。

    • samgr：提供系统能力的注册、查询等核心管理API。

    • safwk_lite / samgr_lite：为内存资源受限的轻量/小型系统提供的轻量化实现。

  2. 核心API列表与功能 尽管搜索结果中没有提供完整的官方API参考手册，但综合多个技术博客和官方介绍，其最核心的API可以归纳为以下几类：

    API类别 核心函数 (示例) 功能描述
    服务注册 AddSystemAbility(int32_t systemAbilityId, const sptr<IRemoteObject>& ability); 向SAMgr注册一个系统能力。每个能力由唯一的SA ID标识。
    服务发现与获取 GetSystemAbility(int32_t systemAbilityId); 根据SA ID查询并获取系统能力的远程对象代理。如果服务未启动，SAMgr可能会按需拉起。
    客户端辅助 SystemAbilityManagerClient::GetInstance().GetSystemAbilityManager(); 客户端获取SAMgr自身远程对象的标准方法，是调用上述API的前提。
    服务端基类 SystemAbility::Publish(sptr<IRemoteObject> ability); 系统服务在OnStart()中调用，将自身发布给SAMgr。

  3. 工作流程示例

    • 服务端注册：一个系统服务（如LocationService）启动后，在其OnStart()生命周期函数中，调用 Publish(this) 或通过 GetSystemAbilityManager()->AddSystemAbility(LOCATION_SERVICE_ID, this) 向SAMgr注册。

    • 客户端调用：应用需要定位服务时，调用 GetSystemAbility(LOCATION_SERVICE_ID)。SAMgr在其注册表中查找，返回该服务的远程代理对象（Proxy）。客户端通过此代理进行RPC调用，整个过程无需关心服务所在的进程。

第四部分 鸿蒙特色

下表梳理了这三个问题的关键信息来源：

关注点 核心答案概览 主要信息来源分析
IDL生成的具体代码段 有详细流程和代码示例。官方提供了从C/C++头文件自动生成IDL的工具（h2idl），并有完整的工作原理和生成示例。 来自官方开发者博客和文档，内容具体。
DSoftBus会话建立过程 仅有高层流程描述。官方文档只概括了会话创建、打开、发送数据、关闭等步骤，没有底层协议和网络交互的细节。 来自开源文档网站，为高层概述，细节缺失。
SAMgr跨设备查询机制 只有原理性说明。官方介绍指出SAMgr支持跨设备查询，并简述了其作为分布式系统服务“枢纽”的角色，但缺少分布式发现、路由等核心机制的详细说明。 来自开源文档和技术博客，后者对原理阐述较生动。

下面将基于现有信息，对这三个问题进行详细说明。

一、IDL生成的具体代码段：h2idl工具的工作流程

官方不仅定义了IDL语法，还提供了从现有C/C++头文件（.h）自动生成IDL文件的工具，例如h2idl和napi-gen插件中的h2sa功能。其核心工作是完成从C/C++类型到IDL类型的映射和转换。

1. 核心类型映射规则 这是生成正确IDL代码的基础。工具内部维护了一个类型映射表，部分关键映射如下：

C/C++ 类型 映射后的 IDL 类型
int32_t, int int
std::string String
std::vector<T> List<T>
std::map<K, V> Map<K, V>
bool boolean

2. 从C++头文件到IDL文件的完整生成示例 假设有一个C++头文件 audio_adapter.h，定义了以下接口：

// audio_adapter.h (C++ 头文件)
namespace ohos {
namespace audio {
class IAudioAdapter {
public:
    virtual int32_t SetVolume(int32_t volume) = 0;
    virtual int32_t GetVolume(int32_t& volume) = 0; // 注意：volume是输出参数
};
} // namespace audio
} // namespace ohos

使用h2idl工具转换后，会生成类似下面的IDL文件：

// 生成的 IAudioAdapter.idl
package ohos.audio;
​
interface IAudioAdapter {
    int32_t SetVolume([in] int32_t volume);
    int32_t GetVolume([out] int32_t volume); // 工具自动识别并添加[out]方向
}

关键生成步骤解析：

  1. 解析提取：工具（如_header_parser.py）会解析C++头文件，提取出类名、方法名、参数类型等信息。

  2. 类型转换：根据映射表，将int32_t转换为int，将std::string转换为String。

  3. 推断参数方向：工具会分析C++代码。例如，对于GetVolume方法中的引用参数int32_t& volume，工具能推断其为输出参数，并在IDL中自动添加 [out] 标签。

  4. 生成最终IDL：按照鸿蒙IDL的语法规范，生成最终的接口文件。

二、DSoftBus会话建立的底层网络过程

关于这部分，公开的官方文档仅描述了高层的编程步骤和逻辑流程，并未深入其底层的网络协议、握手过程、编解码等实现细节。

根据文档，一次完整的会话传输流程如下：

  1. 创建会话服务：业务调用 CreateSessionServer()，注册一个监听回调。

  2. 建立会话：待目标设备上线后，调用 OpenSession() 与其建立连接。

  3. 发送数据：会话建立成功后，使用 SendBytes() 等函数发送数据。

  4. 关闭会话：通信完成后，调用 CloseSession() 和 RemoveSessionServer() 进行清理。

文档强调，所有设备必须位于同一局域网中，这是软总线实现自发现和自组网的基础网络约束条件。底层如何利用Wi-Fi或蓝牙等链路实现设备发现、安全连接和可靠传输，目前缺乏公开的协议细节。

三、SAMgr在分布式场景下的跨设备查询机制

官方文档确认了SAMgr（系统能力管理框架）具备查询跨设备分布式系统服务的功能。其分布式角色可以概括为 “分布式服务能力的统一查询入口” 。

1. 核心机制描述 在分布式场景下，其工作机制可以理解为：

  • 服务注册：每个设备上的本地服务（System Ability）会向本设备的SAMgr注册。

  • 跨设备查询：当应用通过 GetSystemAbility() 请求一个服务时，本地SAMgr会判断该服务是否在本机。

  • 分布式路由：如果不在，SAMgr会通过分布式调度机制（可能与分布式任务调度子系统 dmsfwk 协同），将查询请求路由到网络中的其他设备。

  • 透明调用：找到目标服务后，会返回一个跨设备的代理对象（Proxy）给调用者。后续的调用会通过分布式软总线（DSoftBus）进行跨设备RPC，但对开发者而言，调用方式与本地服务无异。

2. 代码流程示意 以下是一个高度简化的代码逻辑示意，展示了SAMgr如何使跨设备调用对开发者透明：

// 应用代码：调用方式与请求本地服务完全相同
// SAMgr和分布式框架在背后处理了所有跨设备逻辑
sptr<IRemoteObject> remoteObject = 
    SystemAbilityManagerClient::GetInstance().GetSystemAbility(DISTRIBUTED_SERVICE_ID);
​
// 假设获取到的是智慧屏上的音频服务代理
sptr<IAudioService> audioProxy = iface_cast<IAudioService>(remoteObject);
audioProxy->PlayMusic("song.mp3"); // 此调用实际在远程设备执行

四、总结与建议

总的来说，目前关于鸿蒙底层架构的公开信息呈现 “工具与流程可见，深层协议与机制未公开” 的特点。

问题 当前信息状态 性质
IDL生成代码段 较为详细，有工具原理和示例 开发规范/工具链
DSoftBus底层网络过程 仅有高层API使用流程 未公开的实现细节
SAMgr跨设备查询 有原理描述和架构定位 已公开的架构设计
# harmonyos # 华为
Logo
HarmonyOS开发者社区

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

更多推荐

cover

[理财有道应用]Flutter × HarmonyOS 6.0 跨端开发

avatar HarmonyOS开发者社区
cover

「记账星（LedgerStar）」— 基于Flutter × HarmonyOS 6.0开发支出记录模块设计与实现

avatar HarmonyOS开发者社区
cover

文件大师：Flutter × Harmony6.0 构建文件和文件夹列表区域

avatar HarmonyOS开发者社区