最简单Canvas示例出现Dropped Frame丢帧及帧耗时不一致问题排查

掉帧（Dropped Frame）的核心原因 #

你给出的基础示例出现掉帧，主要有以下几个原因：

• 全屏像素填充开销超出预期：你用CSS把canvas设为100%宽高，再乘以设备像素比（dpr）后，canvas的实际像素渲染尺寸会非常大，比如普通1080P屏dpr为2的情况下，单帧需要填充的像素量超过800万，看似只有清屏+画圆两个操作，实际GPU的像素填充压力很高，很容易超出60帧要求的16.6ms单帧阈值，触发掉帧。
• 主线程抢占开销：浏览器主线程除了执行你的requestAnimationFrame回调和渲染逻辑外，还需要处理mousemove事件、其他浏览器内部任务、甚至系统后台进程的调度抢占，偶尔会挤占渲染的时间窗口导致帧超时被丢弃。
• 性能分析工具本身的 overhead：Chrome DevTools的性能录制功能本身会占用额外的CPU/GPU资源，开启录制时统计到的掉帧率会比实际运行时高很多，属于正常现象。

不同帧耗时不一致的原因 #

单帧耗时波动是非常正常的现象，核心原因是：

• 每一帧主线程需要处理的任务量不固定：比如mousemove事件的触发频率随鼠标移动速度变化，有的帧可能触发10次回调，有的帧可能1次都没有，执行耗时自然有差异。
• 浏览器后台任务波动：比如V8引擎的自动垃圾回收（GC）、浏览器的内部页面状态更新、网络请求回调等任务，都会随机插入到主线程执行，拉长对应帧的耗时。
• 系统级资源调度波动：CPU、GPU的资源分配是系统全局调度的，如果你后台有其他程序占用硬件资源，当前页面的渲染任务拿到的资源会动态变化，直接影响单帧耗时。

可尝试的优化方案 #

• 用脏矩形渲染替代全屏清屏：每次只清除上一帧圆形所在的区域，再绘制新的圆形，大幅减少像素填充量。
• 合并mousemove事件回调：通过requestAnimationFrame节流mousemove的坐标更新逻辑，避免同一帧内多次修改坐标，减少事件执行开销。
• 适当降低渲染分辨率：在画质可接受的范围内，把canvas.width = width * dpr改为canvas.width = width * dpr * 0.8，降低GPU压力。
• 给canvas元素添加CSS属性will-change: transform，提示浏览器提前为canvas分配GPU渲染资源，减少运行时的调度开销。

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