- 输入聚焦10ms
- 交互响应，100ms
- 渲染16ms
- 以块的形式进行工作，避免阻塞
- 给与块以优先级
- 需要一个调度程序，它能了解我们的任务和优先级，并在最佳时间执行他们
- uses rAF to run the scheduler
- High priority task types are executed synchronously within rAF
- “Other” task type
- executed via “nextTick”
- 6 priority levels
- “nextTick”: Yields to browser using messagechannel to message itself in rAF
-
4 task priority levels: -ImmediatePriority, UserBlockingPriority, NormalPriority, IdlePriority
-
expiration times mapping to priority
-
enables dynamic adjustment: something that starts as low priority gets higher as it approaches the deadline. Expired tasks are the most important.
Uses rAF to run the scheduler and yield (with postmessage). Heading towards not yielding (and not using rAF) when sufficient signals are available..
-
rAF posts postMessage, within postMessage handler:
- do as much work as possible until “time + frame rate”
- execute expired tasks without yielding
- keep executing callbacks until out of time
- before exiting, flush all the “immediate priority” callbacks
-
- Set of tasks with priority
-
- “virtual” task-queues for managing groups of tasks
-
- API for posting tasks
-
- run-loop
- mechanism to execute tasks at an appropriate time, relative to the current state of the user and the browser
- (React & Maps use rAF for this currently)
run-loop requires knowledge of:
- rendering
- timing of next frame
- time budget within current frame
- input
- is input pending
- how long do we have before input should be serviced
- loading, navigation (including SPA nav)
Ideally run-loop can effectively coordinate with other work on the main thread:
- fetches and network responses
- browser initiated callbacks: eg. onreadystatechange in xhr, post-message from worker etc
- browser’s internal work: eg. GC
- rendering: tasks may be reprioritized dependent on renderer state
- other developer scheduled callbacks: eg. settimeout