一點雨景需要多少資源？
測量於 2026 年 9 月 28 日 · Apple M4 Max · 一塊內建顯示器
Weatherling 在視窗周圍繪製動態雨景，執行時會消耗 CPU、GPU 和記憶體。有人問開銷有多大。這裡介紹測量方法、最近的結果，以及仍需測試的部分。
在這臺 Mac 上，兩次有效的短時預設測試平均佔用單個 CPU 核心的 2.97–3.75% 和 375–391 MiB 實體記憶體。四小時測試的記憶體佔用隨時間增加，達到約 467 MiB 後在最後一小時趨於穩定。這只是某個版本在一臺機器上的測量，不代表所有 Mac，也不能作為續航承諾。
測試所用的 Mac 和構建版本
本次使用配備 Apple M4 Max、64 GB 記憶體和 macOS 27.0 的 MacBook Pro。內建顯示器為 3456 × 2234 畫素、2× 縮放，報告重新整理率為 120 Hz。Mac 接通電源，自動亮度保持開啟；測試期間仍進行日常工作，開始時有九個可見視窗。這不是隔離且閒置的實驗室桌面。
App 為本地 Release 構建，版本標為 1.3（構建 3），基於提交0ed73f4 ，另外還包含隨測試記錄的本地音訊與輸入跟蹤改動。Release 構建採用正式的編譯器最佳化，並不表示該可執行檔案就是 App Store 目前版本。我在採集前固定了一份副本，避免後續程式碼修改替換被測程式。
基準測試如何進行
我測量的是原生 App 在桌面繪製雨景的開銷。瀏覽器動畫、截圖或離屏渲染測試無法反映在視窗間持續疊加效果的完整成本。臨時設定讓各階段可重複，又不覆蓋使用者偏好。
- 先退出 App。 記錄一分鐘系統基線，再啟動 App 但關閉雨景。等待 30 秒穩定後，取樣三分鐘。
- 執行預設雨景。 使用 0.35 強度、自動畫質 30 fps、固定風力和景深，關閉聲音與近景粒子。預熱兩分鐘，測量十分鐘。
- 執行強降雨。 使用最大強度、流暢畫質 60 fps、近景粒子和聲音。同樣預熱兩分鐘，再測量十分鐘。
- 重複三輪。 多輪測量能顯示單個漂亮數字會掩蓋的波動。最後再記錄一次退出 App 後的基線。
- 讓預設雨景持續執行四小時。 重新預熱後，在整個長時間執行中跟蹤記憶體和 CPU，包括結束前的變化趨勢。
全流程約五個半小時。測試工具讓顯示器保持喚醒，臨時預設允許雨景覆蓋全螢幕 App。這些是測量條件，並不能說明正常睡眠行為。獨立的 GPU 跟蹤、網路觀察和記憶體對映快照在 CPU 與記憶體取樣視窗外進行。接受結果前，我會檢查暫停、意外退出和分析器重疊等日誌。
最近的結果
| 場景 | 完成的樣本 | 平均 CPU | 平均實體記憶體 |
|---|---|---|---|
| 關閉雨景，全新啟動 | 3 次 × 3 分鐘 | 0.23–0.82% | 26.0–26.4 MiB（實體記憶體） |
| 預設雨景，30 fps | 2 次有效測試 × 10 分鐘 | 2.97–3.75% | 375.0–390.5 MiB（實體記憶體） |
| 強降雨，60 fps | 3 次 × 10 分鐘 | 6.17–10.01% | 411.7–419.3 MiB（實體記憶體） |
| 預設雨景，耐久測試 | 4 小時 | 5.64% | 441.5 MiB（實體記憶體） |
CPU 百分比以單個核心為 100%，並非整個處理器。記憶體使用物理佔用量，包含圖形記憶體記賬，而不是某些工具顯示的較小駐留記憶體值。關閉雨景的資料來自全新啟動且未啟用雨景的狀態，並非關閉已執行效果後保留的記憶體。
為謹慎起見，排除了第一輪預設測試：某條 App 排除規則在預熱末段暫停了雨景，截圖工具活動也跨入了取樣時間段。所有階段均完成，但短時預設測試只有兩輪完全有效。強降雨的 CPU 佔用在不同輪次間也有明顯波動。桌面活動不斷變化，難以將波動完全歸因於 Weatherling。
為什麼要持續執行四小時
十分鐘測試可能漏掉後期累積的分配。耐久測試中，實體記憶體從379.9 增至 467.1 MiB，取樣峰值為469.7 MiB（峰值）。逐小時平均值為 421.0、435.0、442.8 和 467.0 MiB。最後一小時基本持平，擬合趨勢約為每小時增加 0.1 MiB。
後期穩定是有用的證據，但不能證明沒有記憶體洩漏；前期增長仍值得調查。四小時的平均 CPU 佔用為單核的 5.64%，第 95 百分位為 12.15%，即 95% 的取樣區間不高於此值。耐久測試期間未記錄到生命週期暫停。反覆開關、顯示器重連及睡眠喚醒需另行測試。
GPU 開銷與流暢度
獨立的 Metal System Trace 記錄顯示，預設畫質約每秒 30 次呈現回撥，強降雨畫質約 60 次。每個命令緩衝區的 GPU 活躍時間平均值／第 95 百分位，預設狀態為 0.307／0.758 毫秒，強降雨為 0.375／0.596 毫秒。作為參照，30 fps 每幀預算為 33.3 毫秒，60 fps 則為 16.7 毫秒。
每段跟蹤約 31 秒。預設狀態有一次回撥間隔超過 50 毫秒，強降雨有 15 次超過 25 毫秒。這能使用說明描述節奏，但不是直接的顯示延遲或精確掉影格數。GPU 執行時間也不是 GPU 利用率。我將分析器自身開銷與較長的 CPU、記憶體測量分開。
對續航有什麼影響？
本次測試無法回答 Weatherling 會讓電池少用多少分鐘。短時測試中採集了系統功耗估算，並觀察負責合成桌面的 macOS 程序 WindowServer。這些讀數包含其他 App 和變化中的桌面工作。將兩個繁忙系統讀數相減，無法得到可靠的 App 獨立功耗。
功耗記錄從首次關閉雨景階段的中途開始，在耐久測試早期結束。因此最初的退出 App 基線和四小時階段的大部分時間沒有功耗樣本。可靠的續航結論需要受控的電池供電測試、一致的亮度與負載，並比較 App 執行與退出狀態。我尚未完成這樣的測試。
如何保證測量可信
CPU 取樣器讀取 macOS 程序計數器，並用程序 CPU 時鐘驗證時間換算。約每兩秒取樣實體記憶體和磁碟 I/O。我儲存可執行檔案雜湊、App 版本、原始碼狀態、設定、時間戳及生命週期日誌，以便追溯結果。本次分析器執行在測量視窗前結束，儲存的設定在測試後保持不變。
短時網路快照僅反映對應時段；空快照不等於證明 App 永不聯網。同樣，物理磁碟寫入為零也不表示沒有邏輯檔案活動。原始跟蹤保留在本地，因為可能包含測試 Mac 上其他程序的資訊。本頁只發布彙總結果和測試條件。
還需測試效能較弱的 Mac、外接顯示器、電池供電、低電量模式，以及系統性的睡眠與顯示器切換。本次也未單獨測量每種 Ling™ 的開銷。未來會儘可能沿用相同流程，並明確標出硬體、設定和構建變化，而不混成一個概括數字。
如果您 Mac 上的表現不同，請提交報告 ，附上 Mac 型號、App 版本、顯示器配置和雨景設定。這些資訊能使用說明我把籠統的問題轉化為可重複的測試。