Processes and threads

The smallest unit of resources allocated by a process CPU

The smallest unit of thread CPU scheduling

Browsers are multi-process

  • Opening a TAB page creates an independent browser process. Multiple TAB pages can be merged into one process based on the optimization mechanism of the browser

Which processes are included in the browser

Opening a web page in the browser is like opening a new process, which has its own multithreading

  • Browser process (the main process of the Browser, only one)
    • Page display, interaction with the user, such as forward and backward
    • Manage individual pages and create and destroy other processes
    • Network resource management, such as downloads
  • Third-party plug-in processes
    • Each type of plug-in corresponds to a process that is created when the plug-in is used
  • GPU process
    • One at most for 3D drawing
  • Browser renderer (browser kernel)
    • By default, each TAB page has one process and does not affect each other
    • Page rendering, JS script line, event handling, etc

Advantages of multi-process browsers

If the browser is in process, a TAB page crashes, affecting the entire browser

Browser kernel (Render process)

Browser renderers are multithreaded

  • GUI rendering thread
    • Responsible for rendering pages, parsing HTML, CSS, building DOM trees, and RenderObject trees, layout and drawing, etc
    • This thread executes when the page needs to be repainted or Reflow
    • GUI threads and JS threads are mutually exclusive. When the JS engine executes, the GUI thread is suspended, and GUI updates are stored in a queue for immediate execution when the JS thread is idle
  • JS thread
    • Also known as JS kernel, responsible for parsing JS scripts and running code
    • There is always only one JS thread per TAB page waiting for tasks in the task queue
    • When the JS thread executes the code, the corresponding task is added to the event thread
  • Event trigger thread
    • The browser, not the JS thread, controls the event loop
    • When an event is emitted, the thread adds the event to the end of the queue, waiting for the JS engine to process it
    • Since JS is a single thread, events in the queue are queued to be processed by the JS thread and executed when the JS engine is idle.
  • Timer trigger thread
    • Such as setInterval and setTimeout
    • The browser timer is not provided by the JS thread. After the timer is finished, it is added to the event queue and executed after the JS engine is idle, so the JS timer is not correct
    • The interval shorter than 4ms in setTimeout is 4ms
  • Asynchronous HTTP request threads
    • After connecting, XMLHttpRequest is requested through a thread opened by the browser
    • When a state change is detected, if there is a callback function, the asynchronous thread generates a state change event, puts the callback into the event queue, and executes it by the JS thread

Browser process and Browser kernel (render process) communication process

Open the task manager, then open the browser, you can see two processes appear in the task manager, one is the master process, the other is to open the TAB page renderer process, the process is as follows

  • The Browser process receives a user request, first goes to the page content (such as downloading a resource over the network), and then passes the task to the Render process via the RendererHost interface
  • The Render process receives the message, hands it to the Render process, and begins rendering
    • The renderer process receives the request, loads and renders the page
    • JS threads manipulate the DOM
    • Finally, the Render process passes the result to the Browser process
  • The Browser process receives the results and draws the page

The relationship between threads in the browser kernel

GUI rendering threads are mutually exclusive with JS threads

  • Since the JS thread can manipulate the DOM, if you render the page while modifying these element attributes, the element data obtained before and after the render thread may be inconsistent
  • To prevent unexpected results from rendering, the browser sets the GUI rendering thread to be mutually exclusive with the JS thread, and the GUI thread is suspended when the JS thread executes
  • GUI updates are stored in a queue and executed as soon as the JS engine thread is idle

JS blocks page loading

The reason as above

Web Worker

Since JS is single threaded, if the previous task is not finished, the subsequent task can only queue, Web Worker is to solve this problem. The function of Web Worker is to create a multi-threaded environment for JS, allowing the main thread to create Worker threads and then assign some tasks to run. When the main thread is running, Worker threads run in the background without interfering with each other. After the Worker thread completes the task, it returns the result to the main thread. Once the Worker thread is successfully created, it will always run and will not be interrupted by the activities of the main thread. In this way, it is conducive to respond to the communication of the main thread at any time. However, Woker is more wordless. Should be shut down immediately.

There are the following points to pay attention to

  • The same-origin restrictions
    • The script file assigned to the Worker thread must be of the same origin as the script file of the main thread
  • DOM limit
    • Different from the main thread, the global object where the Worker thread is located cannot read the DOM object of the page where the main thread is located, nor can document, window, parent objects be used, but the Worker thread can use navigator object and LoAction object
  • A correspondence
    • Worker threads and main threads are not in the same context; they cannot communicate directly and must be done via messages
  • Script limit
    • Worker threads cannot execute the Alert and confirm methods, but can use Ajax requests made by XMLHttpRequest objects
  • File limit
    • The Worker thread cannot read local files, and the scripts it loads must come from the network

Basic usage

Direct point I go to ruan teacher’s blog, here do not repeat

Share workers and Web workers

  • Web workers only belong to one page and are not shared with the Render process of other pages
    • Belongs to only one thread under the Render process
    • So in Chrome, create a new thread in the Render process to run the JS application in the Worker
  • A Share Worker is shared by all pages of the browser and cannot be implemented in the same way as a Web Worker
    • A single process

Browser Rendering process

  • Parse the HTML tree and build the DOM tree
  • Parse the CSS to build a CSS tree and merge it with the DOM tree into a Render tree
  • Render tree layout, responsible for each element size, position calculation
  • Render the Render tree, rendering the page pixel information
  • The browser will send the information of each layer to the GPU, and the GPU will tell the composition and display of each layer

The sequence between the Load event and the DOMContentLoaded event

  • When the load event is triggered, all the DOM, stylesheets, JS scripts, and images of the page have been loaded
  • When the DOMContentLoaded event starts, only the DOM is loaded

Whether CSS loading blocks DOM tree rendering

CSS is downloaded asynchronously by a separate download thread, so it does not block DOM tree parsing, but it blocks render tree rendering (which needs to wait for CSS to load). Since CSS loading may modify the style of DOM nodes, if CSS loading does not block render rendering, the Render tree may need to be redrawn and reflow after CSS loading, resulting in additional performance loss

Event Loop and JS runtime mechanism

  • JS atmosphere synchronous and asynchronous tasks
  • Synchronization tasks are executed on the main thread, forming a == execution stack ==
  • Outside of the main thread, the event-triggering thread manages a == task queue == and pushes an event into the == task queue == whenever the asynchronous task runs with a result
  • When all synchronous tasks in == execution stack == are completed (at this time, the JS thread is idle), the system will read the task queue, add runnable asynchronous tasks to the executable stack, and start execution

The timer

  • It is controlled by timer thread separately to avoid JS thread blocking and affect timing accuracy.
  • When setTimeout or setInterval is used, the timer thread will be called. After the timing is completed, the event to be executed will be pushed to the event queue, which will be executed only after the task in the queue is completed. Therefore, the timer is inaccurate

Why setTimeout instead of setInterval

  • When setTimeOut expires, the task in the timer will be executed.
  • SetInterval pushes an event into the task queue at precise intervals each time, but the execution time of the event may not be accurate. The next event may come before the execution of this event is complete, causing the timer code to run for multiple times without any interval.
  • When the browser is minimized, setInterval callbacks are queued and executed all at once when the window opens again