摘要

在鸿蒙系统（HarmonyOS / OpenHarmony）中，分布式能力已经从“概念阶段”进入了实际落地阶段。
手机、平板、智慧屏、车机、穿戴设备之间的协同已经非常常见，但在真实环境下，一个绕不开的问题是：失败随时都可能发生。

设备可能突然离线，网络可能中断，Ability 可能被系统回收，任务执行到一半就“断了”。
如果系统一失败，功能就直接不可用，那分布式能力在真实场景中几乎没法用。

所以在分布式场景中，我们更关心的不是“如何保证不失败”，而是：

失败了，系统能不能知道？能不能恢复？能不能继续往下走？

这篇文章就围绕一个核心问题展开：
鸿蒙系统中，分布式任务的失败恢复该如何设计和实现？

引言

很多刚接触鸿蒙分布式的开发者，第一反应往往是：

• 设备能不能发现？
• Ability 能不能跨设备拉起？
• 数据能不能同步？

但当项目真正跑在真实设备上后，问题马上就变了：

• 任务跑到一半，对端设备下线了
• Ability 拉起成功了，但执行过程中被系统回收
• 分布式数据还没同步完，任务就开始用了
• 网络抖了一下，整个流程直接中断

在单设备应用中，这些问题影响有限；
但在多设备协同中，这些情况几乎每天都会发生。

鸿蒙系统的设计理念，其实默认了这一点：
分布式任务一定会失败，只是时间问题。

系统不会替你自动把任务“救活”，
但它提供了足够多的底层能力，让你可以自己把失败恢复这件事做好。

分布式任务为什么一定要考虑失败恢复

分布式失败不是异常，而是常态

在分布式场景中，失败来源非常多：

• 设备层：关机、离线、弱网
• 能力层：Ability 被系统回收、拉起失败
• 数据层：分布式 KV 未同步完成
• 任务层：子任务超时、执行异常
• 调度层：任务迁移失败

这些失败没有一个是“bug”，都是正常情况。

如果代码里默认“任务一定能跑完”，那上线之后只会不断踩坑。

鸿蒙的思路：能力给你，策略你来定

鸿蒙系统并不会帮你自动完成这些事情：

• 自动重试任务
• 自动迁移任务
• 自动回滚业务逻辑

但它给你提供了这些关键能力：

• 设备状态感知
• 分布式数据存储
• Ability 跨设备调度
• 生命周期回调

失败恢复，本质是业务逻辑，而不是系统逻辑。

分布式失败恢复的核心设计思路

核心原则只有一句话

任务必须是“可中断、可恢复、可重放”的

拆开来看就是：

• 执行到一半停下来，不会崩
• 知道自己执行到哪一步
• 重新执行时，不会把数据搞乱

为什么“任务状态持久化”是第一位的

如果任务失败了，但你连“跑到哪一步了”都不知道，那基本等于失败不可恢复。

在鸿蒙中，最常用的方式就是：

• 本地持久化
• 分布式 KV 数据服务

失败恢复的核心实现方式

使用分布式 KV 保存任务状态

这是整个失败恢复的基础设施。

代码示例：初始化 KV Store

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

let kvStore: distributedKVStore.SingleKVStore;

async function initKvStore() {
  const manager = distributedKVStore.createKVManager({
    bundleName: 'com.example.demo'
  });

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

保存任务状态

async function saveTaskState(taskId: string, state: string) {
  await kvStore.put(`task_${taskId}_state`, state);
}

读取任务状态

async function loadTaskState(taskId: string): Promise<string> {
  return await kvStore.get(`task_${taskId}_state`);
}

这样一来，不管任务在哪个设备失败，
状态都可以在其他设备上读取并继续执行。

设备离线感知与任务回退

在真实场景中，设备离线是最常见的问题。

监听设备状态变化

import deviceManager from '@ohos.distributedDeviceManager';

function listenDeviceState() {
  deviceManager.on('deviceStateChange', (data) => {
    if (data.action === 'OFFLINE') {
      handleDeviceOffline(data.deviceId);
    }
  });
}

function handleDeviceOffline(deviceId: string) {
  console.info(`device offline: ${deviceId}`);
  // 标记当前任务失败
  // 尝试迁移或回退
}

这里你可以根据业务决定：

• 回退到本地继续执行
• 迁移到其他在线设备
• 暂停，等设备重新上线

Ability 启动失败的处理方式

跨设备拉起 Ability 时，一定要做好失败兜底。

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

async function startRemoteAbility(deviceId: string) {
  try {
    await featureAbility.startAbility({
      deviceId,
      bundleName: 'com.example.remote',
      abilityName: 'RemoteAbility'
    });
  } catch (err) {
    console.error('start remote ability failed', err);
    fallbackToLocal();
  }
}

function fallbackToLocal() {
  // 使用本地能力继续执行
}

不要假设 Ability 一定能成功拉起，这在分布式场景中非常危险。

幂等执行，避免任务“跑重”

失败恢复时，最怕的是同一个步骤被执行多次。

async function executeStep(taskId: string, step: string) {
  const currentState = await loadTaskState(taskId);
  if (currentState === step) {
    return;
  }

  await doBusinessLogic();
  await saveTaskState(taskId, step);
}

只要状态一致，就直接跳过，
任务就可以放心重试。

结合实际场景的失败恢复案例

场景一：手机 + 平板协同图片处理

场景说明：

• 手机拍照
• 平板进行图片处理
• 处理完成后返回手机

核心流程

async function imageProcessTask(taskId: string, deviceId: string) {
  try {
    await saveTaskState(taskId, 'START');
    await startRemoteAbility(deviceId);
    await saveTaskState(taskId, 'REMOTE_PROCESSING');
  } catch (e) {
    const state = await loadTaskState(taskId);
    recoverImageTask(taskId, state);
  }
}

恢复逻辑

function recoverImageTask(taskId: string, state: string) {
  if (state === 'START') {
    retryRemoteProcess();
  }
}

场景二：车机 + 手机导航同步

失败点：

• 车机临时断网
• 手机继续导航

async function syncNavigation(taskId: string) {
  try {
    await sendToCar();
    await saveTaskState(taskId, 'SYNC_DONE');
  } catch (e) {
    await fallbackToPhone();
  }
}

场景三：智慧屏 + 手机投屏任务

核心思想：

• 投屏是可中断的
• 失败后直接恢复本地播放

async function castTask(taskId: string) {
  try {
    await castToScreen();
  } catch (e) {
    resumeLocalPlay();
  }
}

QA 环节

Q：鸿蒙有没有“自动失败恢复”的机制？
A：没有，系统只提供能力，不替业务兜底。

Q：一定要用分布式 KV 吗？
A：不是必须，但这是最简单、最稳定的方案。

Q：失败恢复会不会让代码很复杂？
A：如果一开始就设计任务状态，反而会让系统更清晰。

总结

在鸿蒙系统中，分布式失败恢复并不是“额外工作”，
而是分布式设计本身的一部分。

只要记住这几点：

• 任务一定会失败
• 状态一定要保存
• 步骤一定要幂等
• 能力一定要兜底

分布式任务就能在真实环境中稳定运行，而不是只停留在 Demo 阶段。