摘要

随着鸿蒙系统在多设备、多终端场景下的应用越来越多，分布式能力已经不再是“演示功能”，而是直接跑在真实业务里的核心能力。
但在实际开发中，很多项目在功能跑通之后，很少系统性地去验证：
当设备变多、调用变频繁、数据同步变密集时，系统到底还能不能扛得住。

这篇文章就结合真实工程经验，聊一聊鸿蒙分布式应用应该怎么做压力测试，重点放在：

• 压什么
• 怎么用代码造压力
• 怎么结合真实业务场景去看问题

同时给出可运行的 Demo 代码模块，方便你直接在项目里改一改就能用。

引言

在早期做鸿蒙项目时，很多分布式功能的验证方式都比较“原始”：

• 手动点 UI
• 两台设备互相拉 Ability
• 看一眼能不能同步数据

但一旦进入真实场景，比如：

• 多设备协同办公
• 车机 + 手机 + 平板
• 教室 / 会议室里几十台设备同时在线

你会发现，真正出问题的不是功能，而是稳定性和性能。

所以，分布式应用一定要做压力测试，而且要用接近真实业务的方式去压。

鸿蒙分布式压力测试到底在测什么

在鸿蒙里，压力测试的重点不是 UI，而是分布式能力本身。

常见的压力点分类

从工程角度看，主要有这几类：

• 设备发现和组网
• 跨设备 Ability 调用
• 分布式数据同步（KVStore）
• 系统资源消耗（CPU、内存、线程）

实际测试时，不要一上来全压，而是一次只盯一个点，这样问题更好定位。

整体压测 Demo 结构设计

先给你一个最小但完整的压测 Demo 结构，后面的代码都围绕它展开。

entry/
 ├─ ability/
 │   ├─ MainAbility.ts        // 发起压力
 │   └─ RemoteAbility.ts     // 被远程调用
 ├─ data/
 │   └─ KvStress.ts          // KVStore 压测
 ├─ device/
 │   └─ DeviceMonitor.ts     // 设备上下线监听

这样拆分的好处是：

• 压 Ability、压数据、压设备，各自独立
• 你可以按需组合测试

分布式 Ability 调用压力测试

为什么 Ability 调用容易出问题

在真实业务里，跨设备 Ability 调用经常用于：

• 手机拉起车机页面
• 平板拉起大屏展示
• 辅助设备协同处理任务

问题往往出现在：

• 调用次数一多就失败
• 调用延迟突然变大
• 主线程被拖慢

可运行 Demo：高频拉起远程 Ability

下面这段代码可以直接放在 MainAbility 里执行。

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

export function stressStartRemoteAbility(deviceId: string) {
  const want = {
    deviceId: deviceId,
    bundleName: 'com.example.remote',
    abilityName: 'RemoteAbility'
  };

  // 模拟高频跨设备调用
  for (let i = 0; i < 100; i++) {
    featureAbility.startAbility(want)
      .then(() => {
        console.info(`startAbility success: ${i}`);
      })
      .catch(err => {
        console.error(`startAbility failed: ${JSON.stringify(err)}`);
      });
  }
}

这段代码在压什么

• Ability 启动链路
• 设备间通信稳定性
• 系统调度能力

你可以从 20、50、100 慢慢往上加，观察失败出现的临界点。

分布式 KVStore 数据压力测试

为什么 KVStore 是“重灾区”

在多设备协同场景里，KVStore 很容易被用成：

• 实时状态同步
• 临时共享数据
• 多端配置存储

一旦写得频繁，就很容易出现：

• 同步延迟
• 冲突覆盖
• 性能骤降

高频写入压测 Demo

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

export async function stressKvWrite(kvStore: distributedKVStore.SingleKVStore) {
  for (let i = 0; i < 1000; i++) {
    await kvStore.put(`key_${i}`, `value_${i}`);
    console.info(`put key_${i}`);
  }
}

多设备同时写同一个 Key

这是最贴近真实业务的压测方式。

export async function stressKvConflict(kvStore: distributedKVStore.SingleKVStore) {
  for (let i = 0; i < 200; i++) {
    await kvStore.put('shared_key', Date.now().toString());
  }
}

在两台或三台设备上同时跑这段代码，很容易看出：

• 数据是否频繁被覆盖
• 同步是否明显变慢
• 是否需要业务层做冲突控制

设备发现与上下线压力测试

为什么要压设备变化

在真实场景里，设备并不是一直稳定在线的，比如：

• 用户进出会议室
• 设备待机和唤醒
• 网络切换

设备状态监听 Demo

import deviceManager from '@ohos.distributedHardware.deviceManager';

export function monitorDeviceState() {
  const dm = deviceManager.createDeviceManager('com.example.app');

  dm.on('deviceStateChange', (data) => {
    console.info(`device state change: ${JSON.stringify(data)}`);
  });
}

怎么制造压力

• 多台设备反复开关分布式能力
• 快速上线、下线
• 同时进行 Ability 调用和 KV 写入

你要关注的是：
事件有没有丢、延迟是不是越来越大。

结合真实业务的 3 个应用场景

场景一：多屏协同展示

场景描述
手机不断向大屏发送展示指令。

压测方式

for (let i = 0; i < 50; i++) {
  stressStartRemoteAbility(screenDeviceId);
}

重点关注

• 大屏是否出现延迟
• 是否有调用失败

场景二：多设备实时状态同步

场景描述
多终端同步编辑状态或播放进度。

await kvStore.put('play_status', JSON.stringify({
  time: Date.now(),
  state: 'playing'
}));

重点关注

• 状态是否乱跳
• 是否出现明显延迟

场景三：设备频繁进出网络

场景描述
设备在弱网或移动环境下频繁上线。

monitorDeviceState();

重点关注

• 是否影响已有分布式任务
• 是否导致异常堆积

QA 环节（开发中常见问题）

Q1：模拟器能不能做分布式压力测试？
不能指望它。模拟器更适合功能验证，压力测试一定要真机。

Q2：一次压多个点行不行？
不建议。先单点压，定位问题后再组合压。

Q3：压力测试要跑多久？
至少 10～30 分钟，短时间很难暴露问题。

总结

从工程实践来看，鸿蒙分布式应用的压力测试，本质就是一件事：

用代码去模拟最极端、最不友好的使用方式，然后盯住系统的真实反应。

• Ability 要敢高频拉
• KVStore 要敢并发写
• 设备要敢频繁上下线

只要这几关能扛住，你的分布式应用在真实场景里基本就稳了。