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 與其他工具的對比，以及術語表。