【OpenHarmony/HarmonyOs 】CheckMe 备份恢复能力设计：从 BackupExtensionAbility 到设备数据可迁移

本文基于 CheckMe 项目，聚焦 HarmonyOS 的备份恢复能力、数据可迁移和隐私边界。这个选题避开了已经写过的服务卡片、权限申请、端侧 AI 等方向，更适合写“鸿蒙新特性 + 项目工程化”的文章。

很多应用只关注“功能能不能用”，但真正的用户体验还包括：

• 换机后配置能不能回来
• 用户手动校准的数据会不会丢
• 应用升级后历史状态是否还能读取
• 备份恢复时是否会带走敏感信息

CheckMe 是设备监控工具，里面有不少本地配置和校准数据。比如存储容量校准、性能优化记录、卡片注册信息等，都适合纳入备份恢复设计。

这篇文章就从项目里已经配置的 BackupExtensionAbility 出发，讲如何把设备工具类应用做成“可迁移、可恢复、可控隐私”的 HarmonyOS 应用。📦

---

一、为什么 CheckMe 需要备份恢复

设备信息应用看起来像“实时工具”，好像数据都是现查现用，不需要备份。

但实际项目里会有很多本地状态：

• 用户校准过的存储总容量
• 最近一次性能测试分数
• 最近一次优化时间
• 用户选择的主题或显示偏好
• 某些工具模块的历史状态
• 桌面卡片类型和尺寸记录

这些数据如果换机或重新安装后全丢，用户体验会下降。

因此备份恢复的目标不是备份实时设备状态，而是备份“用户配置”和“可迁移记录”。

---

二、项目中的 BackupExtensionAbility

CheckMe 已经在 module.json5 中注册了备份扩展：

{
  "name": "EntryBackupAbility",
  "srcEntry": "./ets/entrybackupability/EntryBackupAbility.ets",
  "type": "backup",
  "exported": false,
  "metadata": [
    {
      "name": "ohos.extension.backup",
      "resource": "$profile:backup_config"
    }
  ]
}

对应的备份配置文件：

{
  "allowToBackupRestore": true
}

这说明项目已经打开了备份恢复能力入口。

EntryBackupAbility.ets 代码如下：

import { hilog } from '@kit.PerformanceAnalysisKit';
import { BackupExtensionAbility, BundleVersion } from '@kit.CoreFileKit';

const DOMAIN = 0x0000;

export default class EntryBackupAbility extends BackupExtensionAbility {
  async onBackup() {
    hilog.info(DOMAIN, 'testTag', 'onBackup ok');
    await Promise.resolve();
  }

  async onRestore(bundleVersion: BundleVersion) {
    hilog.info(
      DOMAIN,
      'testTag',
      'onRestore ok %{public}s',
      JSON.stringify(bundleVersion)
    );
    await Promise.resolve();
  }
}

当前实现比较轻量，但它已经提供了扩展点：备份时整理数据，恢复时校验版本并迁移数据结构。

---

三、哪些数据适合备份，哪些不适合

设备工具类 App 备份数据时要特别谨慎。不是所有数据都应该迁移。

我建议分成三类：

数据	是否备份	原因
用户偏好	适合	换机后保留体验
手动校准值	适合	用户主动设置
历史报告摘要	可选	需用户同意
实时 CPU/内存状态	不适合	换机后无意义
精确定位记录	默认不备份	涉及隐私
设备唯一标识	不备份	迁移后可能错误
图片/音频原始文件	默认不备份	数据体积和隐私风险

总结一下：

备份的是用户配置，不是设备本身。

---

四、项目已有 Preferences 数据

项目中已经有多处使用 data.preferences 的逻辑。

例如存储容量校准：

import dataPreferences from '@ohos.data.preferences';

const PREF_STORE_NAME = 'storage_calibration';
const KEY_STORAGE_CALIBRATION_GB = 'storage_total_gb';

export class StorageCalibrationStore {
  static async init(ctx: common.UIAbilityContext): Promise<void> {
    const pref = await dataPreferences.getPreferences(ctx, PREF_STORE_NAME);
    const raw: dataPreferences.ValueType =
      await pref.get(KEY_STORAGE_CALIBRATION_GB, 0);
  }
}

性能优化服务里也会读取偏好数据：

async function readNumberPreference(
  pref: dataPreferences.Preferences,
  key: string,
  fallback: number
): Promise<number> {
  const raw: dataPreferences.ValueType = await pref.get(key, fallback);
  return typeof raw === 'number' ? raw : fallback;
}

