Chromium multi-process architecture brief introduction and Learning Plan

Chromium is known for its multi-process architecture, which consists of four types of processes, namely the browser process, the render process, the GPU process, and the plugin process. The reason to separate the render process, GPU process, and plugin process is to solve their instability problems. That is, the render process, the GPU process, and the crash caused by the plugin process will not cause the entire browser to crash. This article provides a brief introduction to the multi-process architecture of chromium and the development of a learning plan.

Lao Luo's Sina Weibo: Http://weibo.com/shengyangluo, welcome attention!

        A chromium instance has only one browser process and one GPU process, but the render process and the plugin process may have several. The browser process is responsible for compositing the browser's UI, including the title bar, the address bar, the toolbar, and the page contents of each tab. The render process is responsible for parsing and rendering the contents of the Web page. In general, a tab is supposed to have a render process. But we can also set the startup parameters so that the tab with the same domain name runs in the same render process. For simplicity, let's assume that a tab is supposed to have a render process. Both the browser process and the render process are rendering the UI through the GPU process when hardware-accelerated rendering is enabled. However, the render process renders the content of the Web page in an off-screen window, such as rendering on a frame buffer object, while the browser process renders the UI directly on the frame buffer, which is the screen. Because of this, the render process renders a good web UI to be synthesized by the browser process before it can be seen on the screen. The plugin process is used to run third-party developed plugin so that the browser's functionality can be extended. For example, Flash is a plugin that runs in a separate plugin process. Note that in order to avoid creating too many plugin processes, different instances of the same plugin are running in the same plugin process. That is, whether it is a similar plugin created on a page of the same tab, or a similar plugin created on a different tab page, they are all running in the same plugin process.

As you can see from the above analysis, although each process has different responsibilities, they are not isolated, but require the same collaboration, which requires the implementation of interprocess communication (IPC). For example, after the render process renders its own parsed web page, it needs to notify the GPU process to render the UI of the resolved Web page out of screen rendering, and then to inform the browser process to synthesize a Web UI that has been rendered off-screen. Similarly, the browser process needs to synthesize the title bar, the address bar, the toolbars, and the off-screen UI of individual pages through the GPU process. For the plugin process, the render process needs to send some Web page events to it for processing so that the render process needs to communicate with the plugin process. In turn, the plugin process also needs to request some Web page-related information through the SDK interface to the render process so that the content of the Web page can be expanded. Further, if the plugin process needs to draw its own UI, it also needs to communicate indirectly to the GPU process through the render process.

The browser processes, render processes, GPU processes, and plugin processes that are analyzed above, and how they communicate, can be described in Figure 1 as follows:

Figure 1 Chromium multi-process architecture

As you can see from Figure 1, each process has an IO thread in addition to the main thread used to implement its responsibilities. This IO thread is not used to perform IO such as reading and writing disk files, but is used to execute the IPC. They are called IO threads because the object they manipulate is a file descriptor. The object that is then manipulated is the file descriptor, which can also be called IO. Of course, these are special Io, specifically, a Unix Socket. The UNIX socket is used to perform the local IPC, and its concept is similar to the pipeline. But the communication of the pipeline is unidirectional, one end can only read, the other end can only write, and the UNIX socket communication is bidirectional, each end is both readable and writable.

For the implementation of IO threading, refer to the previous chromium multithreaded model design and implementation analysis article. Simply put, we can get two file descriptors after we create a UNIX socket. One file descriptor as server side, added to the server side of the IO thread of the message loop to monitor, another file descriptor as the client side, added to the client side of the IO thread in the message loop to monitor. The read and write operations on these file descriptors are encapsulated in a channel object. Therefore, both the server side and client side have a corresponding channel object.

When the main thread of a process performs an operation that requires communication with another process, its main thread sends a message to the IO thread's message loop. When the IO thread processes this message, it is forwarded to the target process through the previously created UNIX socket. After the target process receives a message from its IO thread, it generally notifies the main thread of its main thread of the message loop to perform the corresponding operation. This means that within chromium, threads communicate through message loops, while processes communicate through a UNIX socket.

Let's first look at the communication between the browser process and the render process. The browser process creates a Renderprocesshost object each start of a render process. After the render process is started, a Renderprocess object is created to describe itself. In this way, communication between the browser process and the render process is carried out through the Renderprocesshost objects and Renderprocess objects described above.

Let's look at the communication between the browser process and the GPU process. The browser process creates a Gpuprocesshost object to describe the GPU process it starts, and a gpuprocess process is created after the GPU process is started. In this way, communication between the browser process and the GPU process is carried out through the Gpuprocesshost objects and Gpuprocess objects described above. Note that the channel between these two objects is used to perform signaling class communication. For example, the browser process can tell the GPU process to create another channel through the above channel, specifically to execute OpenGL commands. This channel, specifically used to execute OpenGL commands, is called the GPU channel.

