Reference: MDN – Microtasks and Javascript Runtime Environment recommendation: Javascript event loop: From origin to browser to Node.js (from the origin of the event loop and the event loop to the event scheduling is very clear explanation, I read the understanding of the event loop a little deeper, back to update my blog)
Execution context
When marshalling the learning package, a reference to the execution context is published.
The javascript runtime
Some basic concepts related to the JS runtime
The javascript runtime actually maintains a set of agents that execute the JS code when executing it. Each agent consists of a set of execution contexts, an execution context stack, the main thread, a set of additional threads that might create a user execution worker, a task queue, and a microtask queue. Other than the main thread, which some browsers share between multiple agents, the other components are unique to the agent.
Event loop
Each agent is driven by an event loop that collects events (user events and other non-user events, etc.) and sorts tasks so that callbacks can be performed when appropriate. Event loops are essentially a mechanism that browsers use to coordinate user interactions (mouse, keyboard), scripts (such as javascript), rendering (such as HTML DOM, CSS styles), web behavior, and so on.
The event loop sort is divided into two queues:
-
Task Queue: External Queue/macro Task Queue is mainly a Queue for browsers to coordinate various types of events.
- DOM manipulation (page rendering)
- User interaction (mouse, keyboard)
- Network request
- The timer
- The History Api operations
Tasks added to the queue after each iteration start will not be executed until the next iteration begins
- Microtask Queue: an internal task Queue/Microtask Queue. The HTML standard does not specify the event sources of this Queue. It is generally considered as the following:
- Then and Catch of Promises
- MutationObserver
- Object. Observe (deprecated)
When a (macro) task exits and the execution context is empty, each microtask in the microtask queue is executed in turn. The difference is that it waits until the microtask queue is empty before stopping execution — even if a microtask joins in mid-stream. That is, a microtask can add new microtasks to the queue and complete all of the microtasks before the next task starts and the current event loop ends.
Summarize the law of the event cycle
When running a piece of JS code, the event loop schedules the events like this:
- Retrieves an executable task from the macro task queue, executing it if there is one, and moving down if there is none.
- Remove all tasks from the microtask queue in order to execute them. Play when you finish or when you don’t.
- Browser rendering.
In fact, it is not accurate to call task queue, which should be an ordered set. Queue is first-in-first-out in the cognition of development, but the execution order of macro tasks is not necessarily in the order that they are added to the task set. For example, setTimeout will not be executed even if it is in the first place and does not meet the conditions.
Why empty the microtask queue after fetching an executable from the macro task queue when the SetTimeOut0 code is actually executed after promise.then?
I don’t know if you have this question, but I didn’t understand it before. Later, I read the MDN document to clarify this sentence.
The (macro) tasks added to the (macro) queue at the start of each iteration will not be executed until the next iteration.
Tasks added to the microtask queue at the beginning of the iteration will be cleared before the next iteration begins i.e. all microtasks will be executed.
There are three cycles of events
- Window event loop:
Drive all cognate Windows.
Here, homology refers to multiple child Windows opened by the same window, iframe in the same window, etc. Windows may run in the same event loop.
- Worker event loop: The agent that drives the Worker. Including all types of workers: the most basic Web worker, shared worker and service worker. Workers are placed in one or more agents independent of the “main code,” so the browser handles all workers of a given type with one or more event loops.
- Worklet event loop: Used to drive the Worklet agent. Includes Worklet, AudioWorklet, and PaintWorklet.
thread
The code and the user interface of the browser run in the same thread and share the same event loop. If the code performs complex calculations or has bugs, it may cause blocking or endless loops, which will degrade the performance and affect the user experience. Using the Web Worker can cause the main thread to start a new thread to run the script, alleviating the blocking problem.