Mem Reduct 鸿蒙 PC 适配全记录：从 Win32 内存清理工具到 ArkUI 原生监控应用

sdp安歌

20人浏览 · 2026-09-13 16:24:23

sdp安歌 · 2026-09-13 16:24:23 发布

欢迎加入开源鸿蒙 PC 社区：https://harmonypc.csdn.net/

欢迎在 PC 社区平台申请新建项目：https://atomgit.com/OpenHarmonyPCDeveloper

适配开源地址：https://atomgit.com/OpenHarmonyPCDeveloper/ohos_memreduct

环境搭建文章：本项目不是 Electron 或 Qt 工程，适配过程主要依赖 DevEco Studio、HarmonyOS SDK、ArkTS、ArkUI Stage 模型、HiDebug、Notification Kit、Background Tasks Kit、Desktop / Status Bar Extension Kit 与真机签名安装流程，因此不引用 Electron/Qt 环境搭建文章。

一、为什么要适配 Mem Reduct

Mem Reduct 是一个轻量级实时内存管理工具。原 Windows 版本使用 Win32 桌面界面展示物理内存占用，并通过 Windows Native API 尝试清理系统工作集、文件缓存、standby page list、modified page list 等内存区域。它的使用场景很明确：用户不想打开复杂的系统监视器，只希望在桌面上快速看到内存压力，必要时收到提醒，并能通过托盘入口保持长期观察。

把 Mem Reduct 适配到鸿蒙 PC 的价值，不只是让一个小工具多一个系统版本。HarmonyOS PC 面向的是桌面办公和研发场景，系统上也需要一批轻量、常驻、可解释的系统状态工具。内存监控类应用刚好能检验几条典型桌面能力：窗口化 ArkUI、实时系统信息读取、状态栏扩展、通知、后台持续任务、用户配置持久化和文件导出。如果这些能力能在普通三方 HAP 中合规跑通，就能为后续更多 PC 小工具迁移提供可复用经验。

本次适配没有简单照搬 Win32 代码。Windows 版本依赖的 NtSetSystemInformation 等能力在 HarmonyOS 普通应用权限模型中没有等价公共接口，普通 HAP 也不应该伪造“已清理内存”的结果。因此鸿蒙版本选择了更稳妥的路线：原 Win32 源码保留，鸿蒙侧使用 ArkTS + ArkUI 重新实现 PC 界面，通过公开 Kit 完成内存监控、提醒、状态栏、后台任务、配置和导出；真正涉及全局系统内存回收的部分，明确放在 OEM 特权后端边界中。

二、适配边界先讲清楚

Mem Reduct 的核心要分成两部分看：一部分是“监控、提醒、常驻和配置”，这类能力适合普通三方应用实现；另一部分是“清理其他进程工作集和系统页缓存”，这类能力属于系统级资源管理，不能靠把 C/C++ 代码搬进 HAP 来绕过权限。

本次适配的边界如下：

层次	原 Windows 实现	鸿蒙 PC 处理方式
桌面入口	Win32 窗口、菜单、托盘	ArkUI Stage 模型窗口，支持浮动、分屏、全屏和最小尺寸
内存读取	Windows 内存状态 API	HiDebug 读取系统总内存、空闲内存、可用内存和当前应用 PSS
常驻入口	Windows 托盘图标	Desktop / Status Bar Extension Kit 状态栏图标和快捷面板
通知提醒	Windows 通知区域提示	Notification Kit 授权、测试通知和阈值提醒
后台监控	托盘常驻进程	用户可选 `taskKeeping` 后台持续任务
配置文件	`memreduct.ini` / 用户目录配置	Preferences 持久化，DocumentViewPicker 导入导出 INI
历史导出	本地文件写入	URI 授权保存 CSV 历史和诊断 TXT
系统清理	Windows Native API	普通应用版本只说明能力不可用，保留 OEM System Ability 后端边界

这条路线的重点是避免“看起来像适配完成，实际靠演示数据撑页面”。当前鸿蒙版本展示的内存数据来自真机实时采样；无法通过公共 API 完成的系统级清理，则在界面和报告中明确说明限制。

三、适配后的工程结构

仓库保留原 Windows 工程，鸿蒙工程集中在 ohos/，报告和设备证据分别放在 reports/ 与 evidence/：

ohos_memreduct/
├── src/                                      # 原 Win32 主程序、资源和清理逻辑
├── images/                                   # 原项目截图资源
├── README.md                                 # 上游项目说明
├── README.OpenHarmony.md                     # 鸿蒙英文说明
├── README.OpenHarmony_CN.md                  # 鸿蒙中文适配记录
├── ohos/
│   ├── AppScope/
│   │   ├── app.json5                         # 包名、版本、应用图标
│   │   └── resources/base/media/app_icon.png # 原 RAM 模块图标转换资源
│   ├── build-profile.json5                   # SDK、产品和签名配置
│   └── entry/src/main/
│       ├── module.json5                      # UIAbility、状态栏扩展和权限
│       ├── ets/pages/Index.ets               # 主界面、设置页、关于页
│       ├── ets/pages/StatusBarPage.ets       # 状态栏快捷面板
│       ├── ets/services/                     # 内存、通知、后台、导出等服务
│       └── ets/repositories/                 # 设置和历史持久化
├── reports/                                  # 迁移报告、能力矩阵和构建审计
└── evidence/                                 # 真机截图和布局取证

