android-benchmark-comparison

Android 基准测试比较

核心原则

将实体 Android 配置比较视为一项可复现的实验： 在解读排名或选择默认配置之前，先确认工作负载和设备条件具有可比性。

流程

1. 说明决策、配置、工作负载、指标定义和重复次数。保留精确的构建身份、配置、原始结果和跟踪数据；随后确认每个预期用例和迭代都已运行。区分缺失、失败和排除的运行；不要只比较表现最快的运行。
2. 控制并记录相关设备条件，包括设备型号和状态、温度与电源模式、显示亮度、后台负载，以及网络或输入条件。将设备专用命令和 CPU 掩码保存在项目的运行手册中。
3. 平衡或反转运行顺序，并重复比较。报告离散程度以及排序是否保持不变；不要在看到结果后丢弃较慢的迭代。
4. 当排名反转或波动幅度较大时，在解决反转问题之前，不要贸然确定默认配置。给出完整的后续比较步骤，而不只是最先遇到的阻碍：确认相同的具名用例和迭代，采用平衡或反转的运行顺序重复测试，并检查时间戳与每个测量区间重叠的跟踪数据，以确认 CPU 放置、争用或温度变化。固定性能模式并不能证明 CPU 放置情况。如果尝试了亲和性实验，应先查明设备拓扑，并在测量区间内验证 CPU 放置情况。实验结束后恢复记录的原始亲和性设置，并在再次运行前确认已恢复；不要只备注需要检查是否恢复。将已验证 CPU 亲和性的运行标记为受控比较。如果无法获取原始设置或完成其他任一检查，应说明这一缺口，并明确将任何默认选择标记为暂定。
5. 根据未舍入的观测值计算汇总数据，然后仅在展示时舍入。明确说明采用的汇总方式：各次运行的百分位数均值，不等于合并观测值后的百分位数。选择能回答既定决策问题的汇总方式；不要一概推荐某个统计量。
6. 将受控实验的证据与普通用户的性能表现分开。如果多个条件同时发生变化，应说明比较的控制程度更高，但不要把整体差异归因于某一个控制因素。使用 CPU 帧时长证据来辅助视觉质量与性能决策，但不要声称它测量的是 GPU 着色器时间。
7. 最后说明原始证据的位置、已完成用例数量、波动情况、跟踪数据的发现、控制措施和恢复状态，以及有明确范围的决策或剩余的不确定性。若排名反转尚未解决，应说明仍需完成的完整步骤：确保覆盖的用例一致，采用平衡或反转的运行顺序，检查测量区间内的跟踪数据，并恢复所有更改过的亲和性设置。如果提到固定性能模式或亲和性命令，应说明二者都不能在未经跟踪数据验证的情况下证明 CPU 放置情况。在建议中明确写出运行顺序："平衡比较"本身并未告知团队要平衡或反转运行顺序。将此前任何默认选择标记为暂定。

限制

• 一次稳定的基准测试运行可以支持范围有限的观察，但不足以得出可靠的配置排名。
• 不要将设备专用的 CPU 掩码、亮度值、迭代次数或汇总统计量变成永久默认值。
• 如果跟踪数据或重复测试覆盖率无法解决排名反转问题，应保持默认配置不变，或作出明确说明该限制的暂定决策。