Hedroom 的工作原理，一步一步来

Hedroom 从 macOS 读取少量数字，发现某个 App 出了问题时，提出一项修复建议，并在你接受之后测量发生了什么。下面是每一步，以及它使用的阈值。

本页的数字来自 Hedroom 自己的设计文档和代码。凡是测量得出的数字，都会说明是什么时候、在哪台 Mac 上测的。Hedroom 尚未发布，所以这里的内容都不是在描述某个公开版本。

1. 采样：读取什么，多久读取一次

所有读数都来自一个在主线程之外运行的采样器，所以 App 能保持响应。每个来源都是接口背后的一段独立代码，这也是用模拟数据测试它的方式。这些来源是：

周期

“周期”是一轮读数。它发生的频率取决于你在做什么：

“设置”里有“检查我的 Mac 的频率”这一选项，可选 2、5 或 10 秒，用于窗口打开时的频率；后台的频率按它成比例调整。原始读数保留 48 小时。一切都留在你的 Mac 上，存放在你的资源库文件夹中的一个数据库文件里。请见隐私。

2. 检测：什么算作发现

Hedroom 不会因为某个数字大就发出提醒。它会把每个 App 与它在你的 Mac 上通常的大小进行比较，并等着看这种变化是否持续。

内存：健康、吃紧、严重

Hedroom 显示三种状态之一。阈值都是写明的，并且经过测试。

仅仅是被使用的交换空间，绝不会让 Mac 进入“吃紧”，因为 macOS 会保留旧的交换数据。只有正在增长的交换空间才算数。“已用”内存很高但压力健康，仍然是“健康”。为什么看压力，而不是已用内存解释了其中的区别。

泄漏：某个 App 长时间远超它平时的大小

对每个 App，Hedroom 会根据你最近 7 天的正常使用了解它平时的大小。只有以下条件全部成立，它才会标记泄漏：

• 该 App 至少是它平时大小的 3 倍。达到 2.5 倍时只显示为“在增长”，不会更多。
• 它至少有 1 GB，或者在更大时达到你 RAM 的 6%。
• 它已连续 20 分钟保持在那里，或者在 30 分钟的趋势上持续增长。
• 它不在你“从不触碰”的名单上，不是 Apple 制作的（你自己使用的 Apple App 有一个小例外），也不是说明库标注为通常就很大的 App，例如视频编辑器或 Docker。

在 Hedroom 了解某个 App 大约 6 小时之前，它会说明自己仍在学习。对于它按名称认识的 App，它使用说明库中的典型大小；对于不认识的 App，它只会标记至少占你 RAM 的 15% 且仍在增长的大小，并且写“异常大”，而不是写倍数。

失控的 CPU

某个后台 App（不是你正在使用的那个）如果 3 分钟内平均占用一个核心的 80% 或更多，并且至少是它自己平时后台 CPU 的 3 倍，就算失控，除非说明库把它标注为通常就很忙（编译器、备份、视频编码器、索引），或者它正在通话。它在 3 分钟后显示在“今天”。通知要等到持续 10 分钟后才会发出。

噪音控制

关于同一个 App 的同一项发现，最多每 6 小时通知一次。非紧急通知每天最多 3 条。对某个 App 的通知忽略三次后，Hedroom 就不再通知它，并提供一个“从不触碰”条目。

3. 决定：一项建议，然后是安全关卡

当 Hedroom 能做的事不止一件时，它会按能找回多少与风险有多大来排序，并显示前两项。强制退出绝不会作为排序后的修复被提供。

在任何重新打开、退出、暂停或移到能效核心之前，请求都要经过一道安全关卡。当目标是下面这些时，关卡会拒绝：

• Hedroom 自己（悄悄忽略）。
• 由 Apple 制作，或位于系统文件夹中，但你自己使用的 Apple App 除外，这些你可以点一下就重新打开或退出。
• 在你“从不触碰”的名单上。
• 你现在正在使用的 App，当规则要求暂停、移动或退出它时。
• 正在播放音频、使用麦克风，或者摄像头开着时的通话 App。
• 备份进行期间的备份 App。
• 不确定能否安全暂停的 App，当规则想要暂停或退出它，而且不是你自己选的 App 时。Hedroom 无法可靠地看到未存储的工作。
• 说明库标注为不适合重新打开的 App，在严重压力期间。
• 没有第二次、单独确认的强制退出。

