HarmonyOS 项目实战：CheckMe 如何把设备监控、桌面卡片和系统能力做成一个完整项目

摘要

这篇文章想完整拆解我的 HarmonyOS 项目 CheckMe。它不是单纯的设备参数展示应用，而是一个集设备信息采集、实时状态可视化、服务卡片前置、后台刷新、工具能力整合于一体的项目。本文会从整体架构、核心模块、关键代码链路和四个主题方向几个角度，系统讲清楚这个项目为什么有鸿蒙特色，以及它是如何一步一步落地的。

四个主题适配说明

这篇总览文可以作为系列文章的第一篇，适合同时覆盖四大主题。高端精致 体现在实时 Dashboard、多尺寸卡片和趋势图表达；创新体验 体现在服务卡片把高频设备状态前置到桌面；安全隐私 体现在权限按需申请、本地采集和受限能力保守处理；能力增强 体现在 FormKit、BackgroundTasksKit、NetworkKit、LocationKit、CameraKit 与 Native C++ 的组合使用。

一、为什么我要做这样一个项目

很多设备信息类应用都有一个共同问题：功能很多，但缺少场景价值。用户打开一次看个参数，之后很少再回去。

我在做 CheckMe 时，想解决的不是“查参数”这件小事，而是想把项目做成一个真正能被持续使用的 HarmonyOS 工具型应用。于是我给它定下了三个目标：

1. 把 CPU、内存、存储、电池、网络等核心设备信息统一收口。
2. 通过看板和趋势图，让设备状态不只是“看到数值”，而是“看懂状态变化”。
3. 利用 HarmonyOS 的服务卡片能力，把高频状态前置到桌面，减少用户重复打开 App 的成本。

换句话说，我希望它既能在应用内提供完整的信息能力，也能在桌面上提供轻量、持续、场景化的体验。

二、项目最终做成了什么

从功能结果来看，CheckMe 已经具备这些能力：

• 设备基础信息展示
• CPU 型号、核心数、频率和使用率监控
• 内存、存储、电池、网络信息展示
• 位置、媒体、蓝牙、工具页等扩展能力
• 实时可视化 Dashboard
• 7 类桌面服务卡片
• 前台主动刷新与后台定时刷新
• Native C++ 增强 CPU 底层信息读取

如果只看页面，这已经是一个比较完整的工具型 App。但项目真正的重点并不只是页面，而是下面这条完整链路：

数据采集 -> 服务层封装 -> 页面可视化 -> 卡片模型化 -> 卡片推送 -> 后台刷新 -> 生命周期控制

三、项目结构怎么拆更合理

为了让整个项目可维护，我把核心实现分成了几个模块：

1. DeviceInfoService

职责：

• 统一采集 CPU、内存、网络、存储、电池等信息
• 屏蔽不同系统能力的调用细节
• 向页面和卡片提供统一数据入口

2. AdvancedDashboard

职责：

• 在主页面提供高质量动态看板
• 使用 Canvas 绘制趋势图、面积图、环图
• 让设备状态展示更直观

3. WidgetDataService

职责：

• 把原始设备信息转成卡片可直接使用的数据结构
• 维护历史数组和最新缓存
• 控制多卡片共享的刷新节奏

4. WidgetFormAbility

职责：

• 管理卡片添加、更新、移除
• 保存卡片元信息
• 注册 WorkScheduler

5. WidgetWorkSchedulerAbility

职责：

• 在后台环境中由系统调度唤醒卡片刷新

6. Native CPU 信息层

职责：

• 补充 CPU 核心数、频率等更底层信息
• 增强上层设备信息采集能力

这套拆分方式的好处是：页面不直接绑死底层能力，卡片不重复写采集逻辑，后台刷新也不跟 UI 混杂在一起，整个工程结构会更稳定。

如果用示例代码表示，核心分层可以简化成这样：

class DeviceInfoService {
  async getDeviceInfo(): Promise<DeviceInfoData> {
    return {
      cpu: await this.getCpuInfo(),
      memory: await this.getMemoryInfo(),
      battery: await this.getBatteryInfo(),
      network: await this.getNetworkInfo()
    };
  }
}

class WidgetDataService {
  async refreshWidgetSnapshot(): Promise<WidgetSnapshot> {
    const device = await DeviceInfoService.getInstance().getDeviceInfo();
    return buildWidgetSnapshot(device);
  }
}

四、为什么说这个项目很适合体现鸿蒙特性

很多使用 ArkTS 写的项目，其实只是换了个技术栈，但产品形态上仍然接近传统移动应用。CheckMe 的不同在于，它从设计开始就围绕 HarmonyOS 特性展开，尤其是下面几个点。

1. 服务卡片不是点缀，而是核心能力

项目里一共定义了 7 类服务卡片，包括：

