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 帧的预算。因此，高刷新率硬件在相同条件下接受测量，不会因为能够显示更多帧而受罚。

搜索过程

每个场景都会依次经过状态机：预检 → 基线 → 预热 → 爬升 → 夹逼 → 确认 → 锚点。

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）只运行经典场景，并在自身体系内计分，页面会明确标记。
• 性能下降的测试会一直携带这个标记，包括上传到匿名数据集后，以便公开中位数排除这些样本。

连续测试会波动多少

设备接通电源并处于空闲状态时，连续测试通常只相差几个百分点——确认阶段要求连续通过多个窗口，正是为了换来这种稳定性。使用电池、开启省电模式或机身已经发热时，波动会更大，也可能出现性能下降标记。这不是基准测试“闹情绪”，而是设备当时确实只能提供更少性能。拿到数字后该怎样使用，可以继续阅读浏览器基准测试的诚实说明。