鸿蒙版本包名为 com.henrypp.memreduct.ohos，版本为 0.1.0，目标设备类型为 2in1。当前工程使用 HarmonyOS SDK 6.0.2(22) 构建，最低兼容版本为 5.0.2(14)，声明了 WINDOW_TOPMOST 和 KEEP_BACKGROUND_RUNNING 两个公开权限。

四、真机上的五个核心功能验证

以下五张截图均来自 HarmonyOS PC / 2in1 真机实际运行画面，截图分辨率为 3120 x 2080。验证时已启动当前签名 HAP，页面中的内存占用、采样时间、历史计数、系统通知和文件选择器均来自设备运行状态。

1. 主界面实时展示系统内存和历史采样

应用启动后进入内存概览页。页面显示总物理内存、已使用内存、可用内存、完全空闲内存、当前应用 PSS 和采样时间，并用环形图和历史条形图展示当前压力与最近采样趋势。

在这里插入图片描述

这一屏验证了 HAP 安装、EntryAbility 启动、ArkUI PC 窗口布局、原项目 RAM 图标资源、HiDebug 内存读取、历史采样和深色主题渲染。内存占用不是固定文案，采样时间也随真机运行刷新。

2. 偏好设置覆盖刷新、阈值、冷却和通知

偏好设置页提供刷新间隔、自动阈值检测、检测阈值、提醒冷却时间、结果通知和主题开关。设置保存在应用私有目录中，进程重启后可以恢复。

在这里插入图片描述

对内存工具来说，设置页不能只是静态配置面板。刷新频率会影响采样成本，阈值和冷却时间决定提醒是否打扰用户，通知开关则需要和系统授权状态联动。当前实现把这些状态统一落到 Preferences，并由服务层在监控循环中读取。

3. 历史数据通过系统文件选择器导出 CSV

主界面中的“导出 CSV”会调用系统文档保存选择器，默认文件名为 memreduct-history.csv。应用只获得用户本次选择的 URI 写入权限，不申请宽泛的磁盘访问能力。

在这里插入图片描述

这一步验证了鸿蒙 PC 上文件导出的权限模型。传统 Windows 工具常常直接写本地路径，普通 HarmonyOS 应用则应通过系统选择器完成授权。当前 CSV 导出和诊断 TXT 导出都走同一类 URI 授权路径。

4. 后台持续监控由系统通知显式托管

开启后台持续监控后，应用使用公开的 taskKeeping 后台任务能力，系统通知中心会显示 Mem Reduct 正在运行计算任务。用户可以通过系统通知或应用设置停止任务。

在这里插入图片描述

这张图的重点不是“常驻成功”四个字，而是后台行为由系统显式托管。HarmonyOS PC 对后台任务有清晰的用户可见性要求，适配时不能做静默保活，也不能把后台监控伪装成普通前台页面。

5. 关于页明确普通应用和 OEM 特权能力边界

关于页展示当前版本、原始开源项目地址、普通应用适配范围和 OEM 特权适配范围。系统级工作集、文件缓存和页列表清理被归入需要审批 System Ability 后端的能力。

在这里插入图片描述

这个页面承担的是产品边界说明。Mem Reduct 的 Windows 版以系统清理见长，但 HarmonyOS 普通 HAP 不能等同拥有系统资源管理权限。把边界写在用户能看到的位置，比在实现里返回一个看似成功的清理结果更负责。

五、适配过程中遇到的主要困难

难点一：Windows 内存清理 API 没有普通 HAP 等价能力

原版 Mem Reduct 的清理动作依赖 Windows 内部能力。HarmonyOS 普通应用无法清理其他进程工作集，也没有公开 API 可以清理系统文件缓存、standby list 或 modified list。适配时如果强行把这部分写成“已完成”，最终只会得到一个误导用户的按钮。

因此当前实现专门抽出了 CleanupService 边界。普通应用后端只返回能力不可用说明，不伪造回收量；如果后续要做系统预装版，可以由 OEM 提供经过审批的 System Ability，再通过受控 IPC 接入。

难点二：桌面小工具需要状态栏和后台任务协同

内存监控工具不是一次性打开看一眼就结束的应用。用户更常见的使用方式是把它放到状态栏或后台，等系统压力升高时再提醒。HarmonyOS PC 的状态栏扩展、后台持续任务和通知授权分别属于不同能力，生命周期也不同。

适配中把状态栏图标、快捷面板、后台 taskKeeping 和通知服务拆成独立服务，再由设置页统一开关。这样主窗口关闭或最小化时，监控状态仍能被系统看见，也能被用户主动停止。

难点三：文件导入导出不能沿用传统桌面路径假设

