如何在JS绘制过程中测量图形元素的绘制性能

计时精度修正 #

首先替换原有低精度计时接口：

• 彻底放弃new Date().getTime()/Date.now()这类仅返回整数毫秒的墙钟时间API，全量替换为performance.now()。该接口返回浮点数精度的相对时间戳，实际运行精度可达微秒级，足够捕捉单帧内各小段绘制逻辑的耗时差异，从根源解决之前累计统计时，快速绘制段的耗时因为精度不足被平均抹平的问题。

低开销批量统计实现 #

你最初想到的“累计缓存、固定周期输出”的思路是完全正确的，可以针对requestAnimationFrame的运行节奏做适配优化，进一步降低统计本身的性能损耗：

• 在类的作用域内初始化统计缓存对象，按每个绘制段的标识存储累计耗时、累计样本数。每次在drawAll的标记位置直接读取performance.now()的值，计算相邻两个时间点的耗时差，累加到对应段的缓存值上，每跑完一帧就给帧计数器加1。
• 优先用帧计数作为输出触发阈值，不要用墙钟时间做判断：比如累计满120帧（约2秒@60Hz刷新率）就自动输出一次统计结果，输出完成后立刻清零缓存值和帧计数器。这种方式不需要额外启动独立定时器，也不会因为页面帧率波动出现统计周期错位的问题。

避坑要点 #

• 绝对禁止在单帧绘制循环内直接执行控制台输出、DOM更新操作。之前实时输出导致控制台冻结的核心原因是，控制台的对象序列化、渲染操作是和JS主线程同步执行的，高频调用的开销甚至会超过游戏逻辑本身的运行成本。
• 输出统计值时做简单的归一化计算：用累计耗时除以样本数得到段平均耗时，可额外附带记录段内的耗时最大值、最小值，避免单帧的极端卡顿样本干扰判断，也能更精准定位长期拖慢帧率的绘制段。
• 尽量降低测量逻辑的侵入性：不要把时间戳读取逻辑封装成多层嵌套的工具函数，直接在drawAll的作用域内读取performance.now()即可，避免函数调用的额外开销引入计时误差。

关联排查提示：完成耗时统计后，如果发现单帧总耗时超过16.7ms（60fps的单帧运行预算），可以优先排查占耗比例最高的绘制段——这类高耗时段往往是引发画面闪烁的常见诱因，比如频繁触发Canvas重绘、大范围DOM样式更新等操作。

内容的提问来源于stack exchange，提问作者Budda