requestIdleCallback vs requestAnimationFrame

requestIdleCallback MDN 介绍

requestAnimationFrame MDN 介绍

语法如下:

1const process = (deadline) => {
2  // 通过deadline.timeRemaining可获取剩余时间
3  console.log('deadline', deadline.timeRemaining());
4}
5window.requestIdleCallback(process);
6window.requestIdleCallback(process, {
7    timeout: 100 // If the number of milliseconds represented by this parameter has elapsed and the callback has not already been called, then a task to execute the callback is queued in the event loop (even if doing so risks causing a negative performance impact). `timeout` must be a positive value or it is ignored.
8});

1requestAnimationFrame(callback)

https://stackoverflow.com/questions/41740082/scroll-events-requestanimationframe-vs-requestidlecallback-vs-passive-event-lis

• requestIdleCallback
  Due to the fact at which point in the frame life cycle rIC callbacks are called you should not alter the DOM (use rAF for this).
• requestAnimationFrame
rAF gives you the point inside the frame life cycle right before the browser wants to calculate the new style and layout of the document. This is why it is perfect to use for animations. First it won't be called more often or less often than the browser calculates layout (right frequency). Second it is called right before the browser does calculate the layout (right timing). In fact using rAF for any layout changes (DOM or CSSOM changes) makes a lot of sense. rAF is synced with the V-SYNC as any other layout rendering related stuff in the browser.

https://medium.com/@paul_irish/requestanimationframe-scheduling-for-nerds-9c57f7438ef4

https://www.cnblogs.com/echolun/p/16414562.html

React 框架 | 深入剖析 Scheduler 原理

https://github.com/facebook/react/issues/21662
No, it fired too late and we'd waste CPU time. It's really important for our use case that we utilize CPU to full extent rather than only after some idle period. So instead we rewrote to have our own loop that yields every 5ms.