I. Introduction
Most of the mainstream browsers at home and abroad use Google's Chromium browser kernel. Chromium is a web engine with a multi-process and multi-thread architecture. Many applications and underlying developers want to understand the types and uses of processes and threads in Chromium, so as to The relevant information can be used to improve the performance of the application. To this end, this article introduces the evolution history of Chromium's multi-process architecture, lists in detail the common processes and threads of Chromium, and explains their uses in detail. I hope this article can help readers get a preliminary understanding of what common processes and threads Chromium has, and explain their uses in detail. I hope this article can help readers get a preliminary understanding of the processes and threads of Chromium/Webview runtime.
2. Evolution history of Chromium process architecture
single process architecture
Before 2007, browsers on the market basically had a single-process architecture, and all functional modules ran in the same process. The architecture of a single process has the following problems:
1. Stability
In a single-process browser, a problem with any module will cause the entire browser to crash. In particular, many functions of early browsers need to be implemented through plug-ins, and plug-ins implemented by third parties are particularly prone to problems. Similarly, JavaScript code that is too complex or has low performance can easily cause the JavaScript engine to crash, thereby causing the entire browser to crash.
2. Performance
Since all web pages run in one process, the JavaScript code of a certain web page runs slowly or has an infinite loop, which will cause the entire browser to freeze or become unresponsive. And due to possible memory leaks in the rendering engine, long-running browsers will take up more and more memory.
3. Security
All components in a single-process architecture browser run in one process, and it is difficult to achieve a reasonable security environment. Plug-ins and JavaScript scripts can exploit vulnerabilities to obtain system resource permissions, causing many security issues.
3. Multi-process architecture
In 2008, Chromium (Chromium is the open source implementation of Chrome, the main code of the two is the same, Chrome has some Google's private components compared to Chromium. There is no special explanation in the follow-up, Chromium is equivalent to Chrome) released the multi-process as shown above architecture. The difference from the single-process architecture is that the Renderer and Plugin processes are independent. Different processes need to communicate through IPC. The Renderer process is the rendering engine, which is mainly responsible for page rendering, including HTML parsing, rendering, and JavaScript execution.
This architecture effectively solves the three major problems of the single-process architecture:
1. Stability
Processes are isolated. The component crash of a single page only affects the Renderer process where it is located, and will not cause the entire browser to crash, which effectively solves the stability problem.
2. Performance
Each tab of the browser runs in an independent Renderer process. JavaScript scripts with an infinite loop only affect the current tab, and other pages can still run normally. Moreover, the memory leak of the rendering engine only affects a single process. Closing the Renderer that uses too much memory can release the memory and will not affect the use of other web pages.
3. Security
The multi-process architecture also introduces the Sandbox sandbox mechanism, where the Renderer process and the plug-in process run in the sandbox. These processes cannot obtain system resources, and access to resources needs to be executed by the Browser process through IPC. Malicious scripts cannot break through the restrictions of the sandbox and affect system security.
After years of development, more and more functions of Chromium have been separated into independent processes, such as GPU processes and network processes. Although multi-process solves stability, performance, and security issues. However, too many processes also have problems such as excessive memory usage and increased system architecture complexity caused by inter-process communication. In order to solve these problems, Chromium proposed a high-cohesion, low-coupling, and easy-to-extend architecture based on SOA (Services Oriented Architecture) in 2016. The architecture expects to split or aggregate functional components in the form of services, which can run in independent processes or be combined into a single process. On high-end devices, services may run in separate processes to enhance stability and performance. On low-end devices, multiple services can be merged into a single process to save memory usage.
Four, Chromium process and thread
process
Chromium's process model supports one or more processes. Common configurations include Browser process, Renderer process, GPU process, network process and multiple service processes. It can be configured as a dual process (Browser process, Renderer process) or a single process (Browser process) on devices with fewer resources. It should be noted that the code of single-process mode has not been tested and verified by Chromium officially. If this mode is to be used in products, more work is required to maintain the stability of single-process. All possible process and thread names of Chromium can be viewed in the chrome_string_lookup.cc file. The following figure shows the processes visible when two tabs are opened on Windows:
1. Browser/UI process
The main process of the web engine has permission to access system resources. On Windows, it is displayed as a browser process, and on Android, it is usually an App process. Because the main process is usually responsible for interacting with the window system, it is sometimes called the UI process. In the early days, the main process was responsible for UI interaction, persistent data access, and network resource download. For persistent data access in the latest Chromium, network resources already exist as independent processes.
2. Renderer process
Rendering process, which is responsible for page rendering and JavaScript script execution. Depending on the configuration, there can be multiple Renderer processes. Simply put, each opened webpage may create a renderer process, but in the case of less resources, you can configure webpages with the same domain to share one process, or even only one renderer process.
The Renderer process runs in Sandbox. This process does not have permission to access system resources. All resource access requirements are delegated to other functional processes, such as network processes and GPU processes, through IPC.
3. GPU process
The process that executes the GPU command, that is, the process that actually calls the opengl es interface. The Renderer process cannot access the GPU, and its operations on the GPU need to be delegated to the GPU process through CommandBuffer. It can be configured not to use an independent GPU process. At this time, the process degenerates into a thread running in the main process.
4. Network Service process
The process of executing resource loading, through which document resources are downloaded and sent to the Renderer process for analysis through Share Memory. The same process can be configured as a thread in the main process.
5.Storage Service process
Provide storage services for local/session storage, service worker, indexed_db.
6. Data Decoder Service process
The decoding process executes the decoding of image, zip and other files.
7. Audio Service process
Audio process, process audio files.
8. Zygote process
The function is the same as Android's zygote, which is used to accelerate the creation of the Renderer process.
Five, thread
Chromium's architecture design maximizes the use of modern processing multi-core architecture. There are many threads in each process, and each thread is responsible for specific task execution. Common threads of Chromium are as follows:
1. Thread pool-related threads, threads that exist in each process, and multiple ThreadPool threads with the same name can be seen in the process.
2. IO-related threads are responsible for file access and inter-process communication. The IO thread of the Browser process is Chrome_IOThread, and the IO thread of other processes is Chrome_ChildIOThread.
3. Threads in the Browser process
4. Threads in the Renderer process
5. Threads in the GPU process
6. The process of Android Webview
Android system Webivew is a Webivew component provided by Google for Android. The Android system Webivew is based on the Chromium code (after version 4.4). Due to the hardware differences of the embedded platform, the process configuration of the Android system Webivew is different from that of Chromium on the PC.
Seven, Android system Webview process
The process architecture of Android system Webivew follows the architecture of Chromium. But due to platform limitations, on Android L, M, and N, Webivew is in single-process mode. On Android O and later devices, Webivew is in multi-process mode. In order to save memory, Webivew in multi-process mode only has Browser and Renderer processes. Both GPU and network services run in the Browser process as threads, and there is only one renderer process.
In Android N, Webivew can obtain process mode through global configuration. You can also set the multi-process mode through the developer menu (the manufacturer's developer menu does not necessarily have this option).
For Android O and later versions, Webivew defaults to multi-process mode, which cannot be modified by users. Although there are still codes related to process configuration in the code of the framework, the App cannot be configured through the Webivew interface or manifest.
Eight, three-party Webview
Large domestic manufacturers usually develop customized Webviews based on the Chromium engine according to their own needs, and the process configuration is different from that of Android system Webviews. Developers can judge which sub-process of Chromium the process belongs to by the key thread name in each sub-process of the App. For example, the process with the CrRendererMain thread is usually the renderer process.
The following are the processes in some common applications. Customized Webviews usually use GPU processes to improve performance.
Nine. Summary
Chromium's process architecture has evolved into a service-oriented multi-process architecture. With the development of hardware devices, there may be more service processes in the future to make full use of hardware resources. For resource-constrained devices, Chromium's process architecture can also be easily configured to reduce resource usage. Web engine developers can adjust process configurations according to actual scenarios, and application and underlying developers can also choose application or kernel optimization strategies based on actual process configurations.
references
1.https://ithelp.ithome.com.tw/articles/10270187
2.https://www.chromium.org/developers/design-documents/multi-process-architecture
3.https://keyou.github.io/blog/2020/01/03/Chromium-Mojo&IPC
4.https://www.chromium.org/developers/design-documents/inter-process-communication/
5.https://chromium.googlesource.com/chromium/src.git/+/51.0.2704.48/docs/mojo_in_chromium.md
6.https://chromium.googlesource.com/chromium/src/+/HEAD/android_webview/docs/architecture.md
7.https://chromium.googlesource.com/chromium/src/+/HEAD/android_webview/renderer/README.md
Long press to follow Kernel Craftsman WeChat
Linux Kernel Black Technology | Technical Articles | Featured Tutorials