How the browser works (i): Browser processes and Threads

Reference: 1190000012925872#articleheader4

First, the browser is multi-process, the browser core is multi-threaded, JS engine is single-threaded

1, the browser is multi-process, the main process includes the following:

Process Name	Number	Role
Browser Master Process	1 x	Master process, responsible for coordinating other processes Responsible for browser interface display, interact with user. such as forward, retreat, etc Responsible for managing each page, creating and destroying other processes Draws the renderer process to the in-memory bitmap to the user interface Management of network resources, download ......
Rendering process	A tab page A	That is, the browser kernel, the internal is multi-threaded, the main role: Page rendering Script execution Event handling ......
Plug-In Process	A type of plug-in one	Created when the plug-in is used
GPU Process	0 or 1	For 3D drawing, etc.

2, the browser core is multi-threaded, the main thread includes the following:

Thread Name	Role	Threading Relationships
GUI Rendering thread	Responsible for rendering the browser interface, including Parse Html,css, build dom tree and RenderObject tree, layout and draw, etc. Redraw (Repaint) and reflow (reflow) processing	The GUI rendering thread is mutually exclusive to the JS engine thread Since JavaScript is a manipulation of the DOM, the element data obtained before and after the render thread may be inconsistent if you modify these element properties to render the interface simultaneously (that is, the JS thread and the UI thread run concurrently). This mutex is designed to prevent unpredictable results from rendering When the JS engine executes, the GUI thread will be suspended, and the GUI update will be saved in a queue until the JS engine thread is idle and executed immediately. This can also be inferred, JS if the execution time is too long will block the page
JS engine thread	Also known as the JS kernel, is responsible for processing JavaScript scripts. (e.g. V8 engine) The JS engine thread is responsible for parsing the JavaScript script and running the code. The JS engine waits for tasks in the task queue and then handles them. A tab page (renderer process) whenever there is only one JS thread running JS program
Event Trigger Thread	belongs to the rendering process, not the JS engine, to control the event loop When the JS engine executes code blocks such as settimeout (which can also come from other threads of the browser kernel, such as mouse clicks, Ajax asynchronous requests, etc.), the corresponding task is added to the event thread When the corresponding event matches the trigger, the thread adds the event to the end of the queue to be processed and waits for the JS engine to process Note: because of the single-threaded connection of JS, so the events in the backlog queue wait for the JS engine processing, the JS engine is idle to execute
Timed Trigger Thread	setIntervalWith setTimeout the thread The browser timer counter is not counted by the JS engine. The JS engine is single-threaded, and if it is in a blocked thread state it affects the accuracy of the timing, so the timing is timed and triggered by a separate thread After the timer is finished, add to the event queue and wait for the JS engine to execute after idle Note: In the HTML standard, it is stipulated that the time interval of less than 4ms in settimeout is calculated as 4ms.
Asynchronous HTTP Request Thread	XMLHttpRequest After the connection is a new thread request through the browser When a state change is detected, if a callback function is set, the asynchronous thread generates a state change event and puts the callback into the event queue. It is then executed by the JavaScript engine.

How the browser works (i): Browser processes and Threads