如果 Hedroom 无法检查其中某一项（例如音频检查失败），规则什么都不做，点按操作会先询问你。拒绝会连同原因一起显示，比如一句“Slack 正在通话。”，而不是显示成错误。所有被拒绝或已执行的操作都会被记录。更多内容见Hedroom 绝不会做的事。

4. 行动，经你同意

这些操作都很小，而且可以撤销：

• 重新打开请 App 退出，就像按 ⌘Q 一样，等待，然后再次打开它。
• 能效核心降低 App 的优先级，让它的工作在能效核心上运行。
• 暂停冻结 App，直到你切换回它，或最长 60 分钟。即使 Hedroom 崩溃，一个小型守护进程也会让它恢复。

点按一个按钮，就是对该操作的同意。规则是你事先给出的同意，并且每个模板出厂时都是关闭的。退出或重新打开一个不确定是否安全的 App，始终会先询问。没有你每次的许可，绝不会删除任何内容；清理会把文件移到废纸篓。修复和规则列出了每一项限制。

5. 回执：之前、之后，以及一个诚实的结论

每次操作都会产生一份回执。Hedroom 会把操作前 5 分钟的读数，与操作后 5 到 15 分钟的读数进行比较，并在系统稳定期间跳过最初的 30 秒（重新打开之后是 60 秒）。

有四种诚实的结果：

• 已测量。变化至少达到 Hedroom 计入的最小值：内存 100 MB、一个 CPU 核心的 10 个百分点、0.3 W，或磁盘 50 MB。
• 没有效果。变化比这更小，或者方向不对。回执会写“没有可测量的效果。”，并且不居功。
• 无法测量。同一时间其他 App 的变化太大（另一个 App 的变化超过 1 GB、新启动的 App 占用超过 500 MB、你退出了其他 App、Mac 睡眠过，或者电源被接上或拔掉）。回执会如实说明，而不是居功，并且不计入总计。
• 已取消。在测量完成之前，你撤销了操作，或者 Hedroom 退出了。不声称任何效果。

每份回执还带有一个可信度等级（高、中或低）。可信度低的回执会标为“粗略”，并且不计入总计。回执比较的是两个时间窗口；它不是对照实验。要了解如何阅读，请见如何阅读回执。

为什么看内存压力，而不是已用内存

开机一段时间的 Mac，按设计会把大部分内存显示为已用。macOS 会用缓存的文件填满空闲内存，因为这样你接下来打开的东西会更快，而一旦有 App 需要，它会立刻交还。内存条被占满并不是问题。要紧的是 macOS 是否在费力地腾出空间：这就是内存压力，再加上交换空间增长的速度。这就是 Hedroom 没有“清理”内存的按钮的原因。那样做会迫使 macOS 丢掉有用的缓存。关于压力与已用内存的指南介绍了如何在“活动监视器”中自己检查这一点。

是什么让它开销很低

Hedroom 的预算是：平均占用不到一个 CPU 核心的 0.5%，内存不到 80 MB。目前已测得的结果：

请把这些当作实测，而不是承诺。这只是一台 Mac，而且部分运行是在更快的 2 秒周期下进行的，因为那台 Mac 当时处于内存压力下。安装后的第一次运行会进行存储空间扫描，这会以低优先级、最多占用一个核心，持续几分钟。除“今天”之外的其他标签页没有全部重新测量。在同一份记录中的修复之前，打开一个窗口会占用一个核心的 20% 到 40%；这是在这次测试中发现并修复的。原始文件和完整的记录在代码仓库的 bench/results 文件夹中，“设置”会显示 Hedroom 在你的 Mac 上自身的实测开销。发布关卡是基准测试，以及对已签名版本进行的一次开销测试，这些尚未进行。

让它保持轻量的做法：一切共用一个采样器，没有事发生时放慢周期，后台只每隔几个周期扫描一次每个 App，窗口内容只在窗口显示在屏幕上时才构建，窗口隐藏时动画会停止。

它拒绝触碰的内容

• macOS 本身：任何由 Apple 签名或位于系统文件夹中的内容。Hedroom 会解释这些进程，例如 kernel_task 和 WindowServer，但绝不会暂停、减慢或退出它们。请见kernel_task、WindowServer 及其他进程的解释。
• 你面前的 App、正在通话的 App、正在播放音频或使用麦克风或摄像头的 App，以及备份进行期间的备份 App。
• 你“从不触碰”名单上的 App。
• 你的文件，除非你亲自确认每一次删除。清理会先移到废纸篓。

完整的清单，以及每一行背后的测试，在Hedroom 绝不会做的事。接下来：每项功能及其局限、Hedroom 与其他工具的对比，以及术语表。