拆解鸿蒙 IoT 接入：网络通信、分布式软总线和能力调用是怎么配合的

摘要

随着物联网设备数量的快速增长，设备之间"能连上"已经不是问题，如何低成本、低复杂度、稳定地接入和管理设备 ，才是开发中的核心难点。

在传统模式下，IoT 设备往往只是一个"外设"，需要开发者自己处理协议、连接、状态同步、安全等大量细节。

鸿蒙系统在设计之初就把"多设备协同"作为核心能力，通过网络通信、分布式软总线以及分布式能力，把 IoT 设备从"外设"提升为"系统节点"。

本文将从实际项目视角 出发，结合可运行 Demo 代码，系统讲清楚鸿蒙是如何支持物联网设备接入的，以及在真实场景中该如何选型和落地。

引言

在当前的 IoT 应用中，你可能已经遇到过这些情况：

写了一堆 Socket 代码，只是为了控制一个简单设备
不同设备协议不统一，后期维护成本很高
设备和 App 强耦合，换设备就要改一堆逻辑
同一局域网下，设备发现、连接、状态同步全靠自己维护

鸿蒙提供的思路并不是"再造一个协议"，而是从系统层面帮你把设备管理这件事做掉一大半 。

你只需要关心两件事：

设备能提供什么能力
我什么时候调用这些能力

接下来我们就一步一步来看，鸿蒙是如何做到这一点的。

鸿蒙支持物联网设备接入的整体思路

从工程角度看，鸿蒙的 IoT 接入可以拆成五层能力：

设备发现与连接

Wi-Fi、蓝牙、BLE、分布式软总线

设备身份与安全

设备 ID、认证、加密通信

设备能力抽象

把具体硬件行为抽象成"能力接口"

数据通信与控制

消息、属性、事件上报

分布式能力调用

像调用本地模块一样控制远端设备

一句话理解就是：
鸿蒙希望你把 IoT 设备当成系统里的一个远程模块，而不是一个"麻烦的外设"。

最通用的 IoT 接入方式：基于网络通信

适用场景说明

这种方式在真实项目中非常常见，适合：

智能灯、插座、传感器
局域网设备控制
网关类设备
远程升级（OTA）场景

架构非常直观：

复制代码

IoT 设备  <------ TCP / MQTT ------>  鸿蒙 App

你只需要保证双方协议一致即可。

Demo：鸿蒙端通过 TCP 连接 IoT 设备

这是一个最小可运行示例，用于演示鸿蒙设备如何直接控制一个 IoT 设备。

ts 复制代码

import socket from '@ohos.net.socket';

const tcpSocket = socket.constructTCPSocket();

// 连接设备
tcpSocket.connect({
  address: '192.168.1.100',
  port: 8888
}, () => {
  console.log('已连接到 IoT 设备');
});

// 发送控制指令（示例：开灯）
const command = new Uint8Array([0x01, 0x01]);
tcpSocket.send({ data: command });

// 接收设备返回的数据
tcpSocket.on('message', (msg) => {
  console.log('设备上报数据:', msg.message);
});

代码说明

constructTCPSocket()

创建一个 TCP 客户端
connect()

直接连接 IoT 设备 IP 和端口
send()

发送控制指令，协议完全由你定义
on('message')

接收设备主动上报的数据

这种方式的优缺点

优点：

实现简单
灵活度高
不依赖系统生态

缺点：

协议需要自己维护
安全和设备管理成本高
设备多了之后会比较累

鸿蒙的核心优势：分布式软总线接入设备

为什么说这是鸿蒙的"杀手锏"

在传统系统里，设备发现、连接、认证基本都要自己做。

而在鸿蒙里，这些能力是系统级别提供的。

你不需要关心：

IP 地址
端口
网络类型
设备是否在同一子网

系统会帮你统一处理。

Demo：发现并感知 IoT 设备上线

ts 复制代码

import deviceManager from '@ohos.distributedDeviceManager';

const dm = deviceManager.createDeviceManager('com.example.iot');

dm.on('deviceStateChange', (data) => {
  if (data.action === deviceManager.DeviceStateChangeAction.ONLINE) {
    console.log('发现新设备:', data.device.deviceName);
  }
});

代码说明

createDeviceManager()

创建分布式设备管理器
deviceStateChange

监听设备上下线状态
ONLINE

设备上线即被系统感知

这一步完成之后，你已经可以完全不依赖网络细节来管理设备。

把 IoT 设备"像本地模块一样用"

分布式能力的核心思想

IoT 设备不再只是一个地址，而是一个提供能力的节点。

比如，一个智能插座可以提供：

打开
关闭
查询状态

Demo：远程调用 IoT 设备能力

设备端暴露能力

ts 复制代码

export function turnOn() {
  // 控制继电器上电
}

export function turnOff() {
  // 控制继电器断电
}

鸿蒙端调用能力

ts 复制代码

import rpc from '@ohos.rpc';

rpc.callRemoteAbility({
  deviceId: remoteDeviceId,
  bundleName: 'com.example.device',
  abilityName: 'ControlAbility'
});

实际效果

没有 Socket
没有协议解析
调用方式和本地服务几乎一致

这在复杂项目中能极大降低维护成本。

典型应用场景分析与示例

场景一：智能灯控制

场景说明

用户在鸿蒙平板或手机上控制家里的灯。

实现方式

同一局域网
分布式软总线发现设备
分布式能力调用开关

示例代码（控制）

ts 复制代码

function openLight(deviceId: string) {
  rpc.callRemoteAbility({
    deviceId,
    bundleName: 'com.example.light',
    abilityName: 'LightControlAbility'
  });
}

场景二：环境传感器数据采集

场景说明

温湿度、空气质量传感器周期性上报数据。

实现方式

TCP / MQTT 上传数据
鸿蒙端统一解析展示

ts 复制代码

tcpSocket.on('message', (msg) => {
  const data = JSON.parse(msg.message);
  console.log('温度:', data.temp);
  console.log('湿度:', data.humidity);
});

场景三：设备远程升级（OTA）

场景说明

批量设备需要升级固件。

实现方式

鸿蒙端下发升级指令
设备拉取固件并校验
重启生效

ts 复制代码

function startUpgrade(deviceId: string) {
  const cmd = new Uint8Array([0x02, 0x01]);
  tcpSocket.send({ data: cmd });
}

这个场景和你之前做的远程升级项目是高度一致的。

QA 环节（常见问题）

Q：一定要用分布式吗？

不一定，小规模或跨公网设备，用 TCP / MQTT 更合适。

Q：分布式适合哪些设备？

同一生态、同一网络、需要强系统协同的设备。

Q：能不能混合使用？

完全可以，实际项目里经常混合。

总结

从工程角度来看，鸿蒙对 IoT 的支持并不是"多了几个 API"，而是从系统架构层面降低了设备接入的复杂度。

你可以这样概括：

网络通信解决"能不能连"
分布式软总线解决"好不好连"
分布式能力解决"用起来像不像本地"