ScreenTest.Pro 分數是如何計算的

這是方法說明頁。這裡沒有為了宣傳而簡化的內容；如果程式碼和本頁說法不一致，那就是一個瑕疵，歡迎告訴我們。（撰寫時的基準測試版本：2.5.0。）

基準測試提出的問題

多數圖形基準會固定工作負載，再測量影格率。我們的做法剛好相反：固定影格時間目標，然後尋找裝置能夠穩定維持的最重工作負載。每個場景的輸出是「最大穩定負載」，例如 840,000 個星雲粒子，最終分數就以這些結果為基礎。

為什麼要反過來測？因為影格率會撞上上限。固定工作負載在高效能裝置上很快就會達到螢幕更新率，此後數字不再提供任何資訊；真正有意思的問題是它原本還能多處理多少。尋找效能上限，讓同一組場景從五年前的手機到桌上型 GPU 都能產生有意義的結果。

實際執行的內容

標準設定包括五個招牌場景和一個對照場景，分別施加不同類型的壓力：

渲染的像素比最高限制為 1.5×，內部尺寸也有上限，因此 5K 顯示器和 1080p 筆電面對的像素數量大致可比。亂數使用固定種子，模擬步長也保持不變，所以同一版本的每次執行都會完成相同工作。

穩定性如何判定

引擎從不去讀 FPS 計數器。它從瀏覽器的動畫時鐘把影格時間收集進大約 0.7–1.6 秒的視窗，然後對每個視窗提出兩項要求：

• 超過通過門檻的影格不得多於 5%——可變更新率螢幕為 17.5 毫秒；固定更新率螢幕則取預算之內的工作永遠無法落上的第一個垂直同步時段（60 Hz 為 25.0 毫秒，120 Hz 為 20.8 毫秒）；
• 截尾平均——丟掉最差的 2% 影格——必須守在 17.5 毫秒之內，這是每一類螢幕共用的同一個持續預算。

統計「超標影格數」而不是把它們平均掉，會讓一次垃圾回收停頓只算作一格壞影格，而不是一個失敗的視窗；截尾平均則是持續輸送量的界線，而且從 2.3.0 起，它在所有地方都是同一個數字——真實的垂直同步時間戳記比 2.2.0 假設的固定更新率模型更亂，而舊的、較寬鬆的截尾容差，一直悄悄給固定更新率螢幕一個比可變更新率螢幕寬鬆約 9% 的預算。

為什麼超標門檻仍然要顧及你的螢幕：固定的 60 Hz 螢幕只能在 16.7 毫秒或 33.3 毫秒呈現一格畫面，中間沒有第三種可能，而可變更新率的筆電螢幕會把 18 毫秒的一格原樣交還為 18 毫秒。因此在第一個場景之前，一次約 600 毫秒的節奏探測會觀察你的螢幕如何交還畫面，掉格門檻隨之調整，讓「穩住 60 fps」在每一類螢幕上都是同一句話。接著，同一次探測還會花約 2 秒檢查機器本身在零負載下是否已經卡頓——忙碌的機器會在三分鐘的測試之前就收到警告，而不是測完才意外拿到一個下限。如果探測發現螢幕被限制在約 50 Hz 以下——低耗電模式、一條 30 Hz 的線材——這次測試會拒絕開始，而不是隔著一根 30 Hz 的吸管替 GPU 打分。

16.67 毫秒的預算本身不隨更新率變動。120 Hz 的螢幕在輕鬆時每 8.3 毫秒送出一格，但通過只要求守在「每秒 60 格」的預算之內——高更新率硬體被平等地量測，不會因為多顯示了幾格而被懲罰。

搜尋過程

每個場景都走一台狀態機：preflight → baseline → warmup → ramp → bracket → confirm → anchor。

1. Baseline 量測一個已知的輕負載——它成為熱基準。
2. Ramp 每通過一個視窗就把負載乘以約 1.5×，直到某個視窗失敗。
3. Bracket 在最後一次通過與第一次失敗之間二分搜尋，直到區間收窄到約 6%。
4. Confirm 要求候選負載上出現連續三個通過的視窗，總預算為四個。開頭的一個壞視窗還能挽回；連續兩次失敗，或者用完預算仍湊不出連續三次，就否決這一階，候選負載下調一級。
5. Anchor 重跑基準負載。如果它現在比開始時慢了 15% 以上，代表裝置在我們腳下變了——幾乎總是熱降頻——這個場景會被標記為漂移，而不是假裝什麼都沒發生。變慢的幅度也會被記錄下來，而不只是記下這件事發生過。

