requestAnimationFrame 制作数据大屏的核心是精准、省资源、不干扰数据表达，需配合浏览器渲染节奏，用 deltaTime 控制速度，避免重排，协同图表库并做好性能降级。
网页端用 requestAnimationFrame 制作高性能数据大屏，核心不是“让东西动起来”，而是让动得精准、省资源、不抢数据风头。它本质是把动画节奏交给浏览器渲染管线，而不是靠人猜帧率或硬写定时器。
动效必须服务于数据表达
数据大屏里，用户第一眼要看的是数字、趋势、异常点。所有动画都该回答一个问题：“这个动，让用户更清楚数据了吗？”
- 数字滚动更新（如“12,487 → 12,503”）加缓动过渡，能强化变化感知，属于功能性动效，建议做
- 图表切换时用交叉淡入淡出，比突然替换更能维持空间连续性，也推荐
- 背景粒子飘动、光效扫过这类纯氛围装饰，除非品牌强要求且性能实测无影响，否则建议关掉
- 避免对每个卡片、每条折线都加入场动画——叠加过多会拖慢首屏，还干扰注意力
用对 requestAnimationFrame 的三个关键动作
它不是 setTimeout 的替代品，而是要配合浏览器渲染节奏工作：
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 每次回调必须接收时间戳参数，用 deltaTime = currentTime - lastTime 控制运动速度，确保在 30Hz/60Hz/120Hz 设备上表现一致
- 动画中只读一次布局信息（如容器宽高），所有样式写操作集中到帧末尾，优先用 transform 和 opacity，避免触发重排（layout）
- 必须管理生命周期：用变量存 animationId，组件卸载或数据清空时调用 cancelAnimationFrame，并检查元素是否还存在（
if (!el || !el.isConnected)）
和图表库（如 ECharts）协同不打架
大屏常用 ECharts 渲染图表，但它内部已有自己的动画调度。直接在外层用 rAF 驱动图表实例的 setOption 会冲突，导致卡顿或丢帧：
- 图表自身的动画交给 ECharts 配置项控制（
animation: true,animationDuration: 800） - 若需同步多个图表状态（比如联动高亮），可在 ECharts 的
dispatchAction后，用 rAF 封装后续 UI 反馈（如边框脉冲、标签放大），而非驱动图表重绘 - 避免在 rAF 循环里反复调用
chart.getDom().getBoundingClientRect()或chart.resize()，这些是强制回流大户
性能兜底与降级策略
大屏常运行在老旧工控机或低配安卓盒子上，不能只依赖理想环境：
- 首次加载时用
performance.now()初始化时间基准，避免首帧 currentTime 为 0 导致 deltaTime 异常 - 监测连续两帧耗时 > 16ms，可临时降低动效密度（如暂停非关键粒子、简化数字滚动缓动曲线）
- CSS 层面开启硬件加速：给动效容器加
transform: translateZ(0)或will-change: transform，但注意别滥用引发层爆炸 - 后台标签页自动暂停：rAF 天然支持，无需额外处理；但若需保持数据轮询，应拆开逻辑——用
setInterval做数据拉取，rAF 只负责可视化更新
