用requestAnimationFrame优化渲染帧率的关键是嵌入浏览器渲染流水线：避开强制布局、聚焦transform/opacity等可合成属性、用Performance API测量帧耗时、按需启停rAF循环，并分层归因卡顿。
用 requestAnimationFrame（rAF）优化复杂页面的渲染帧率，关键不是“调用它”，而是让它真正嵌入浏览器渲染流水线——避开强制布局、聚焦可合成属性、配合 Performance API 定位卡点，并控制执行节奏。
只在 rAF 里做两件事：更新状态 + 设置样式
每一帧中，rAF 回调应严格限制为「逻辑计算」和「样式写入」，禁止读取布局信息（如 offsetTop、getBoundingClientRect()、scrollHeight）：
- 读-改-读交替操作会触发强制同步布局（Layout Thrashing），单帧内多次重排，耗时飙升
- 若必须获取尺寸，统一放在上一帧末尾批量读取，本帧只写；或用 ResizeObserver 替代主动查询
- 动画属性只用
transform和opacity，它们走合成层（Compositor Layer），不触发布局与绘制
用 Performance API 主动测量帧耗时，不靠感觉
rAF 本身不告诉你这帧花了多久。需手动构建测量闭环：
DeepBI DHTML 页面生成器
下载
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 在 rAF 回调开头调用
performance.now()记录起始时间 - 完成状态更新和样式设置后再次采样，差值即真实帧耗时
- 超过 16.7ms 标记为潜在卡顿帧；连续 3 帧 > 50ms 或单帧 > 100ms，触发轻量上报
- 配合
PerformanceObserver监听longtask类型，确认是否 JS 长任务抢占了渲染时间
避免无意义的 rAF 循环，按需启停
复杂页面常含多个动画模块（轮播、视差、粒子效果等），不能全量常驻 rAF：
立即学习“前端免费学习笔记（深入）”；
- 监听
document.hidden，页面不可见时cancelAnimationFrame暂停所有非必要循环 - 元素移出视口后暂停其动画，进入视口再恢复（可用 IntersectionObserver 驱动）
- 对低优先级动画（如背景微动）设帧率上限，例如 30fps：
if (timestamp - lastRender > 33) { render(); lastRender = timestamp; }
上线后分层归因，别只看平均帧率
60fps 平均值掩盖抖动。生产环境应保留异常感知能力：
- 仅监听
['paint', 'longtask', 'first-input']三类条目，避免采集开销反噬性能 - 上报异常帧时附带设备指纹：
navigator.hardwareConcurrency、screen.width、devicePixelRatio - 按设备分组分析帧耗时分布：若仅在 2 核低端机高频出现 > 80ms 帧，说明需拆分 JS 任务而非压缩资源
- 将卡顿帧时间戳与自定义标记（如
performance.mark('hero-anim-start')）对齐，还原用户操作路径