We know that the GPU process needs to execute OpenGL commands for multiple processes simultaneously, and the OpenGL command is stateful, so the GPU process needs to create an OpenGL context for each client process, which is a Glcontext object. Before the GPU process executes the OpenGL command for a client process, it needs to locate the Glcontext object that was previously created for the client process and set the OpenGL context described by the Glcontext object to the current OpenGL context.

As mentioned earlier, the render process also needs to communicate with the GPU, which means that they also need to establish a pair of GPU Channel with the GPU process, just like the browser process. However, the render process cannot directly request the GPU process to create a pair of GPU Channel like the browser process. The render process first sends a request to the browser process to create a GPU channel, which is then forwarded to the GPU process after the browser process receives the request. When the GPU receives a request to create a GPU channel, a UNIX socket is created, the server-side file descriptor is encapsulated in a Gpuchannel object, and the client-side file descriptor is returned to the browser process. The browser process then returns to the render process so that the render process can create a client-side GPU channel. In addition to creating a client-side GPU Channel,render process also creates a Webgrahpicscontext3dcommandbufferimpl object that describes the OpenGL context of a client side, This OpenGL context corresponds to the OpenGL context described by the Glcontext object inside the GPU process.

Finally, let's look at the communication between the render process and the plugin process. Chromium supports two types of plug-ins, one is the Npapi plugin and the other is the Ppapi plugin. NPAPI plugin is a plug-in mechanism from Mozilla, which is supported by many browsers, and chromium is no exception. However, because the code running in the NPAPI plug-in cannot take advantage of the sandbox technology and other security techniques that take full advantage of chromium, the NPAPI plugin is now unsupported. So here we just focus on the PPAPI plug-in mechanism.

When the render process discovers the need to create a PPAPI plug-in when parsing a Web page, it notifies the browser process to create a plugin process. Of course, if the corresponding plugin process already exists, it will be used instead of starting one. Each browser process starts a plugin process, and a Ppapipluginprocesshost object is created to describe it. After the plugin process starts, a Childprocess object is also created to describe itself. In this way, the browser process and the plugin process can communicate through the channel between the Ppapipluginprocesshost object and the Childprocess object later on. However, the communication between the render process and the plugin requires a different channel. Therefore, the browser process further requests that the plugin process create another channel to communicate between the render process and the plugin process. With this channel, the render process creates a Hostdispatcher object, and the plugin process creates a Plugindispatcher object, The subsequent communication between the render process and the plugin process is done on both of these objects.

As mentioned earlier, the plugin process may also need to render the UI, so the PPAPI plug-in mechanism provides a GRAPHICS3D interface that the PPAPI plug-in can use to communicate with the GPU. Note that communication between the plugin process and the GPU process differs from the communication between the render process and the GPU process, which does not have a dedicated channel to perform IPC communication. However, the plugin process can use the channel previously established with the render process to communicate. This means that the communication between the plugin process and the GPU process is done indirectly through the render process. Specifically, the plugin process first sends the OpenGL command to the render process, which is then sent by the render process to the GPU process through the GPU channel.

During the chromium process, many IPC messages need to be sent between processes. Different types of IPC messages are handled by different modules. In order to be able to quickly distribute these IPC messages, Chromium provides a flexible set of message distribution mechanisms. This distribution mechanism specifies that each IPC message has a 32-bit routing ID and a 32-bit type, where the high 16 bits of type describe the IPC message category, and the low 16 bits have no special meaning.

Based on the class information of the IPC message, we can register a series of messagefilter in the IO thread, each of which can specify the IPC message categories that it supports. When an IO thread receives an IPC message, it first finds out whether the corresponding MessageFilter is registered according to its category. If any, it is quickly distributed to the IO thread to handle it.

In addition, we can also register a listener in an IO thread. When an IPC message does not have a corresponding messagefilter to handle, it is then distributed to the listener processing of the above registration. Note that this time the listener processing code runs in the thread that is registered. This thread is generally the main path. Listener is first distributed to the appropriate handler for processing based on the type of the IPC message. If no corresponding handler can be processed, and listener supports the registration router, the corresponding router is then distributed according to the routing ID of the IPC message for processing.

Finally, it is also important to note that in the Android platform, Chromium's browser process is the main process of the Android application, it has all the permissions of the Droid application request, the render process, The GPU process and the plugin process are service processes for Android applications. These service is configured in the Androidmanifest file to run in an orphaned process, that is, its Android:isolatedprocess property is set to true. When this process starts, it will not be given permission to apply to Android applications, which means that they are running in a very restricted process. This we can see by analyzing the process source code that the Android application process starts.

From the source code analysis of the previous Android application process startup process, you can know that the Android application process was started by Activitymanagerservice. Specifically, when you start a service, if you find that you need to create a separate process for it, you call the following member function of the Activitymanagerservice class startprocesslocked create a new process, as follows:

Public final class Activitymanagerservice extends Activitymanagernative        implements Watchdog.monitor, Batterystatsimpl.batterycallback {    ...    Private final void startprocesslocked (Processrecord app,            string hostingtype, String hostingnamestr) {        Startprocesslocked (app, Hostingtype, HOSTINGNAMESTR, NULL/* Abioverride */,                NULL/* entrypoint */, NULL/* entrypoint Args */);    }    ......}

