WebKit architecture and modules

Features: Support for different browsers. Some code is shared and some is different. The different parts are called Ports for WebKit.

  • At the bottom is the operating system, and WebKit works on different operating systems
  • On top of the operating system are the third-party libraries that WebKit relies on, which are the foundation on which WebKit runs
  • The next level up is the WebKit project, which is divided into two layers
    • WebCoreSections contain the shared sections currently used by various browsers and are the basis for processing rendered web pages. Including HTML (interpreter), CSS (interpreter), SVG, DOM, render tree (ReaderObject tree, ReaderLayer tree, etc.), Inspector (Web Inspector developer tools, debugging Web pages)
    • JavaScriptCoreThe engine is the default JavaScript engine in WebKit, and calls to the JavaScript engine in WebKit are engine independent. For example, in Chromium, the V8 engine is replaced
    • WebKit PortsThis refers to the non-shared parts of WebKit, including hardware accelerated architecture, networking stack, video decoding, image decoding, and so on
  • WebCore 和 WebKit PortsThe layer above primarily provides an embedded programming interface for browser calls. The definition of the interface layer is also closely related to migration, rather than WebKit having a unified interface.

The WebKit2 embedded interface is not a simple modification of the WebKit embedded interface, but introduces a cross-process architecture for security and stability reasons in the browsing environment. Released by Apple in April 2010, WebKet2 has at least two processes in its process structure model, one is the UI process of WebKit2’s browser or Web platform, and the other is the Web process, that is, the process of Web page rendering

Chromium browser structure based on Blink

Chromium browser architecture and modules

Chromium is also based on WebKit (Blink), and has introduced many advanced concepts into the field of browsers, which can understand how to build browsers based on WebKit.

Structure and Modules

The Chromium architecture and main modules are as follows:

As you can see from the figure, Blink is just one of them, and there are many Chromium modules, Including the GPU/CommandBuffer (hardware acceleration architecture), V8 JavaScript engine, sandbox models, CC (Chromium Compositor | Chromium synthesizer), IPC (inter-process communication), NPAPI (Netscape Plugin API), UI, etc

Further up are the “Content module” and the “Content API”, which are Chromium abstractions for rendering web pages. The sandbox model, cross-process GPU hardware acceleration, and many HTML5 features are implemented in the Content layer, which hides rendering, security, and plug-in mechanisms and provides an interface for upper-level modules to use.

Multiprocess model

Benefits:

  • Avoid single page unresponsiveness or crashes that affect the stability of the entire browser
  • Crashes of third-party plug-ins do not affect the stability of the page or browser
  • The sandbox model is based on multi-process architecture

The main process types included in the Chromium browser

  • Browser process: The main process of the Browser
  • Renderer process: A process responsible for rendering pages. There may be more than one, but not necessarily the same number of open pages
  • NPAPI plugins: Created for NPAPI plugins. Each type of plugin is created once and only when used. Multiple web pages share the same process but have different instances.
  • GPU process: This process is created only when GPU hardware acceleration is enabled
  • PPAPI process: process created by the Pepper plug-in
  • Other types of processes: The “Zygote” process under Linux from which Renderer is created. Sandbox preparation process

The Android version does not support plug-ins. The GPU process becomes a thread of the Browser process, and the Renderer process evolves into a Service process on Android. And there is a “shadow” tag, will be the background of the webpage used by the rendering facilities are cleared, when the user switch when the need to reload the rendering.

The Renderer process is created in the following way:

  • Process-per-site-instance: Each page has its own Render Process
  • Process-per-site: Pages in the same domain share the same Process
  • Process-per-tab :(default) per TAB
  • Single Process: All rendering is done in the Browser process, which is used in Android WebView
Browser process and Renderer process

Because some types in Chromium are not consistent with WebKit internally, Chromium does not directly use WebKit interfaces but Bridges them with adhesion layers. Renderer for interprocess communication was added on top of the bridge layer, encapsulating rendering as a separate service and masking the concrete implementation.

RendererHost is also required in the Browser process to handle process communication, followed by Web Contents, which are TAB by TAB and the top Browser UI

Multithreaded model

There are many threads in each process to ensure that the UI threads in the Browser process are not affected by any other time-consuming operations. Let nothing else prevent the Renderer thread from executing quickly. In addition, the rendering process is piped so that the rendering can be executed in different threads (the rendering process is divided into many independent stages, and one thread is created in each stage, making use of the CPU’s multi-core capability to speed up the rendering and improve the concurrency like an assembly line).

Page loading rendering process

  • The Browser process receives user requests, which are processed by the UI thread, forwarded to the IO thread, and then passed to the Renderer process
  • The Renderer process has its own IO thread, which is handed over to the Renderer process after simple explanation. The rendering process may require the Browser process to obtain resources and the GPU process to render. The render results are passed to the Browser process by the IO thread
  • Browser process drawing

Interprocess communication: Most scenarios use events and the task passing mechanism created by Chromium, using locks or thread-safe objects only when absolutely necessary.

The Content interface

The Content interface not only provides a layer of encapsulation for multi-process rendering, but also supports all HTML5 features, GPU hardware acceleration, and sandbox.

WebKit2

WebKit2 is a set of permission structures and interfaces, similar in purpose to Chromium, that put the rendering process in a separate process.

Compare WebKit2 and Chromium

  • Chromium uses the WebKit interface, not WebKit2
  • Chromium encapsulates rendering as a service and builds multiple processes on top of the service. WebKit2 wants to hide the multi-process structure and implement the multi-process model directly in rendering.

More and more

WebKit Technology Insider knowledge extraction – resource loading and networking stacks