为什么测这两样：现代游戏在 CPU 受限场景里，时间不是花在“多核算力”上，而是花在 单核的依赖链（引擎逻辑、物理、脚本、draw call 提交）和 内存/缓存的随机访问延迟 （实体、组件、句柄的指针遍历 —— 只要工作集溢出缓存，每次访问就要等一次内存往返）上。 1% low 和最大帧之所以难看，几乎都是后者的功劳。所以本基准只压这两条路径，多核跑分不进分数。
一标准帧 = 四段固定工作量（常量跨设备完全一致，改了就换代、新旧分数不可比）：
池子用 pool[i] = (A·i + B) mod 2^k 构造：这是模 2^k 的单周期置换，指针追逐会走满整块内存才重复，
所以每次访问都是新缓存行、真实测到内存往返延迟。若把池子填成“随机索引”，随机映射的环长只有 O(√n)，
指针几万步内就会被困在几百 KB 的小环里，量出来的是缓存命中而不是内存延迟（本页实测踩过这个坑，已修正）。
计时方式：定工作量 —— 单帧工作量在所有设备上完全相同，累计实测 30 秒（墙钟 75 秒兜底）， 每约 12 ms 记一个样本（采样窗口远大于计时器量化误差），出 P50 / P99 / P99.5 帧时。
预热与丢弃：正式计时前先空跑 1.8 秒热身（不计分），把刚开跑时缓存未热、频率未升、触屏操作造成的虚高延迟摊掉； 热身之后再丢掉第一块（约 1 秒）的数据。所以实际计分的样本不留开跑期的尾巴 —— 手机尤其需要这一步。
档案微测取最好值：延迟/吞吐这类指标，任何干扰只会让它变慢、不会变快，所以每项测 3 轮取最好的一轮 （这也是内存延迟测量的通行做法）。页面上同时给出轮间离散度，用来判断这次跑的设备环境干不干净。
计分：分数 = 1000 / (0.55×P50 + 0.30×P99 + 0.15×P99.5)，单位 fps。
中位帧时占 55%，两个"烂帧"指标占 45% —— 快但不稳的机器拿不到高分，这就是低帧权重。
第三项用 P99.5 而不是 P99.9：30 秒约 2500 个样本时 P99.9 只由 2 个样本决定，本身抖动就有 ±10%，换成 P99.5（约 12 个样本）稳得多。
帧时超过 5×P50 的样本视为系统中断（其他程序抢 CPU / 切标签页），统计时剔除但计数展示。
可比性条件：同一版本（页面左上角 vN）、非 SAFE 自检模式、非降级运行。 分数依赖单线程 + 内存表现，后台程序、电源模式（节能/全速）、内存 XMP/EXPO 是否开启都会明显影响结果； 跑分前关掉占 CPU 的程序、插电、开高性能电源模式。同一台机器重复跑，分数波动通常 <3%。
自证：结果里有一行“模型自证” —— 用档案微测（单核吞吐 / 各级延迟 / 带宽）反推的预测帧时，
与实测 P50 对比，比值贴近 1 说明测量链路自洽；偏差大说明后台干扰或降频。全部原始数据在 window.__bench，
「⧉ 复制 JSON」可直接取。