16GB Mac 内存占用怎么看？我做了一个常驻桌面的 Memory HUD

给 16GB Mac 的一块常驻内存仪表盘

我日常会同时打开浏览器、ChatGPT、Codex、IDE 和几个 CLI 工具。对一台 16GB Mac 来说，真正麻烦的往往不是“内存用了多少”，而是很难一眼看清：到底是哪个 App 家族、哪个 Helper，还是哪个终端任务正在持续占内存。

活动监视器当然能看，但每次都要打开、排序，再从一排 Renderer、Service 和 Helper 中判断它们属于谁。我想要的是一块常驻桌面的仪表盘：工作时抬眼就能看到内存压力，也能知道主要占用来自哪里。我要的不是事后复盘，而是在工作还在进行时，先看见资源压力的线索。

所以我做了 Kenton Memory HUD。

它不清理内存，不会把 16GB 变成 32GB，也不承诺让 Mac 自动变快。它做的事情很克制：把当前机器上可读的资源占用持续摆在桌面上。

这套工具主要围绕 16GB Apple Silicon Mac 的重度多任务场景设计，也适用于满足系统要求的其他内存容量 Mac。源码仓当前保持私有，不提供源代码或预编译应用下载。

这个 Skill 解决的是“工作时看不见”

在这里，我说的 Skill 指的是 Memory HUD 提供的这项实用能力：让 16GB Mac 的内存压力在工作时保持可见。工程上，它是一款原生 macOS App；在真实使用中，它像一层常驻桌面的内存态势感知，把原本藏在活动监视器里的状态持续留在余光里。

当内存压力从正常变为偏高或严重，或者某个 App 家族、CLI 任务长时间占据排行前列时，用户可以自己判断是否先保存工作、暂停任务或关闭高占用应用。它不会自动替人决策，但让人多一个在问题发生前先看见线索的机会。

它不会预测崩溃，也不监控网络，更不能保证防止应用退出、任务中断或系统卡死。它真正提供的是观察窗口：当问题确实与内存压力有关时，让用户不必等到电脑已经失去响应，才想起打开活动监视器。

它实际显示什么

HUD 分成三部分：

• 当前内存压力，以及估算已用、物理内存、压缩内存、文件缓存和 Swap。
• App Top 5，显示同一个最外层 .app 下面多个进程的 footprint 合计和进程数。
• CLI Top 3，显示当前用户、有控制终端、非 Shell 且不属于 .app 的命令行程序，并把同一路径的多个 PID 合成一行。

完整视图可以拖动、固定、收起，也可以切换到始终置顶。收起后只保留内存压力与已用摘要。隐藏、锁屏或睡眠时，采样会暂停。

为什么不能只看一个主进程

Chrome、ChatGPT、Codex 和许多 Electron 应用都会拆成多个进程。只看主 PID，会漏掉 Renderer、Service 和 Helper；但把机器上所有 PID 直接相加，又会把共享页和不相关后台进程混在一起。

Memory HUD 选择了一个可解释的中间方案：按照 executable path 中最外层的 .app 归组，把同一 bundle 里的可读 PID footprint 相加，并明确显示“进程 footprint 合计”和进程数。

一个 App
├── 主进程
├── Renderer
├── Service
└── Helper
        ↓
一行 App · 4 个进程 · footprint 合计

这里的数字不是“独占内存”。共享页可能出现在多个进程的 footprint 中，它也不是 Apple 没有公开稳定合同的私有 coalition 口径。

CLI 为什么不算进 Terminal

Terminal 自己的 footprint，和 Terminal 里运行的 Codex、Claude CLI、Node 或 Python 任务不是一回事。

CLI 榜单只纳入同时满足下面条件的进程：

• 属于当前登录用户。
• 拥有控制终端。
• executable path 不在任何 .app 内。
• 不是 zsh、bash 等 Shell 本身。
• 同一路径出现多个 PID 时合并展示。

这意味着无 TTY 的后台任务、其他用户的系统进程和部分外部解释器 Helper 不会进入榜单。因此页面写的是“CLI 同路径进程合计”，不是“全系统 CLI 排行”。

为什么主卡写的是“估算已用”

进程排行使用 macOS SDK 随附的 proc_pid_rusage(...).ri_phys_footprint。系统主卡则从 Mach VM 页计数构建下面三项：

应用内存估算 = max(internal - purgeable, 0) × pageSize
估算已用 = min(物理内存, 应用内存估算 + wired + compressed)
文件缓存 = min(物理内存, external × pageSize)

相邻采样中，应用内存估算和压缩内存可以与活动监视器的对应值对上；“估算已用”仍可能相差数百 MB，因为 Apple 的完整分类还包括工具没有复刻的页类别。所以界面保留“估算”两个字，而不是假装逐字节一致。

它自己占多少内存

在一台 Apple M4、16GB 内存、macOS 26.2 的 Mac mini 上，v0.3.0 Build 5 稳定运行约 80 秒后测得：

• 主 HUD：约 26.74 MB
• recovery helper：约 1.05 MB
• 去重合计：约 27.69 MB

这是指定机器、指定版本和指定采样时刻的结果，不是所有 Mac 上恒定不变的承诺。两者当时的 ps CPU 瞬时采样都是 0.0%，但这也不代表 CPU 永远为零。核心读取器按默认两秒刷新折算约占单核 0.25%，完整 UI 的实际占用仍会随环境变化。

异常退出后为什么还能回来

恢复功能默认关闭。用户显式打开“登录与异常退出自动恢复”后，应用才会注册一个低占用的 user LaunchAgent。

当前完成的真机验证包括：

• recovery helper 自身退出后可以恢复。
• HUD 收到 SIGTERM 后可以由 helper 重新打开。
• 从菜单正常退出时，会先注销恢复服务并删除 plist，三秒内没有复活。

尚未验证的范围包括真实 WindowServer 重建、重新登录、多显示器重排和 Stage Manager 开启。一次 SIGTERM 测试不能替代这些场景，所以它们仍然保持未验证状态。

当前测试证据

当前源码的 Swift Testing 共 47 项：默认执行时 46 项通过、1 项真实进程集成测试显式跳过；开启 live integration 后为 47/47。MemoryHUDCore 行覆盖率门限固定为至少 80%，本轮默认结果为 87.81%，live 环境根据真实进程分支为 94.85% 至 96.23%。

这里的覆盖率只代表 MemoryHUDCore，不声称 AppKit 主程序、LaunchAgent 边界与 C helper 的全部生产代码拥有同一覆盖率。它们另外通过行为测试、编译闸门和真机回读验证。

适合谁，不适合谁

它适合：

• 使用 16GB Mac、经常同时打开浏览器、AI 应用、IDE 和 CLI 的人。
• 想持续观察 App 家族和终端任务 footprint 的开发者。
• 接受统计口径透明，而不是追求一个看起来绝对精确数字的人。
• 偏好原生、离线、无需管理员权限工具的人。

它不适合：

• 需要历史曲线、告警、云同步或团队监控的人。
• 需要看到所有 root 和系统进程的人。
• 需要逐字节复刻活动监视器私有分类的人。
• 需要已经签名、公证并可以直接安装的成品应用的人。

当前发布边界

Kenton Memory HUD 的源码仓当前保持私有。本文只公开产品定位、统计口径、本机测试证据和已知限制。

当前不提供源代码、预编译 .app、DMG 或其他安装包的公开下载。