一点雨景需要多少资源？
测量于 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 接通电源，自动亮度保持开启；测试期间仍进行日常工作，开始时有九个可见窗口。这不是隔离且闲置的实验室桌面。
应用为本地 Release 构建，版本标为 1.3（构建 3），基于提交0ed73f4 ，另外还包含随测试记录的本地音频与输入跟踪改动。Release 构建采用正式的编译器优化，并不表示该可执行文件就是 App Store 当前版本。我在采集前固定了一份副本，避免后续代码修改替换被测程序。
基准测试如何进行
我测量的是原生应用在桌面绘制雨景的开销。浏览器动画、截图或离屏渲染测试无法反映在真实窗口间持续叠加效果的完整成本。临时设置让各阶段可重复，又不覆盖用户偏好。
- 先退出应用。 记录一分钟系统基线，再启动应用但关闭雨景。等待 30 秒稳定后，采样三分钟。
- 运行默认雨景。 使用 0.35 强度、自动画质 30 fps、固定风力和景深，关闭声音与近景粒子。预热两分钟，测量十分钟。
- 运行强降雨。 使用最大强度、流畅画质 60 fps、近景粒子和声音。同样预热两分钟，再测量十分钟。
- 重复三轮。 多轮测量能显示单个漂亮数字会掩盖的波动。最后再记录一次退出应用后的基线。
- 让默认雨景持续运行四小时。 重新预热后，在整个长时间运行中跟踪内存和 CPU，包括结束前的变化趋势。
全流程约五个半小时。测试工具让显示器保持唤醒，临时预设允许雨景覆盖全屏应用。这些是测量条件，并不能说明正常睡眠行为。独立的 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%，并非整个处理器。内存使用物理占用量，包含图形内存记账，而不是某些工具显示的较小驻留内存值。关闭雨景的数据来自全新启动且未启用雨景的状态，并非关闭已运行效果后保留的内存。
为谨慎起见，排除了第一轮默认测试：某条应用排除规则在预热末段暂停了雨景，截图工具活动也跨入了采样时间段。所有阶段均完成，但短时默认测试只有两轮完全有效。强降雨的 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。这些读数包含其他应用和变化中的桌面工作。将两个繁忙系统读数相减，无法得到可靠的应用独立功耗。
功耗记录从首次关闭雨景阶段的中途开始，在耐久测试早期结束。因此最初的退出应用基线和四小时阶段的大部分时间没有功耗样本。可靠的续航结论需要受控的电池供电测试、一致的亮度与负载，并比较应用运行与退出状态。我尚未完成这样的测试。
如何保证测量可信
CPU 采样器读取 macOS 进程计数器，并用进程 CPU 时钟验证时间换算。约每两秒采样物理内存和磁盘 I/O。我保存可执行文件哈希、应用版本、源码状态、设置、时间戳及生命周期日志，以便追溯结果。本次分析器运行在测量窗口前结束，保存的设置在测试后保持不变。
短时网络快照仅反映对应时段；空快照不等于证明应用永不联网。同样，物理磁盘写入为零也不表示没有逻辑文件活动。原始跟踪保留在本地，因为可能包含测试 Mac 上其他进程的信息。本页只发布汇总结果和测试条件。
还需测试性能较弱的 Mac、外接显示器、电池供电、低电量模式，以及系统性的睡眠与显示器切换。本次也未单独测量每种 Ling 的开销。未来会尽可能沿用相同流程，并明确标出硬件、设置和构建变化，而不混成一个概括数字。
如果您 Mac 上的表现不同，请提交报告 ，附上 Mac 型号、应用版本、显示器配置和雨景设置。这些信息能帮助我把笼统的问题转化为可重复的测试。