我們如何研究 Windows
本頁內容
在「Windows 研究」專區中，我們檢驗具體的技術主張。每篇文章都會說明我們檢驗了什麼、在什麼條件下檢驗，以及結果適用於哪些系統。
參數的存在、它對系統運作的影響，以及效能提升，都需要個別的證據。
什麼算是證據
Section titled “ 什麼算是證據”我們使用幾種彼此獨立的證據類型：
- 第一手文件。 Microsoft 的官方文件、規格，以及硬體或應用程式製造商的說明文件。
- 靜態觀察。 特定版本元件中的實作跡象。這類觀察僅限於所研究的組建，本身並不能證明該路徑在執行時會被執行。
- 動態觀察。 在所描述的情境中取得的系統事件、元件狀態與追蹤記錄。
- 受控量測。 在已知變更且已驗證狀態還原的情況下，比較事先選定的指標。
- 重現。 在獨立的執行、另一台系統或組建上重複得到結果。
內部的收集與處理自動化方式不予公開。這不改變揭露受檢問題、組態、指標、執行次數與限制的要求。
| 狀態 | 意義 |
|---|---|
| 已記錄 | 行為已於第一手公開來源中描述。 |
| 已觀察 | 事件或狀態已在指定環境中發現。 |
| 已量測 | 已依所述方法取得數值差異。 |
| 已重現 | 結果已獨立重複。 |
| 未重現 | 在指定條件下未發現所宣稱的效果。 |
| 資料不足 | 方法或樣本不足以得出結論。 |
狀態是針對個別主張，而不是自動適用於整篇文章。我們不使用任意的信心百分比，也不會在未於其他系統上檢驗的情況下，將結果稱為普遍已證實。
實驗如何建構
Section titled “ 實驗如何建構”量測之前會先固定：
- 一個受檢問題；
- 自變數；
- 主要指標及其單位；
- Windows build、重要硬體、驅動程式與應用程式版本；
- 具實際意義的門檻；
- 還原初始狀態的方式。
我們比較初始狀態與變更後的狀態，然後檢查是否還原。情況允許時，我們會交替成對執行的順序。我們控制預熱、供電、溫度與背景負載；若無法控制，則會指出該限制。
同一條追蹤中的個別區間顯示的是隨時間的變化，但不被視為獨立的重複。虛擬機器的結果不能自動套用到實體電腦。若要對同一類別的所有裝置下結論，只檢驗一台裝置並不足夠。
物理 click-to-photon 測試平台
Section titled “ 物理 click-to-photon 測試平台”針對遊戲研究，我們使用自有的硬體測試平台。它實際量測從滑鼠按鍵的電氣訊號到螢幕像素亮度變化之間的完整延遲，不以此區間的軟體估算代替。
主要訊號路徑的構造如下：
- 導線焊接在第一代 Logitech G PRO X SUPERLIGHT 左鍵的線路上。電氣訊號前沿會啟動 Arduino Uno 計時器。
- 同一次點擊會經過滑鼠控制器、USB、Windows、遊戲、渲染佇列、GPU 與螢幕。
- 固定在螢幕上的光感測器會在測試區域的亮度跨越事先選定的門檻時停止計時器。
- 單一結果包含以毫秒為單位的完整 click-to-photon 區間。
這樣的起始點刻意包含滑鼠控制器的處理及其 click debounce，但不包含按鍵在接點閉合前的機械行程。我們不會從最終數值中扣除滑鼠延遲。在現行的獨立量測方法中，RTINGS 對 G PRO X SUPERLIGHT 標示有線為 2.5 ms、透過 receiver 為 3.1 ms。量測到的低 click latency 使這款滑鼠成為測試平台上穩定可用的一部分，但不會讓結果變成純粹的 Windows 或遊戲延遲。
另一款 Arduino Nano 格式的 HID 微控制器可以自動將點擊傳送到 Windows。當需要消除手動按壓的差異，並以受控的節奏重複輸入訊號時，會使用這條路徑。它回答的是另一個問題，不會與從滑鼠按鍵實體線路開始的系列混在一起。
在 CS2 中使用 workshop 地圖 BXLAT，其中點擊會引起測試區域可預期的變化。Valorant 中也採用類似的視覺情境。光感測器的位置、解析度、螢幕頻率、FPS 上限、display scaling 模式、presentation mode 與光線門檻，在整個受比較的系列中都會固定。
現行標準要求每個狀態至少 300 次有效點擊。在新的系列中，我們會保留平均值、標準差、最小值、最大值、百分位數（包括 P90），以及用於繪製圖表的分布。錯誤觸發、逾時，以及超出事先設定範圍的數值，我們會標記並在檢查系列適用性時納入考量。
在此測試平台上進行的研究已持續數年，而儲存格式在這段期間有所變動。公開的歷史量測表 中有 300 次點擊的系列，也有較早期 100 次的系列。部分舊測試只保留了 AVG、STDDEV、MIN 與 MAX；缺少的 P90 或圖表無法從彙總資料還原，並會直接標示為不可取得。新的系列將以更完整的統計資料發布。
結果中會公開什麼
Section titled “ 結果中會公開什麼”文章包含：
- 簡短回答；
- 受檢主張；
- 研究範圍；
- 方法與獨立追蹤的數量；
- 指標數值與離散程度；
- 已證實與未證實的結論；
- 已排除或受汙染的指標；
- 限制；
- 不保證結果相同的實務建議；
- 狀態已還原的確認；
- 第一手公開來源與檢驗日期。
如果結果未能證實某項熱門建議或 BoosterX 的某項功能，它仍然可以被公開。產品中存在某項設定，並不構成其有效性的證據。
如何自行檢驗
Section titled “如何自行檢驗”我們研究中相當一部分的動態觀察，可用公開工具重現：Sysinternals ProcMon 用於系統追蹤，以及 WinDbg 搭配 Microsoft 公開符號。基本的檢驗路徑如下。
- 讀取參數 — ProcMon。 開啟 Options → Configure Symbols，並指定 Microsoft 公開符號伺服器，讓堆疊顯示模組與函式的名稱。接著新增 Path contains 篩選條件——例如來自
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile的SystemResponsiveness。從讀取事件可以看出該值是否被讀取、何時被讀取，以及由哪個處理程序讀取。 - 誰在讀取 — 呼叫堆疊。 雙擊事件會開啟其屬性；Stack 索引標籤顯示模組鏈——這就是參數的「讀取者」。例如從
user32.dll到win32kfull.sys的鏈，表示該值由 Win32k 子系統負責。 - 執行時的行為 — WinDbg。 搭配 Microsoft 公開符號，可以在堆疊中的函式上設定中斷點，觀察讀取到的值如何被套用。
- 合成測試。 變更數值並量測觀察到的行為。例如滑鼠輸入間隔可用公開的輪詢率測試工具量測。
誠實的界線。 文章中不公開二進位檔的靜態分析與完整追蹤。上述路徑重現了我們觀察中的動態部分，但不能取代靜態分析——其結論僅適用於所研究的組建。
延遲量測的界線
Section titled “ 延遲量測的界線”軟體延遲、佇列深度、音訊引擎週期、執行緒排程時間與完整物理延遲描述的是不同的量。例如 XAudio2 佇列並不決定從使用者動作到喇叭發出聲音的整個區間。要量測它需要外部設備。
同樣地，單一處理程序的 CPU 時間不等於對 FPS、frametime、能耗或系統回應性的整體影響。這類結論需以個別指標檢驗。
原始 ETL、PML、事件記錄、記憶體傾印與登錄檔匯出預設不公開。系統追蹤可能包含使用者名稱、路徑、命令列、網路位址與其他敏感資料。Microsoft 在 Sysinternals 條款 中特別對此提出警告。
網站上只會放置經人工挑選並去識別化的表格。我們會移除裝置與安裝的唯一識別碼、使用者路徑、帳戶資料、網路識別碼、登入資料，以及與研究無關的處理程序相關資訊。
Windows、驅動程式與應用程式都會改變。每篇文章都會標註最後檢驗日期與適用範圍。如果新的量測與舊結論相牴觸，文章會更新並說明原因。舊結果不會自動套用到新的組建。
獨立性與商標
Section titled “ 獨立性與商標”研究由 BoosterX 團隊發布，且可能涉及產品功能。這項可能的利益衝突，透過將方法、量測數值、限制與負面結果與產品建議分開來處理。
BoosterX Wiki 是獨立出版物，與 Microsoft Corporation 無關，未經其授權、贊助或認可。Microsoft 與 Windows 名稱僅用於精確描述研究對象。詳情請見：Microsoft Trademark and Brand Guidelines。
- 2026-08-24： 方法已發布。
- 2026-09-20： 新增「如何自行檢驗」章節；修正滑鼠資料來源的連結。
方法最後檢驗日期：2026-09-20。