ScreenTest.Pro 分數是如何計算的

這是一頁完整的方法說明，不會為了行銷而簡化。如果程式碼與本文任何一處不一致，那就是程式錯誤，也歡迎告訴我們。（撰寫本文時的基準版本：2.0.0。）

基準測試提出的問題

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

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

實際執行的內容

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

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

穩定性如何判定

引擎從不讀取 FPS 計數器，而是從瀏覽器動畫時鐘收集影格時間，劃分為約 1.6 秒的視窗，再對每個視窗檢查兩項條件：

• 平均影格時間 ≤ 16.67 毫秒 × 1.08
• 影格時間第 95 百分位數 ≤ 16.67 毫秒 × 1.28

p95 是更嚴格也更關鍵的一關：裝置若快速渲染 100 個影格，卻有 6 個影格出現嚴重延遲，體感仍然會卡頓；百分位數不會允許準時影格靠數量把延遲影格的問題投票抹掉。

無論螢幕更新率是多少，16.67 毫秒預算始終固定。120Hz 螢幕在輕負載下以 8.3 毫秒節奏輸出畫面，但通過測試只需要守住 60 FPS 的預算。因此，高更新率硬體在相同條件下接受測量，不會因為能夠顯示更多畫面而受罰。

搜尋過程

每個場景都會依序經過狀態機：預檢 → 基準 → 預熱 → 爬升 → 夾逼 → 確認 → 錨點。

1. 基準測量一個已知的輕負載，並把結果當作之後判斷溫度降速的參考。
2. 爬升在每個通過的視窗後把負載提高約 1.6 倍，直到出現失敗。
3. 夾逼在最後一次通過和第一次失敗之間進行二分搜尋，直到範圍縮小到約 15%。
4. 確認要求候選負載連續通過三個視窗。一次壞視窗可以重試（通知彈窗或垃圾回收暫停不該直接讓這一級失敗）；連續失敗兩次才會否決，並退到更低的候選值。
5. 錨點再次執行基準負載。如果此時比開始時慢 15% 以上，代表裝置狀態在測試過程中發生了變化——幾乎總是熱降頻——該場景會被標記為效能下降，而不是假裝一切正常。

每個階段都有嚴格時限（每場景 30 秒、整次測試 150 秒）。把分頁切到背景會暫停測量並作廢目前視窗；調整視窗大小會重建場景並重新預熱。狀態機不存在無限掛起的路徑。

從負載換算為分數

計分是記錄結果上的純函式，你甚至可以手動重算：

1. 將每個場景的最大穩定負載除以該場景的參考負載（每個版本凍結不變的校正常數；粗略來說，一台效能扎實的 2025 年桌上型電腦會落在 1.0 附近）。
2. 把比值限制在 [0.05, 20] 區間，避免單一場景獨占整個結果或把結果歸零。
3. 使用加權幾何平均數合併這些比值——五個招牌場景占主要權重，Canvas 2D 對照場景占 10%。之所以使用幾何平均，是為了獎勵均衡：各方面都優秀的裝置，應勝過只在一項無敵、其餘項目很差的裝置。
4. 結果乘以 1000，再扣除穩定性懲罰——每個因溫度而下降的場景扣 3%，總扣分最高 10%——最後四捨五入。

每個版本的等級門檻固定：600 以下為入門，600–1499 為均衡，1500–2999 為快速，3000 及以上為極限。等級只是讓數字更容易理解；各場景子分數才是真正的資訊。

哪些情況會讓比較失效

• 不同基準版本永遠不能互比。 哪怕只改一個著色器，工作負載也會改變；結果頁上的版本號是分數的一部分。
• 相容模式測試（沒有 WebGL2）只執行經典場景，並在自己的體系內計分，頁面會明確標記。
• 效能下降的測試會一直攜帶這個標記，包括上傳到匿名資料集後，以便公開中位數排除這些樣本。

連續測試會波動多少

裝置接上電源並處於閒置狀態時，連續測試通常只相差幾個百分點——確認階段要求連續通過多個視窗，正是為了換來這種穩定性。使用電池、開啟省電模式或機身已經發熱時，波動會更大，也可能出現效能下降標記。這不是基準測試「鬧情緒」，而是裝置當時確實只能提供較少效能。拿到數字後該如何使用，可以繼續閱讀瀏覽器基準測試的誠實說明。