javascript执行与页面渲染争夺主线程资源，需用requestidlecallback分片长任务、避免强制同步布局、web worker卸载计算、raf对齐渲染节奏。
JavaScript执行耗时和页面渲染帧率（FPS）本质上争夺的是同一线程资源——浏览器的主线程。JS长时间运行会阻塞渲染，导致掉帧、卡顿；而频繁强制重排重绘又会拖慢JS执行。平衡的关键不是“少写JS”或“少更新UI”，而是让JS工作更可控、更可中断，并与渲染节奏对齐。
用 requestIdleCallback 分割长任务
当必须处理大量数据（如解析大JSON、遍历万级DOM节点），直接循环会阻塞主线程超过16ms，必然丢帧。requestIdleCallback 允许你在浏览器空闲时段分片执行，且自带超时保护：
- 它接收一个回调函数和可选的 timeout（毫秒），若空闲时间不足，超时后也会强制执行
- 回调中通过 deadline.timeRemaining() 判断剩余空闲时间，决定是否继续本次任务
- 适合非实时性任务：日志上报、预加载计算、低优先级状态同步等
注意：需配合 polyfill 使用（如 react-idle-timer 或自行封装），且不支持 Safari 旧版本。
避免强制同步布局（Forced Synchronous Layout）
这是隐藏最深、影响最广的FPS杀手。当你在 JS 中读取某些布局属性（如 offsetTop、clientWidth、getBoundingClientRect）后，又立即修改样式（如 element.style.height = '200px'），浏览器不得不立刻触发回流（reflow）并计算新布局，打断当前渲染流水线。
- 把所有“读操作”集中放在前面，所有“写操作”集中放在后面（即“读-写分离”）
- 用 getComputedStyle(element).height 替代 clientHeight，避免触发脏检查
- 使用 CSS 变量 + will-change 或 transform 实现动画，完全避开布局计算
用 Web Worker 卸载纯计算型逻辑
加密、图像处理、复杂算法、大型数组排序等不涉及 DOM 的任务，应彻底移出主线程：
- Worker 中无法访问 window、document，但可收发结构化数据（包括 ArrayBuffer 零拷贝）
- 配合 Transferable（如 postMessage(data, [arrayBuffer])）大幅降低通信开销
- 现代方案可考虑 Comlink 简化 Worker 调用接口，像调用本地函数一样使用
用 RAF 对齐渲染节奏，而非 setTimeout/setInterval
需要驱动动画或高频 UI 更新时（如拖拽反馈、实时图表），必须用 requestAnimationFrame：
- RAF 自动与显示器刷新率（通常60Hz）对齐，保证每次执行都在下一帧开始前
- 页面后台或节流时自动暂停，节省资源；而 setTimeout 不具备此行为
- 搭配 shouldComponentUpdate 或 useMemo 控制 React 组件更新粒度，避免无意义重渲染
不复杂但容易忽略
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
