之前我写了一个埋点库 sunshine-track ，很多人问我为啥批量上报埋点信息的时候，用的是 requestIdleCallback 而不是 requestAnimationFrame，今天就解答一下。
sunshine-track 源码学习：https://github.com/sanxin-lin/sunshine-track。
一、背景与问题场景
在前端性能监控领域，埋点信息上报是重要的数据收集手段。当我们需要批量上报用户行为数据时，传统同步上报方案可能导致以下问题：
- 阻塞主线程造成页面卡顿
- 影响关键渲染流程的执行
- 造成不必要的性能损耗
二、核心API对比分析
1. requestAnimationFrame（rAF）
执行时机：每次重绘前（约16.6ms/次）
设计目的：执行与渲染相关的动画逻辑
优先级：高（属于浏览器渲染流水线的一部分）
特点：
- 保证与屏幕刷新率同步
- 页面隐藏时自动暂停
2. requestIdleCallback（rIC）
执行时机：浏览器空闲时段
设计目的：执行低优先级任务
优先级：低（仅在空闲时执行）
特点：
- 提供deadline参数判断剩余时间
- 页面隐藏时可能不会执行
- 可设置超时时间强制执行
三、选择 requestIdleCallback 的核心原因
1. 执行时机的合理性
- 埋点上报是非关键任务，不需要抢占渲染资源
- 避免在渲染关键路径中插入网络I/O操作
- 适合利用浏览器的空闲时段执行
2. 优先级控制
- 用户交互 > 动画渲染 > 空闲任务
- rAF属于高优先级（每帧必须执行）
- rIC属于低优先级（可被浏览器跳过）
3. 性能影响对比
指标 | rAF方案 | rIC方案 |
主线程阻塞概率 | 较高 | 极低 |
影响FPS的可能性 | 可能 | 无 |
CPU使用率 | 较高 | 优化空间大 |
执行可靠性 | 高 | 需超时处理 |
4. 容错机制
四、特殊场景处理建议
1. 页面关闭前的上报
2. 兼容性处理
使用 polyfill 方案：
3. 超时控制策略
五、最佳实践总结
- 分优先级处理：关键数据立即上报，普通数据批量处理
- 队列机制：积累足够数据或达到时间阈值时触发
- 混合策略：结合 rIC + 超时机制 + 降级方案
- 性能监控：记录上报任务执行耗时
- 错误重试：对失败请求进行指数退避重试
六、结论
选择 requestIdleCallback 的核心优势在于其能够：
- 最大限度减少对用户体验的影响
- 智能利用浏览器空闲时段
- 实现优先级合理的任务调度
- 避免与关键渲染流程竞争资源
