Browser processes include:

  • Browser process (main process)

    • Move back
    • Page management creates and destroys other processes
    • Management downloads of network resources
    • Draw an in-memory bitMap from the Render process to the user interface

  • Browser rendering process

    • By default, each Tab page has one process and does not affect each other
    • Used to render pages, execute scripts, and handle events
    • The browser rendering process includes
    • GUI rendering thread
    • Responsible for rendering browser interfaces, parsing HTML, CSS, building DOM trees and rendering trees, layout and drawing
    • Interface rearrangement redraw
    • GUI rendering thread and JS thread are mutually exclusive. When the JS engine thread executes, the GUI thread is suspended, and GUI updates are stored in a queue to be executed as soon as the JS engine thread is idle.
    • Why GUI and JS engine threads are mutually exclusive
    • JS can manipulate the DOM. If you render the interface at the same time as modifying elements (i.e., the JS thread and the GUI thread), the data obtained before and after the render thread is likely to be inconsistent

  • JS engine thread

    • Responsible for handling JS scripts (e.g. V8 engine)
    • The JS engine waits for the task to arrive in the task queue,
    • Note that the JS thread is mutually exclusive with the GUI thread, and if the JS thread executes for too long, the page rendering will be incoherent and the page rendering load will block

  • Event trigger thread

    • The browser, not the JS engine, controls the event loop
    • When the JS engine executes a block of code, such as a click event, Ajax, etc., the corresponding task is added to the event thread
    • When the corresponding event is triggered, the thread adds the event to the end of the queue, waiting for the JS engine to process it
    • Due to the single-threaded nature of JS, all these pending events are queued up for processing by the JS engine

  • Timing trigger thread

    • SetInterval, setTimeout Specifies the thread where setTimeout resides
    • Browser timing counters are not counted by the JS engine (because the JS engine is single-threaded and the accuracy of the count is affected if it is blocked)
    • So timing is done by a separate thread and timing is triggered (even after completion, add to the end of the event queue and wait for the JS engine to be idle)
    • In addition, if setTimeout is less than 4ms, it is calculated as 4ms

  • Asynchronous request thread

    • XMLHttpRequest requests a new thread from the browser after the connection has been established
    • When the request state changes, if there is a callback function, the asynchronous request thread generates the state change event, puts the event into the event queue, and then executes it by the JS engine.

  • Third-party plug-in processes

    • Each plug-in corresponds to a process that is created only when the plug-in is used

  • GPU process

    • One at most, used for 3D drawing, etc

Why is JS single threaded

  • The main purpose of JS is to interact with users and manipulate the DOM

    • So if you have multiple threads that can cause synchronization problems, for example two threads that add content to the DOM and one that deletes the DOM, there will be a conflict

  • In order to take advantage of CPU’s multi-core capability, Web Worker standard is used in H5

    • Allows JS to create multiple threads
    • However, child threads are completely controlled by the main thread and cannot manipulate the DOM