摘要

这两年在做鸿蒙应用的时候，一个特别明显的变化是：

应用不再只跑在一台设备上。

手机、平板、智慧屏、手表、车机同时存在，很多业务天生就是“多设备协同”的，比如：

• 手机下发任务，平板展示进度
• 手表触发操作，手机执行逻辑
• 智慧屏做大屏展示，手机当控制器

问题也随之而来：

代码在单设备上跑得好好的，一上多设备就各种异常。

所以在开发阶段把设备间协同调试跑通，几乎成了鸿蒙分布式开发的必修课。

这篇文章我就结合真实开发顺序，聊清楚：

• 鸿蒙协同调试到底在调什么
• 开发阶段怎么一步步把它跑起来
• 常见翻车点和真实业务里的用法

全程都是能直接跑的 Demo 级代码，不走教材风，偏实战记录。

引言

在传统 Android / iOS 开发中，多设备调试往往意味着：

• 自己写网络通信
• 自己处理设备发现
• 自己兜底各种失败情况

而在 HarmonyOS 里，官方给了完整的一套分布式能力：

• 设备发现
• Ability 跨设备启动
• 分布式数据自动同步

协同调试，说白了就是：

在开发阶段，把这些分布式能力在真机上完整跑一遍，并且能打断点、看日志。

只要你后面要做：

• 分布式任务
• 设备协同
• 远程控制 / OTA

那这一步都绕不开。

协同调试前的准备工作

设备与环境要求

这个地方看着简单，但实际开发中踩坑最多。

必须满足下面三个条件：

• 至少两台鸿蒙设备（手机 / 平板 / 智慧屏都行）
• 登录同一个华为账号
• 处在同一个局域网（同一个 Wi‑Fi）

只要有一个不满足，设备发现就会直接失败。

DevEco Studio 打开分布式调试

在 DevEco Studio 里：

Run → Edit Configurations → 勾选 Distributed debugging

这个选项的意义是：

• 允许你在运行时选择远端设备
• 允许断点命中远端设备的代码

如果不勾选，后面就算 Ability 真启动了，你也只能靠猜。

设备发现与连接（调试第一步）

获取当前可用设备列表

在协同调试里，我个人的习惯是：

第一步永远先验证设备能不能被发现。

import deviceManager from '@ohos.distributedDeviceManager';

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

dm.getAvailableDeviceList().then(devices => {
  devices.forEach(device => {
    console.info(`发现设备: ${device.deviceName}, id=${device.deviceId}`);
  });
});

这段代码主要干三件事：

• 创建设备管理器
• 获取当前网络中可用的鸿蒙设备
• 打印 deviceId，后面所有跨设备操作都要用

如果这里返回的是空数组，后面就不用继续查业务逻辑了，先把环境问题解决。

Ability 的设备间协同调试

开启 Ability 的分布式能力

不是所有 Ability 天生就能跨设备跑，需要在配置里显式开启。

// module.json5
{
  "abilities": [
    {
      "name": "MainAbility",
      "distributed": true
    }
  ]
}

如果忘了这一步，调用 startAbility 时不会报错，但远端设备就是没反应。

启动远端设备的 Ability

import featureAbility from '@ohos.ability.featureAbility';

featureAbility.startAbility({
  deviceId: remoteDeviceId,
  bundleName: 'com.example.demo',
  abilityName: 'MainAbility'
});

这里的体验其实很直观：

• 本地设备发起调用
• 远端设备真实启动页面
• 本地断点依然能命中

这一步一旦跑通，说明你的协同调试环境基本已经没问题了。

分布式数据同步的调试方式

创建分布式 KVStore

import distributedKVStore from '@ohos.data.distributedKVStore';

const manager = distributedKVStore.createKVManager('com.example.demo');

const store = await manager.getKVStore('syncStore', {
  kvStoreType: distributedKVStore.KVStoreType.SINGLE_VERSION,
  securityLevel: distributedKVStore.SecurityLevel.S1
});

KVStore 在调试阶段特别有用，因为：

• 不用自己写同步逻辑
• 数据变化非常直观

写入并监听数据变化

await store.put('debug_key', 'hello harmony');

另一台设备：

store.on('dataChange', (change) => {
  console.info('收到远端数据变化:', JSON.stringify(change));
});

调试时重点关注：

• 数据是否同步
• 是否有明显延迟
• 多设备同时写时的表现

结合实际业务的应用场景

场景一：手机控制，平板展示

典型场景是：

• 手机作为控制端
• 平板作为展示端

手机写入状态：

await store.put('play_status', 'start');

平板监听状态变化并刷新 UI。

这种模式在智慧屏、车机项目里非常常见。

场景二：远程任务下发

比如你现在做的远程任务同步：

await store.put('task_command', 'upgrade');

设备端监听：

store.on('dataChange', change => {
  if (change.insertions[0]?.key === 'task_command') {
    // 执行升级逻辑
  }
});

调试阶段可以非常清楚地看到任务是否真正下发。

场景三：多设备状态一致性校验

在调试阶段，可以用 KVStore 做状态对账：

await store.put('device_status', 'ready');

所有设备监听并上报自身状态，用来验证协同是否可靠。

QA：常见问题集中解答

Q：模拟器能不能用来协同调试？
A：UI 可以，分布式能力基本不可信，建议真机。

Q：断点为什么有时候打不中？
A：检查是否勾选 Distributed debugging，以及是否选中了正确的设备。

Q：数据不同步怎么办？
A：先确认安全等级一致，再确认使用的是同一个 storeId。

总结

协同调试并不是一个“高级功能”，而是：

只要你在做鸿蒙分布式应用，就必须优先跑通的一步。

我的个人经验是：

• 先把设备发现跑通
• 再验证 Ability 能跨设备启动
• 最后再叠加复杂业务逻辑

这样问题会少一半以上。