每次負載變動之後的幾格畫面會在統計恢復之前被丟棄：改變負載會重新配置 GPU 緩衝區和算圖目標，瀏覽器把這筆帳記成一格超長畫面。那次卡頓屬於過渡，不屬於工作負載——2.1.0 把它算了進去，而在那個每一階都要重設算圖目標尺寸的場景裡，它讓搜尋遠遠停在硬體真實能力之下。

每個階段都有硬性時限（每場景 30 秒，每次測試 200 秒，只有在確實排入重試時才會短暫延長）。量測前的暖機也會自適應：首次造訪時要編譯著色器，預檢階段會在影格時間仍顯示編譯卡頓時繼續等待——最多 4 秒——讓負載階梯從一台已經暖機的機器開始，而不是淹沒在卡頓裡。把分頁切到背景會暫停量測並作廢當前視窗；調整視窗大小會重建場景並重新暖機。另外，如果某個場景什麼都沒量到，而同一次測試裡後面的場景已經恢復正常，它會在最後恰好追加一次量測——前提是一次新的靜默檢查顯示機器已經安定下來。沒有任何數據是捏造的；場景只是重新跑一遍，重試的結果會取代那個空結果。狀態機裡沒有任何一條路徑會卡死。

從負載換算為分數

計分是對已記錄結果的純函式——你完全可以手算一遍：

1. 每個場景的最大穩定負載除以該場景的參考負載（每個版本凍結的校準常數；粗略地說，一台 2025 年的可靠桌機大約落在 1.0）。
2. 比值下限為 0.05，上限則取該場景自己的梯子天花板——這個場景在物理上能擺出的最重負載，大約設在我們測過最快硬體的 10 倍之外——這樣分數只能在量測本身結束的地方停止上升。（2.1.0 把每個場景都卡在統一的 20×；一台 M4 Max 有兩個場景頂住這個上限、第三個頂住量測上限，這正是彼此無關的蘋果旗艦不斷報出幾乎相同總分的原因。）
3. 經過限制的比值匯入一個加權幾何平均——五個 Signature 場景承擔大部分權重，Canvas 2D 對照占 10%。取幾何平均是因為它獎勵均衡：樣樣都好的機器勝過一項傳奇、另一項糟糕的機器。
4. 乘以 1000，套用穩定性扣分——每個被標記的場景扣 3%，無論標記是漂移還是未確認的階位，總扣分最多 10%——然後取整。

等級是每個版本的固定門檻，而由於分數是參考機器的 1000 倍，每個等級其實都是它的倍數：入門低於 1000，均衡到 2999，快速到 8999，極致在其之上——也就是不足 1×、至多 3×、至多 9×，再往上就是超出。它們的存在只是給數字一個把手；各場景的分項才是真正的資訊。

哪些情況會讓比較失效

• 不同基準測試版本之間絕不比較。 改動一個著色器就改變了工作負載；結果單上的版本號是分數的一部分。
• 相容模式測試（沒有 WebGL2）只使用 Classic 場景，並在自己的計分空間裡計分，且有明確標註。
• 降頻的測試——每個場景都量到了，但裝置變熱變慢，或者守住了一個能通過、卻沒能連續三個視窗獲得確認的階位——是關於持續效能的真實量測，因此正常計分，並帶著列內可見的標記進入最高分排行榜。絕大多數手機測試都落在這裡；那是物理定律，不是故障。
• 降級的測試——某個場景沒有產出可用結果——是下限而非高峰，所以不進榜，也不計入公開的中位數。它們仍會被保留，結果單也會說明是哪個場景、為什麼。
• 兩種標記都會隨著這次測試進入我們的匿名資料集，因此任何公開數字都能把它們區分開。

連續測試會波動多少

在接著電源、處於閒置的機器上，連續幾次測試通常相差幾個百分點——確認階段對連續視窗的要求正是這份穩定的來源。用電池、開省電模式或機身發熱時，請預期更大的離散，而且很可能帶上降頻標記；那不是基準測試在鬧脾氣，而是你的裝置此刻確實只能給出這麼多。測試前讓它涼下來並接上電源，是取得有代表性數字最有效的一件事。瀏覽器基準測試能測到什麼、測不到什麼講的是拿到這個數字之後該怎麼用它。