移动 GPU 基准测试：手机 FPS 与散热指南

手机和平板有严格的功耗和散热限制。设备可以在 WebGL benchmark 开始时以较高 boost clock 运行，然后随着热量累积下降到较低水平。

移动浏览器行为也会变化。Safari、Android Chrome、Samsung Internet 和其他浏览器可能暴露不同 WebGL 路径和 timing 行为。因此手机 benchmark 是设备加浏览器的结果。

屏幕尺寸和像素密度同样重要。浏览器在较高 device pixel ratio 下运行时，实际推动的像素可能远多于肉眼看到的小 canvas。

移动结果还依赖用户不一定能看到的系统策略。低电量模式、自适应刷新率、后台同步、热保护、充电发热和厂商浏览器优化，都可能在页面不变时改变同一 WebGL 工作负载。

从较低复杂度开始，避免在手机已经发热时运行长测试，并把设备放在有空气流通的稳定表面。

不要用一次短跑评价手机。记录早期 FPS，也记录设备升温后的持续 FPS。如果浏览器关闭变慢或屏幕明显变暗，应停止运行。

为了可复现比较，保持方向、亮度、电池模式、浏览器和测试时长一致。

安全的移动流程是先短后长。先做快速检查确认 WebGL 可用，等设备回到正常温度，再做固定 60 秒或 3 分钟测试获取稳定性数据。

不要把 iPhone Safari、Android Chrome、Samsung Internet 和桌面 Chrome 混进一个未标注的排名。每条路径都可能使用不同浏览器引擎、GPU 后端、计时行为和屏幕缩放。

先在受控池内比较：同一手机型号比较两个浏览器、同一浏览器比较两台 Android 手机，或同一 iPhone 在系统更新前后比较。这类比较比混合排行榜能回答更清楚的问题。

发布手机结果时，包含操作系统版本、浏览器名称、方向、显示亮度、充电状态，以及测试是在冷设备还是热设备上运行。这样 casual score 才能变成可复现的移动 GPU benchmark 备注。

原生手机 benchmark 可以暴露更深入的遥测，但不一定回答网页性能问题。浏览器 WebGL 测试展示真实网页应用能使用的图形路径，包括浏览器调度、shader precision 和 context 稳定性。

这对 WebGL 游戏、shader demo、3D 产品页、creative coding sketch 和 GPU-heavy 浏览器体验很重要。原生套件分数很高的手机，如果网页图形路径受限，仍可能出现不稳定 frame time。

最好的移动评测同时使用两种视角：浏览器 benchmark 用于真实网页路径，原生诊断用于需要温度、clocks 或硬件故障排查的场景。

报告手机型号、浏览器、操作系统版本、电源状态、运行时长、平均 FPS、低 FPS，以及是否出现可见热漂移。

比较 Android 和 iPhone 结果时，在方法学足以控制浏览器和渲染差异之前，应分开结果池。

当设备变暗、烫手、触控响应下降或丢失 WebGL context 时，加入停止备注。移动端的失败模式往往比强行延长测试更有价值。