Garmin 跑分白皮书
WristBench 跑分原理与评分白皮书
WristBench 用于评估 Garmin 智能手表在真实 Connect IQ 环境下的整数计算、虚拟机内存管理、设备存储 I/O 和 2D 绘图吞吐能力。 它刻意放弃传统的浮点数算 Pi 测试，因为许多手表芯片和虚拟机对浮点路径的优化差异很大，无法稳定反映日常应用里的真实压力。
1. 测试目标
当前程序的目标不是得到一个抽象的芯片理论峰值，而是测量“Garmin 应用实际能用到的性能”。所有 CPU、内存、I/O 和绘图测试都运行在 Monkey C 与 Connect IQ 运行时之上，并使用 System.getTimer() 记录完整阶段耗时或吞吐量。
为避免 Connect IQ watchdog 误杀，计算密集阶段采用分片执行：每一小片完成有限工作后把控制权还给系统，界面也会刷新当前进度。但计时器从阶段开始一直累计到阶段结束，因此分片不会让结果变快。
2. 四个测试模块
逻辑与位运算测试
创建 1000 个确定性伪随机整数，执行 256 轮高强度 bitmask、bitshift、xor、or 和累加混合操作，最后对数组执行 QuickSort。该阶段主要压测 Monkey C VM 的整数运算、数组访问、循环调度和递归排序开销。
记录值：完成整个逻辑阶段的毫秒数。耗时越低，得分越高。
内存与 GC 测试
先动态构建长字符串，再执行 2400 次 substring 切片与拼接控制，随后创建 5000 个 Dictionary 对象，写入 index/value/slice 后立即释放引用。该阶段用于放大对象分配、短生命周期对象回收、字符串复制和 GC 压力。
记录值：完成字符串、切片和 Dictionary 压力循环的总毫秒数。
存储 I/O 测试
通过 Application.Storage 准备 500 个 key，清理旧值，连续写入 500 个小型整数值，再逐个读取校验，最后删除清理。该阶段反映 Connect IQ 应用可见的本地持久化接口成本，而不是裸闪存理论速度。
记录值：准备、写入、读取与删除全过程的毫秒数。
图形渲染测试
在 5 秒窗口内持续 requestUpdate，以每帧 500 个绘图操作压测 Graphics.Dc：包含 fillCircle、多边形和文本。该阶段测的是屏幕刷新链路、绘图 API、抗锯齿支持和设备分辨率综合影响。
记录值：5 秒内成功完成的总帧数。帧数越高，得分越高。
3. 分数计算原则
WristBench 使用固定基准设备指标作为 1000 分参考点。耗时类项目使用“基准耗时 / 实际耗时”，吞吐类项目使用“实际帧数 / 基准帧数”。这让高性能设备可以超过 1000 分，低性能设备则低于 1000 分。
Score = (Base_Time / Actual_Time) * 1000Score = (Actual_Frames / Base_Frames) * 1000当前基准常量如下：
- BASE_TIME_LOGIC = 2000 ms
- BASE_TIME_MEM = 3500 ms
- BASE_TIME_IO = 1500 ms
- BASE_FRAMES_UI = 60 帧
Final = Logic * 0.25 + Memory * 0.35 + UI * 0.30 + I/O * 0.104. 为什么这样加权
内存与 GC 权重最高，因为 Garmin 小程序的真实体验常常受字符串处理、对象生命周期和 VM GC 影响。UI 权重排第二，用于体现 AMOLED/MIP 分辨率、绘图栈和帧循环压力。 逻辑计算反映 VM 整数执行能力，存储 I/O 权重较低，因为它对用户体验重要，但通常不是每帧都会触发的热路径。
5. 排行榜与去重
手表端上传原始指标：logicMs、memoryMs、ioMs 和 uiFrames。服务端不会盲信客户端上传的分数，而是按同一套公式重新计算单项分和总分。 排行榜按 Garmin 机型聚合，同一机型下多台不同设备取平均值；展开详情仍可查看单台设备的原始指标和计算后分数，但不会公开用于服务端去重的设备标识符。
6. 阅读结果时的注意事项
跑分结果会受到固件版本、Connect IQ 版本、电量策略、屏幕类型、屏幕分辨率和设备温度影响。跨设备比较时，应优先比较同一 App 版本与相近固件状态下的数据。 对单台设备而言，建议连续运行多次后查看稳定区间，而不是只看一次峰值。