帧率稳定在58–60 fps且掉帧减少：通过Chrome Performance面板录制相同操作，对比拆分前后FPS曲线及渲染轨道中紫色块（Rendering）是否变少、变短。
直接看帧率变化最直观：拆分前后用 Chrome Performance 面板录制相同用户操作（比如滚动列表、点击播放），对比 FPS 曲线和渲染轨道中的紫色块（Rendering）是否变少、变短。帧率稳定在 58–60 fps，且掉帧（
用 Performance 面板抓真实帧表现
打开 DevTools → Performance → 点击录制 → 执行一段典型交互（如快速滚动视频列表页）→ 停止录制。重点看三处：
- Main 轨道里的长黄色块：代表长任务，拆分后应明显变短、变少，尤其首屏阶段
- Frames 轨道的 FPS 柱状图：高度越接近 60 越好；柱子底部出现红色“dropped frame”说明掉帧，优化后应基本消失
- Rendering 轨道的紫色块：对应样式计算、布局、绘制。长任务减少后，这些块常会更均匀、不堆积——因为主线程空闲了，渲染能及时调度
配合 TBT 和 FID 等指标交叉验证
长任务减少不等于帧率一定提升，得结合关键指标确认效果：
- TBT（总阻塞时间）：FCP 到 TTI 之间所有长任务阻塞时间之和。从 812ms 降到 200ms 以内，通常伴随 FPS 显著回升
- FID（首次输入延迟）：用户第一次点击/滚动到浏览器开始处理的时间。若从 120ms 降到 30ms，说明主线程响应能力恢复，间接反映帧率稳定性提升
- 滚动时的平均 FPS：可在 DevTools 的 Rendering 设置中开启 FPS Meter，边滚动边观察实时数值，比离线录制更贴近真实体验
加代码级监控，让提升可量化
除了人工录制，用 PerformanceObserver 主动捕获长任务，并关联帧率变化：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
- 用
new PerformanceObserver监听longtask类型，记录每次耗时和触发时机 - 同时用
requestAnimationFrame统计每秒实际帧数（例如每秒调用次数），持续 5 秒取均值 - 上线前后对比：长任务次数下降 60% + 滚动帧率均值从 42fps 升至 57fps，就是强证据
注意干扰项：别把假提升当真效果
有些改动看似帧率变高，实则掩盖问题：
- 只优化了某一个函数，但第三方脚本或 CSS 动画仍在强制同步布局 → FPS 可能短暂回升，滚动一久又掉下去
- 用
setTimeout拆分但 chunk 太小（如每次只处理 1 个元素），导致宏任务过多，反而增加事件循环开销 - 没关掉开发工具的“Disable cache”或“Throttling”，测试环境失真，数据不可信
