静默空闲：优化前后的 Windows 后台
本页内容
禁用 Windows 后台组件确实能让空闲状态更安静：在两个独立的测量系列中，进程数下降了 49–56 %，空闲 CPU 占用下降了 17–67 %，内存提交量（commit）在第二个系列中下降了 52 %。但在 CPU 满载下，吞吐量仅提升了 0,2–0,5 %。「安静的空闲」是后台工作和资源竞争被确认减少，而不是 FPS 提升：本研究中最终的游玩效果并未被测量。
状态： 效果方向已在同一 Windows 11 版本的虚拟机上的两个独立系列中复现。各系列之间的数值存在差异，因为 Windows 的后台工作呈突发式：在包含 Microsoft Defender 扫描的窗口中，CPU 占用差异可达 −67 %，而在已经安静的窗口中为 −17 %。
待验证的论断
Section titled “待验证的论断”我们验证了四项论断：
- 禁用后台组件会明显降低系统在空闲状态下的活动。
- 它会明显降低启动后最初几分钟内的活动。
- 它会明显减少内存占用。
- 它会在 CPU 满载下带来可测量的性能提升。
- Windows 11 Pro，build 26300.9457 (26H2)；
- 虚拟机：4 vCPU、8 GB RAM、VMware 虚拟化；
- 同一安装的两个状态：原始状态（「之前」）和应用 BoosterX 优化配置文件之后（测量日期时的当前版本）；
- 两个独立的测量系列：2026-09-18 和 2026-09-19；各状态在独立的磁盘副本上进行比较，以免测量相互影响；
- 阶段：启动后 5 分钟、稳定 5 分钟、空闲 5 分钟；
- 短时合成负载：1、4 和 8 线程、内存负载、节拍式负载以及优先级混合。
测量未包含真实游戏、GPU 负载、物理硬件以及长时间窗口（数小时和数天）。
协议符合「我们如何研究 Windows」：
- 每个阶段都用 ETW 跟踪（Windows Performance Recorder，轻量级 CPU、磁盘、文件和网络配置文件）以及性能计数器记录，系统间隔 5 秒、按进程间隔 15 秒；
- 「启动后」阶段通过受控重启启动，并在运行时间约为一分钟时开始记录；
- 每条跟踪都检查了丢失事件数——在所有给出的窗口中它均为零；
- 平均仅按阶段边界内的完整五秒区间计算（每阶段 59 个区间）；
- 在系列 2 中，第一次「之前」运行因虚拟机进入睡眠而被排除；使用了重复运行；
- 负载测试各执行两次，给出中位数；CPU 占用按四个 vCPU 归一化。
「之前」和「之后」是同一 Windows 安装的状态：「之后」通过应用优化配置文件获得，「之前」是原始状态。更改的是整套设置，因此未评估单个禁用项的独立贡献。
系列 1（2026-09-18）——无活跃维护的稳定空闲：
| 指标 | 之前 | 之后 | 变化 |
|---|---|---|---|
| CPU 占用，% | 2,48 | 2,06 | −17 % |
| DPC + ISR，% CPU | 1,73 | 1,59 | −8 % |
| 上下文切换，/秒 | 469 | 381 | −19 % |
| 进程数（平均） | 134,9 | 69,3 | −49 % |
| 线程数（平均） | 1 444,6 | 738,7 | −49 % |
| 所有进程的 CPU 总和，% | 1,22 | 1,06 | −13 % |
| 可用内存，MB | 5 490 | 6 518 | +1 028 |
| 磁盘读取，KB/秒 | 22,6 | 24,4 | +8 % |
| 磁盘写入，KB/秒 | 311,3 | 262,1 | −16 % |
| 网络（接收），KB/秒 | 132,6 | 2,2 | −98 % |
| 网络（发送），KB/秒 | 43,2 | 4,7 | −89 % |
系列 2（2026-09-19）——相同的空闲窗口，但在「之前」状态下执行了 Microsoft Defender 后台扫描：
| 指标 | 之前 | 之后 | 变化 |
|---|---|---|---|
| CPU 占用，% | 33,37 | 11,03 | −67 % |
| 上下文切换，/秒 | 3 737 | 291 | −92 % |
| 进程数（平均） | 142,3 | 61,9 | −56 % |
| 线程数（平均） | 1 494,7 | 637,1 | −57 % |
| 可用内存，MB | 5 174 | 6 653 | +1 479 |
| 已用物理内存，MB | 3 017 | 1 538 | −49 % |
| 内存提交量（commit），MB | 2 617 | 1 249 | −52 % |
| Nonpaged pool，MB | 298,2 | 212,9 | −29 % |
| Paged pool，MB | 258,5 | 86,0 | −67 % |
| DPC，% CPU | 0,89 | 0,19 | −78 % |
| 磁盘读取，MB/秒 | 7,42 | 0,01 | −99,9 % |
| 磁盘写入，MB/秒 | 4,57 | 0,23 | −95,0 % |
系列 2 的空闲中两种状态下网络几乎都不存在（每秒数十字节），因此未给出其网络行。各系列之间的差异并非矛盾，而是后台工作本身的性质：当 Windows 正在执行维护时，禁用后台组件节省更多；当窗口已经安静时——更少。
启动后最初几分钟
Section titled “启动后最初几分钟”| 指标 | 系列 1（之前 → 之后） | 系列 2（之前 → 之后） |
|---|---|---|
| CPU 占用，% | 3,42 → 2,59 | 14,62 → 11,88 |
| 上下文切换，/秒 | 1 114 → 600 | 1 257 → 393 |
| 进程数 | 132 → 74 | 139 → 64 |
| 线程数 | — | 1 719 → 746 |
| 已用物理内存，MB | — | 2 821 → 1 581 |
| 可用内存，MB | — | 5 370 → 6 610 |
| 磁盘读取，KB/秒 | — | 826 → 433 |
| 磁盘写入，KB/秒 | 634 → 418 | 709 → 298 |
| 网络（接收），KB/秒 | — | 1,15 → ~0 |
破折号表示该系列中此阶段的该指标未被记录。
空闲时的清单快照（系列 1）：
| 之前 | 之后 | |
|---|---|---|
| 进程数 | 136 | 70 |
| 线程数 | 1 679 | 842 |
| 总 working set，MB | 3 841 | 1 868 |
| 总 private bytes，MB | 1 524 | 660 |
优化前最大的内存消耗者：杀毒进程 MsMpEng.exe（257 MB）、explorer.exe（213 MB）、StartMenuExperienceHost（144 MB）、msedge.exe（133 MB）、SearchHost.exe（122 MB）。优化后列表由 explorer.exe（170 MB）、msedgewebview2（119 MB）、SearchHost.exe（115 MB）和 StartMenuExperienceHost（106 MB）领衔。
可用内存增长了 1,0–1,5 GB，而提交量（commit）减少了 52 %。其中哪些确实可以被「释放」，以及为什么进程 working set 之和并不等同于空闲内存，已在「Windows 中实际可以释放多少内存」中详细分析。
短时合成测试（系列 2，两次重复的中位数）：
| 场景 | 吞吐量变化 | CPU 占用：之前 / 之后 |
|---|---|---|
| 单线程 | +5,4 % | 21,9 / 22,6 % |
| 四线程（满载） | +0,19 % | 88,9 / 89,4 % |
| 八线程（满载） | +0,50 % | 88,9 / 88,8 % |
| 内存负载 | +11,2 % | 84,8 / 87,5 % |
| 节拍式（暂停 1 毫秒） | +5,4 % | 64,3 / 67,7 % |
| 混合优先级 | +8,5 % | 21,2 / 22,5 % |
| 后台优先级 | +77,1 % | 38,8 / 65,2 % |
在完整的四线程负载下，有效进程在优化前后都获得了约 89 % 的四个 vCPU 容量。虚拟机中剩余的约 11 % 不能被称为可消除的「Windows 噪声」：虚拟机管理程序的调度从客户机跟踪中不可见。工作线程分布均匀（它们之间工作量的离散度为 0,994–0,997），未观察到饥饿，而优化后空闲时的 CPU 队列几乎为空。
后台工作去向何处
Section titled “后台工作去向何处”「之前」状态下测量到的后台活动来源：
- 杀毒扫描——系列 2 窗口中的主要来源：进程
MsMpEng.exe在五分钟空闲窗口内消耗了 212 CPU 秒； - 在原始状态下，搜索服务、SysMain 服务、遥测、打印后台处理程序及其他组件都在运行——优化配置文件将约 50 个后台服务和 58 个计划任务转为禁用状态；
- 启动后，活动伴随 Windows 更新协调器。
禁用后台组件并不能完全消除后台工作：在优化状态下，应用兼容性评估仍在运行（在维护窗口中约为每秒 3,7 毫秒 CPU），而稳定空闲中的总残余后台为每秒 4,8 毫秒 CPU——约为四个 vCPU 容量的 0,12 %（根据跟踪测量）。
已确认的内容
Section titled “已确认的内容”- 已复现（两个独立系列）：进程数 −49…−56 %，线程数 −49…−57 %，可用内存 +1,0–1,5 GB。
- 已测量（系列 2）：空闲时 commit −52 %；已用物理内存在空闲时 −49 %，在启动后阶段 −44 %。
- 已测量： 空闲 CPU 占用在安静窗口中 −17 %，在扫描窗口中 −67 %；上下文切换 −19 % 和 −92 %；DPC −78 %（系列 2 窗口）；启动后活动在两个系列中都更低。
- 已测量： 在 CPU 满载下吞吐量提升 +0,19 %（4 线程）和 +0,50 %（8 线程）；在非满载和混合负载下——从 +5,4 到 +11,2 %。
- 已测量： 后台优先级类负载加快了 77,1 %——在「之前」状态下它与 Windows 自身的后台工作（包括杀毒扫描）竞争。
- 已观察到： 主要后台来源是杀毒扫描、维护和兼容性任务；优化后残余后台接近零，但并非为零。
未确认的内容
Section titled “未确认的内容”- 真实游戏中的 FPS 提升、输入延迟或帧时间降低：未测量。合成 CPU 测试不模拟带 GPU 的游戏，也不证明游玩效果。
- 每个单独禁用项的独立贡献：应用的是整套更改。
- 将绝对数值外推到物理硬件、其他版本和其他优化配置文件。
- 长时间窗口上的稳定性：每个阶段为 5 分钟；Windows 的后台工作呈突发式，因此「平均一天」未被测量。
- 测量在虚拟机中完成。虚拟化会引入自身的 DPC/ISR 份额并隐藏主机调度；在物理硬件上绝对值会不同。在相同条件下，「之前/之后」比较的比例和方向保持不变。
- ISR 指标已从表格中排除：在虚拟机中，通过 PDH 的 ISR 计数器与通过 ETW 的中断处理程序相差约 10 %，且无法精确求和。
- 系列 2 的「之前」窗口包含活跃的 Defender 扫描，且各窗口之间的主机负载不同（平均 44 % 对 24 %）。因此数值与具体窗口绑定；方向已由两个系列确认。
- 在系列 1 中，部分空闲阶段被虚拟机外部暂停中断约 26 秒；捕获在恢复后完成，没有丢失事件。
- 负载测试为两次重复：这是描述性统计，未评估统计显著性。
- 空闲中部分收益与禁用 Microsoft Defender 防护组件有关。没有杀毒防护的系统是有意识的妥协，而不是无代价的优化；禁用防护必须理解其代价。
- 测量层（跟踪和计数器）本身会产生少量后台负载；它存在于两种状态中。
研究与所用工具属于 BoosterX 开发者，因此开发者对结果有直接利益。方法和适用范围已在上文描述，结论可通过公开数据和所列公开来源进行验证。
减少后台噪声是真实的、已两次复现的效果：进程和线程数减半，内存提交量减半，空闲时磁盘和网络活动减少一个数量级。这本身就有用——对系统响应性、后台任务、温度、风扇噪声和电池续航而言——并且不需要承诺 FPS。
不应期待的是：满载下的性能提升。如果 CPU 已被有效工作占用约 89 % 的容量，禁用后台活动不会增加剩余的 11 %——在虚拟机中它们不属于 Windows。系统在比较时刻越忙碌，可见效果越大：在维护窗口中差异成倍，在安静窗口中——适中。
建议：在自己的计算机上评估任何更改前后的后台（任务管理器 → 「性能」和「进程」、资源监视器），而不要以他人的百分比为准。如果目标是特定游戏中的 FPS，就测量它本身在更改前后的值。
两个系列都在独立磁盘副本上的隔离虚拟机中执行；测量后机器恢复到原始状态。本文不要求读者更改参数，因此用户计算机上无需单独的恢复操作。
公开一手来源
Section titled “公开一手来源”- Microsoft: Windows Performance Recorder——方法中使用的 ETW 跟踪记录工具；检查于 2026-09-20。
- Microsoft: About Event Tracing——ETW 模型与丢失事件检查；检查于 2026-09-20。
- Microsoft: Windows 中的 Microsoft Defender Antivirus——Defender 的进程和服务，包括
MsMpEng.exe（任务管理器中的「Antimalware Service Executable」）；检查于 2026-09-20。 - 我们如何研究 Windows——证据等级与测量协议。
- Service Host 与 Windows 11 后台组件——Windows 如何按进程托管后台服务。
- Windows 中实际可以释放多少内存——同一实验的内存详细分析。
- 桌面与登录屏幕——续篇：用户会话噪声由什么构成。
- 2026-09-20： 首次发布——两个独立的空闲测量系列、启动后阶段、清单和负载测试。
- 2026-09-20： 明确了各系列结果的归属（commit 和已用物理内存——仅系列 2；进程 −49…−56 %）；利益冲突免责声明已改为规范表述。