这类数据非常适合备份恢复，因为它属于用户配置或本地计算结果。

---

五、备份数据结构建议

我建议在项目里定义一个统一备份快照：

interface CheckMeBackupSnapshot {
  version: number;
  createdAt: number;
  preferences: {
    storageCalibrationGb?: number;
    lastBenchmarkScore?: number;
    lastBenchmarkGrade?: string;
    lastOptimizedAt?: number;
  };
  privacy: {
    includeLocationHistory: false;
    includeDeviceIdentifiers: false;
  };
}

注意这里把隐私策略也写进结构里。

这样恢复时可以判断：

• 快照版本是多少
• 哪些字段存在
• 是否包含敏感数据
• 是否需要迁移字段

后续升级项目时，也能通过 version 做兼容。

---

六、恢复时要做版本兼容

onRestore() 中会拿到 BundleVersion：

async onRestore(bundleVersion: BundleVersion) {
  hilog.info(
    DOMAIN,
    'testTag',
    'onRestore ok %{public}s',
    JSON.stringify(bundleVersion)
  );
  await Promise.resolve();
}

这可以用于判断：

• 备份来自哪个版本
• 当前版本是否兼容
• 是否需要字段迁移
• 是否应该忽略旧字段

比如：

function migrateBackupSnapshot(snapshot: CheckMeBackupSnapshot): CheckMeBackupSnapshot {
  if (snapshot.version === 1) {
    return {
      ...snapshot,
      version: 2,
      privacy: {
        includeLocationHistory: false,
        includeDeviceIdentifiers: false
      }
    };
  }
  return snapshot;
}

备份恢复最怕的不是没有数据，而是恢复了错误的数据。版本迁移能降低这个风险。

---

七、备份恢复和隐私保护要一起设计

很多应用备份时会犯一个错误：只想着“尽量完整”，没想着“是否应该带走”。

对 CheckMe 来说，不建议默认备份：

• 精确经纬度
• WiFi 名称
• IP 地址
• 设备唯一标识
• 硬件序列号
• 用户选择的图片或媒体文件

如果未来支持检测报告历史，应该提供选项：

备份设置
  [开启] 备份应用偏好
  [开启] 备份手动校准数据
  [关闭] 备份历史检测报告
  [关闭] 备份定位相关信息

这样用户可以理解自己备份了什么，而不是被动接受全部迁移。

---

八、和全场景设备迁移的关系

HarmonyOS 的全场景体验强调设备之间的连续性。对于 CheckMe 来说，备份恢复可以带来这些体验：

• 新设备安装后保留用户偏好
• 校准过的显示配置不丢失
• 性能测试历史摘要可参考
• 隐私设置保持一致
• 工具页排序和入口偏好延续

但也要注意：设备状态本身不能迁移。

比如旧手机的 CPU 型号、电池健康、存储容量，不应该恢复到新手机上。恢复后应该重新采集设备状态，只迁移用户偏好。

这也是设备类工具的特殊点。

---

九、推荐落地步骤

如果继续完善 CheckMe 的备份恢复，我建议按这个顺序：

1. 梳理所有 Preferences key。
2. 给每个 key 标记是否允许备份。
3. 定义 CheckMeBackupSnapshot。
4. 在 onBackup() 中生成备份快照。
5. 在 onRestore() 中读取快照并做版本迁移。
6. 恢复后重新采集实时设备状态。
7. 提供隐私设置开关。

这样做出来的备份恢复不是形式化配置，而是一个真正可维护的数据迁移方案。

---

十、文章小结

CheckMe 当前已经具备备份恢复扩展入口：

• EntryBackupAbility
• backup_config.json
• module.json5 中的 backup extension 注册
• 多处 Preferences 本地配置

下一步可以围绕“用户配置可迁移，设备状态重新采集”的原则完善。

最终目标是：

• 换机后体验连续
• 配置不会丢
• 隐私不被默认带走
• 旧版本数据可迁移
• 新设备状态不会被旧设备污染

最后一句总结：备份恢复不是把所有数据都打包带走，而是让用户真正有价值的配置在新设备上继续可用。 🔄

---

参考资料

• 华为开发者文档：ExtensionAbility Component
• 华为开发者文档：BackupExtensionAbility API
• 华为开发者文档：UIAbility Backup and Restore