This function is defined in the file Frameworks/base/services/core/java/com/adroid/server/am/activitymanagerservice.java.

The Activitymanagerservice class three parameter version of the member function startprocesslocked calls the other overloaded version of the member function startprocesslocked, which is implemented as follows:

Public final class Activitymanagerservice extends Activitymanagernative implements Watchdog.monitor, Batterystatsim Pl. Batterycallback {... private final void startprocesslocked (Processrecord app, String Hostingtype, STR            ing hostingnamestr, string abioverride, String entrypoint, string[] entrypointargs) {... try {            ... int[] Gids = null;                ... if (!app.isolated) {int[] permgids = null;                    try {... final packagemanager pm = Mcontext.getpackagemanager ();                    Permgids = Pm.getpackagegids (app.info.packageName); ......                }                catch (Packagemanager.namenotfoundexception e) {...}                ... if (permgids = = null) {Gids = new int[2]; } else {Gids = new Int[permgids.length + 2];                System.arraycopy (permgids, 0, Gids, 2, permgids.length);                } Gids[0] = Userhandle.getsharedappgid (Userhandle.getappid (UID));            GIDS[1] = Userhandle.getusergid (Userhandle.getuserid (UID));            }            ...... Process.processstartresult Startresult = Process.Start (entrypoint, App.processname, UID, uid, Gids, Deb                    Ugflags, Mountexternal, App.info.targetSdkVersion, App.info.seinfo, Requiredabi, Instructionset,            App.info.dataDir, Entrypointargs); ......        }    catch (RuntimeException e) {...} }    ......}

This function is defined in the file Frameworks/base/services/core/java/com/adroid/server/am/activitymanagerservice.java.

As you can see from here, only if the parameter app describes a Processrecord object that has a member variable isolated equal to False. The member function of the Activitymanagerservice class startprocesslocked requests Packagemanagerservice to return the permissions that are requested by the Android application to which the service is to be started. A series of GID. And when a service sets the property Android:isolatedprocess property to True in Androidmanifest.xml, The parameter app here describes the Processrecord object's member variable isolated also equals true, which is equivalent to not giving any permissions to the process that the service is running on, so it runs in a sandbox.

We'll introduce you to the multi-process architecture of chromium. In the following series of articles, we then combine the source code to detail its implementation details. Specifically, it includes the following scenario analysis:

1. The START process analysis of the render process;

2. Analysis of the IPC message distribution mechanism;

3. GPU process Start-up process analysis;

4. Analysis of the initiation process of the plugin process;

Here we deliberately skip the browser process analysis, because the browser process is actually an Android application process, but involves some chromium related library loading process, And some chromium related libraries are preloaded by the zygote process, and when we analyze the WebView startup process later, we analyze the boot process of the browser process in detail.

At the same time, after analyzing the start-up process of the render process, we did not immediately analyze the startup process of the GPU process, but first analyzed the specific implementation of the IPC message distribution mechanism described earlier, because after understanding the start process of the render process, We can get a better understanding of Chromimum's IPC message distribution mechanism with the communication process between it and the browser process.

After analyzing the above four scenarios, we also have an important task of analyzing how the render process and the plugin process are hardware-accelerated rendering UI through the GPU process. Hardware accelerated rendering is a necessary condition for a smart device to get a smooth UI. It can be said that there is no hardware accelerated rendering support, the device UI animation to reach 60fps, is very difficult. Chromium uses hardware-accelerated rendering in a very unique way, with the following features:

1. The render process and the plugin process invoke the OpenGL API, but these APIs are just a proxy interface, which means that these API calls simply send the corresponding commands to the GPU process for processing.

2. Some OpenGL APIs, such as Glbuffersubdata, need to send the data associated with the command to the GPU process in addition to sending the corresponding command to the GPU process. These data are often very large, which involves how to transfer them to the GPU process correctly and efficiently.

3. The GPU process has only one thread that handles the OpenGL commands sent by the client, but the thread is serving multiple clients at the same time, which is to serve both the render process, the plugin process, and the browser process. Each client side is equivalent to having an OpenGL context, which will involve scheduling problems for each OpenGL context.

4. The GPU process serves multiple client side at the same time, they are not isolated from each other, they sometimes have some relevance. For example, the render process renders a good off-screen UI that needs to be handed over to the browser process for compositing so that it can eventually be displayed on the screen. That is, the browser process needs to wait for the render process to complete before it can be synthesized, otherwise it will get an incomplete UI. For the GPU process, the question involved is how to synchronize in two different openggl contexts.

For these features mentioned above, after the completion of chromium multi-process architecture analysis, we then through another series of articles for detailed analysis, please pay attention! More information, you can also pay attention to the old Luo Sina Weibo: Http://weibo.com/shengyangluo.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Chromium multi-process architecture brief introduction and Learning Plan