• CPU 使用率卡片
• CPU 频率卡片
• WiFi 信号卡片
• 内存卡片
• 存储卡片
• 电池卡片
• 网络流量卡片

这些卡片不是展示一个 Logo 或一句宣传语，而是真正把实时设备状态直接搬上桌面。

2. 后台刷新考虑了真实使用场景

如果只是把卡片显示出来，技术含量并不高。真正难的是：

• 应用在前台时怎么高频更新
• 应用到后台时怎么尽量不失效
• 多张卡片同时存在时怎么统一调度

在 CheckMe 中，这些问题分别由 EntryAbility、WidgetDataService 和 WidgetWorkSchedulerAbility 协同处理。

3. 页面不是堆信息，而是做成实时看板

AdvancedDashboard 不是简单列表，而是做了趋势图、面积图、平滑曲线和动态刷新，这一点非常契合同类项目里“高端精致”的方向。

4. 不只调系统 API，还往下补底层能力

通过 Native C++ 读取 /proc/cpuinfo 和 /sys/devices/system/cpu/...，项目进一步增强了 CPU 信息的可读性和细粒度，这也是一个很有“工程味”的亮点。

五、核心实现链路怎么理解

这里我用一条完整链路来解释整个项目是怎么跑起来的：

第 1 步：页面或卡片发起刷新

卡片页面在显示时会通过 postCardAction 调用主应用能力，请求刷新当前卡片。主应用前台时也会通过 EntryAbility 启动统一轮询。

第 2 步：Service 层采集数据

DeviceInfoService 负责从多个 HarmonyOS Kit 和系统文件中收集信息，比如：

• @kit.BasicServicesKit
• @kit.NetworkKit
• @kit.SensorServiceKit
• @kit.LocationKit
• @ohos.display
• @ohos.file.fs

第 3 步：卡片数据层进行整理

WidgetDataService 会把采集到的原始数据整理成卡片专用模型，例如：

• CPU 使用率 + 历史趋势
• 各核频率 + 各核类型
• 网络上传下载速率 + 历史趋势

第 4 步：通过统一 Helper 推送卡片

WidgetFormPushHelper 会根据卡片类型把数据序列化为 JSON，并调用 formProvider.updateForm() 推送给对应的服务卡片。

第 5 步：后台场景下由系统调度补充刷新

当前台定时器不可靠时，WidgetWorkSchedulerAbility 会在系统调度下被拉起，再次执行采集和推送，提升卡片后台存活能力。

这条链路里，每一层都只做一件事，所以后面新增卡片或新增设备信息类型时，扩展成本会比较低。

六、项目中我最重视的三个设计点

1. 先抽象数据，再做展示

不管是主页、详情页还是卡片，我都不希望页面直接拼系统能力调用。因为页面会变，UI 会重构，但数据模型和服务层通常更稳定。

所以项目中先有 DeviceInfoService 和 WidgetModel.ts，再有各类展示层。

2. 卡片更新要考虑真实环境，而不是 Demo 环境

很多服务卡片 Demo 在前台运行看起来都没问题，但一旦应用退到后台、进程被冻结，问题就会集中爆发。所以我专门用：

• WidgetFormIdRegistry 管理卡片实例
• EntryAbility 管前台轮询
• WorkScheduler 管后台刷新

这套逻辑虽然比普通 Demo 麻烦，但更接近真实使用场景。

3. 要有项目辨识度

如果只写一个设备信息页面，很多人都能做。但当你把服务卡片、多尺寸布局、后台刷新、Native CPU 采集都串起来之后，项目的辨识度就会明显上来。

七、从四个主题视角怎么包装这个项目

如果要把 CheckMe 放进项目成果里，我会这样概括它：

高端精致

• 主页面用实时趋势图和动态看板表达状态
• 卡片支持多尺寸和差异化布局

创新体验

• 通过服务卡片把高频设备信息前置到桌面
• 减少用户反复进入 App 的操作成本

安全隐私

• 权限按需申请
• 受限能力不伪造数据
• 尽量本地采集和本地展示

能力增强

• 联动 FormKit、BackgroundTasksKit、LocationKit、NetworkKit、CameraKit
• 通过 Native C++ 增强底层 CPU 信息读取

八、结语

CheckMe 这个项目让我最有收获的一点是：HarmonyOS 项目真正的亮点，不在于页面多漂亮，而在于你有没有把系统能力、服务卡片和真实使用场景真正结合起来。

如果你也在做鸿蒙项目，我很建议不要只做一个“能运行的页面”，而是像 CheckMe 这样，从一开始就把卡片、后台刷新、能力整合和工程结构一起考虑进去。这样项目不仅更像一个完整产品，也更容易在四个主题里找到自己的亮点位置。