Chrome design document-multi-process Architecture

Chromium multi-process Architecture

This document describes the multi-process architecture of Chromium from the perspective of high-level.

Problem

To buildNever crash or suspendRendering Engine is almost impossible. Similarly, it is impossible to build a 100% secure rendering engine.

From some perspective, today's Web browsers are a bit similar to previous single-user, multi-task operating systems. Just as an abnormal program will cause the entire system to go down, an abnormal webpage will also cause a modern browser to go down.

The reason why modern operating systems are more robust is that they place applications in isolated processes. An application crash does not affect other applications or the operating system itself. Any user's data operations on other users are strictly restricted.

Architecture Overview

We use isolated processes for browser tabs. This solution protects the application from being complete and is not affected by the rendering engine's bugs or small errors. At the same time, we also strictly restrict access from the rendering engine to other processes. In some aspects, this brings the benefits of memory protection and access control to Web browsing. These two points are based on the operating system.

The main process is called "browser process" or "Browser ". This process is responsible for UI running and Tab management, and also for Agent process management. Similarly, a tab-specific process is called "render process" or "Renderer ". Renderers uses the "WebKit" Open-Source engine to parse and layout HTML documents.

Manage rendering processes (rendering process/Renderer)

Each Renderer corresponds to a global renderprocess object. This object manages the communication between the Renderer and the browser process of the parent process, and maintains the global status. Browser maintains multiple renderprocesshost objects. Each renderprocesshost corresponds to a Renderer. Browser is responsible for controlling the browser status and communicating with Renderer. The communication between browser and renderers is undertaken by the chromium IPC System.

Manage views

Each Renderer has one or more renderview objects. A Renderer is equivalent to a tab. Correspondingly, renderprocesshost maintains an renderviewhost. A renderviewhost corresponds to a view in Renderer. In the same Renderer, in order to distinguish different views, each view is assigned an ID. These IDS are unique in the same Renderer, but not in the browser. Therefore, to identify a view, you need renderprocesshost and a view ID.

Components and interfaces

In the render process:

• Renderprocess processes the IPC between renderprocesshost and renderprocesshost. Renderprocesshost is located in browser. Each render process has only one renderprocess. The communication between all browser and Renderer is like this.
• The renderview object communicates with the renderviewhost in the browser process (of course, it is completed through renderprocess ). Renderview indicates the content of a webpage or the content of a webpage in the pop-up window.

In the browser process:

• The browser object represents a browser window at the top layer.
• Renderprocesshost represents the browser <-> Renderer IPC connection. In browser, each render process corresponds to an renderprocesshost.
• Renderviewhost encapsulates the communication process with remote renderview. Renderwidgethost processes the drawing of input and renderwidget.

Shared Renderer

Generally, a new window or a new tab opens a new process. The browser generates a new process and instructs it to create a separate renderview.

Sometimes, sharing Renderer between tabs and Windows is also required or necessary. For example, a Web application uses window. Open to open a new window in synchronization mode. In this case, when creating a new window or tab, We need to reuse the original process, that is, the process where the window opens. When the number of processes is too large, we also have a corresponding policy to hand over the new tab to the existing process. For more information about these policies, see process models.

Crash Detection or rendering exception

Each IPC link to the browser process monitors the rendering process (Renderer) handle. If these handles receive signals, the rendering process will crash and the tab page will receive a crash notification. From now on, when Renderer crashes, We will display a "Sad tab" screen to notify users. You can click "preload" to reload the current page.

Renderer sandbox

If WebKit runs in a separate process, we have the opportunity to control its access to system resources. For example, we can limit that the network operation of the Renderer can only be completed by its parent process. Similarly, we can strictly restrict its access to the file system.

Plug-ins

The npapi plug-in runs in its own process and is separated from renderers. For more information, see plugin architecture.