Windows 便携应用常用 INI 文件和固定路径保存历史。HarmonyOS 普通应用访问用户文件需要通过选择器授权，返回的可能是 URI，而不是传统绝对路径。CSV 历史、诊断报告和 INI 导入导出都必须按 URI 授权读写处理。

这部分适配的关键是把文件能力做成“用户选择一次，应用写入一次”，避免申请不必要的存储权限。这样既符合平台安全模型，也减少了后续迁移到正式分发渠道时的权限风险。

难点四：PC 窗口布局不能只按移动端思路写

Mem Reduct 在鸿蒙 PC 上运行时面对的是键鼠、任务栏、大分辨率和可调整窗口。适配中为 Ability 声明了浮动、分屏、全屏窗口模式和最小窗口尺寸，并重新组织左侧导航、主内容区、设置项和底部按钮。

真机截图中可以看到，主界面没有把移动端列表简单拉宽，而是按桌面工具的阅读方式组织信息：左侧固定导航，右侧显示概览卡片、历史图表和操作按钮。设置页也使用横向空间承载滑块、开关和说明文案。

难点五：原项目品牌资源需要完整替换

迁移早期很容易为了快速出包使用临时图标。最终版本把安装图标、窗口标题图标、主界面 Logo、任务栏图标和状态栏图标都统一回原项目 RAM 模块图案。对于系统工具类应用来说，图标是用户在任务栏和状态栏中快速识别应用的主要线索，不能只在主页面露出一次。

六、构建、安装与运行

进入鸿蒙工程目录后，使用 DevEco Studio 自带 Hvigor 构建签名 HAP：

cd ohos

/Applications/DevEco-Studio.app/Contents/tools/hvigor/bin/hvigorw \
  assembleHap --mode module \
  -p product=default \
  -p module=entry@default \
  -p buildMode=debug \
  --no-daemon

当前签名产物位于：

ohos/entry/build/default/outputs/default/entry-default-signed.hap

连接 HarmonyOS PC 真机后安装并启动：

hdc list targets

hdc install -r ohos/entry/build/default/outputs/default/entry-default-signed.hap

hdc shell aa start \
  -a EntryAbility \
  -b com.henrypp.memreduct.ohos

启动后可在主界面查看实时内存采样，在偏好设置中调整刷新、阈值、通知、主题和后台监控，并通过主界面导出 CSV 历史。状态栏扩展启用后，Mem Reduct 会在 PC 状态栏中显示原 RAM 模块图标和快捷状态面板。

七、当前能力与边界

当前鸿蒙版本已在真机上验证以下能力：

ArkTS / ArkUI 编译、HAP 打包、签名、安装和 EntryAbility 启动；
原项目 RAM 模块图标用于应用、窗口、任务栏和状态栏入口；
HiDebug 实时读取系统总内存、空闲内存、可用内存和当前应用 PSS；
主界面展示占用率、采样时间、最近 24 次历史和最多 120 次持久化采样；
刷新间隔、阈值、提醒冷却、通知、主题、置顶、状态栏和后台监控设置持久化；
Notification Kit 授权、测试通知、阈值通知和后台任务通知；
taskKeeping 后台持续监控由用户主动开启，并由系统通知显式展示；
Desktop / Status Bar Extension Kit 状态栏入口和快捷面板；
INI 导入导出、CSV 历史导出和诊断 TXT 导出；
深色/浅色主题、窗口置顶、PC 浮动窗口和最小尺寸约束；
关于页展示版本、上游来源、普通应用能力范围和 OEM 能力范围。

以下能力没有声明为普通应用版本已完成：

清理其他进程工作集；
清理系统文件缓存；
清理 standby / modified page list；
Windows registry cache 相关能力；
Windows page-file 细粒度统计；
全局清理热键和开机自启动；
不经过用户授权的全盘文件读写；
不可见的静默后台保活。

更准确地说，当前版本已经完成了“鸿蒙 PC 普通应用权限下的内存监控、提醒、常驻入口、历史和导出闭环”。它不是 Windows 版系统清理能力的无差别复制，系统级清理仍需要后续 OEM 特权后端配合。

八、总结

Mem Reduct 的适配说明，传统 Windows 系统工具迁移到 HarmonyOS PC 时，最重要的不是逐行搬运 API，而是把原工具的用户价值重新拆开：哪些能力可以通过公开 Kit 合规落地，哪些能力属于系统权限，哪些体验需要按 PC 窗口和状态栏重新设计。

当前鸿蒙版本已经能在真机上完成实时内存监控、历史采样、阈值提醒、通知、后台持续任务、状态栏入口、配置持久化和文件导出。对于普通用户来说，它已经是一个可运行、可配置、可长期观察的内存监控工具；对于系统级清理能力，则通过清晰的服务边界留给 OEM System Ability，而不是用不可验证的结果掩盖权限差异。

后续继续推进时，重点应放在更长时间的后台稳定性测试、状态栏右键入口、阈值冷却重复触发验证、正式签名分发，以及 OEM 特权清理后端的接口设计上。这样既能保留 Mem Reduct 原本的轻量体验，也能让鸿蒙 PC 版本符合平台的安全和权限模型。

模型。