As the environment of front-end code running, as well as the bottom knowledge of front-end engineers, the browser is familiar with its structure and working mode, both for the development of high-performance Web applications, and for the establishment of a perfect front-end knowledge framework, all play a crucial role.

Processes and threads

Process is the basic unit of operating system resource allocation and scheduling, thread is the smallest unit of operating system operation.

A program has at least one process, and a process has at least one thread. Threads need to be started and managed by processes.

Typically, programs need to perform multiple tasks. For example, a browser needs to render a page while requesting back-end data and responding to user events. A single-threaded process can only perform one task at a time and cannot meet the requirements of multiple tasks executed in parallel. There are three ways to solve this problem:

  • Multiple processes
  • Multithreading (same process)
  • Multiprocess and multithreading

Since the third method is a combination of the first two methods, only multi-process and multi-threaded features are discussed here.

The previous mention that processes are the basic unit of resource allocation in the operating system implies that resources between different processes are exclusive and cannot be accessed by each other. One of the biggest benefits of this feature is that it creates isolation between processes, avoiding the problem of multiple processes working on the same data at the same time.

While multithreading does not allocate independent resources, data is shared between threads, which means that the cost of creating a thread is lower, since no additional storage needs to be allocated. However, data sharing among threads also brings a number of problems. The first is stability. The crash of any thread in the process can cause the entire process to crash, which means that other threads in the process can be “implicated”. The security implications are easier to understand if a malicious thread starts and can access any resource in the process at will.

All in all, multi-threading is lighter, multi-processing is safer and more stable.

Now that you know about processes and threads, let’s take Chrome as an example of what processes and threads are used in the browser.

Browser architecture (multi-process + Multi-thread)

As you can see from the browser’s task manager, the following processes are started when the browser hits.

Browser process

The main process of the browser is responsible for interface display (address bar, navigation bar, bookmarks, etc.), user events processing, management of child processes, etc.

GPU process

Handle GPU tasks from other processes, such as CSS3 animation effects from renderer or extender processes, interface drawing from browser processes, etc.

During the browser rendering process, the layer composition operation in the last step “draw” is actually handed over to the GPU process.

Another important feature is the ability to accelerate rendering using GPU hardware, including Canvas drawing, CSS3 Transitions, CSS3 Transforms, WebGL, and more. The idea is that if a DOM element uses these attributes, the GPU process will process it separately when composing layers, and then elevate it to a separate layer for drawing, thus avoiding relayouts and redrawing.

The following code uses KeyFrames to animate a motion around a square.

<div class="gpu"></div>
<style>
  .gpu {
	background-color: darkgreen;
	width: 50px;
	height: 50px;
	transform: translate(0.0);
	animation: slide 3.7 s ease-in-out infinite;
}

@keyframes slide {
	25% {
		transform: translate(250px.0);
	}

	50% {
		transform: translate(250px.250px);
	}

	75% {
		transform: translate(0.250px); }}</style>
Copy the code

Use the browser performance analysis tool to record the entire page drawing process. After the page is drawn, the browser does not perform any operations related to layout or drawing. Therefore, the rendering of elements has been removed from the rendering engine and maintained by the GPU process.

For comparison purposes, we’ll modify the code a little bit, changing the element position by fixing the position.

<div class="gpu"></div>
<style>
  .cpu {
	background-color: darkgreen;
	width: 50px;
	height: 50px;
	left: 0;
	top: 0;
	position: fixed;
	animation: move 3.7 s ease-in-out infinite;
}

@keyframes move {
	25% {
		left: 250px;
		top: 0;
	}

	50% {
		left: 250px;
		top: 250px;
	}

	75% {
		left: 0;
		top: 250px; }}</style>
Copy the code

You can see the page layout and draw in a loop.

Network Service process

Load web resources for the page, such as entering a web address in the address bar, and the web process will send the requested resources to the renderer process. Originally just a module of the browser’s main process, it has been sipped off as a separate process in order to “servize” the browser process.

V8 proxy parsing tool process

Chrome supports the use of JavaScript to write scripts to connect to proxy servers, called PAC proxy scripts.

Since PAC proxy scripts are written in JavaScript, to be able to parse pac proxy scripts requires the use of a JavaScript script engine. Introducing a JavaScript engine directly into the browser’s main process is not consistent with the process “servitization” design philosophy. Therefore, this parsing function is separated into a process.

Rendering process

The browser starts a separate rendering process for each TAB, so it’s not unique.

The renderer process, whose job is to turn HTML, CSS, and JavaScript into a web page that the user can interact with, starts a separate render engine thread and a JavaScript engine thread.

There are also event-triggering threads, which receive events and put callback functions into the event queue of the JavaScript engine thread, and timer threads, which handle timed tasks.

This design ensures the security of the program and the system. It can establish a sandbox running environment for each rendering process through the permission mechanism provided by the operating system, so as to prevent malicious damage to the user system or affect the behavior of other tabs.

It also keeps the rendering process stable, because if a TAB becomes unresponsive, the user can close it while the rest of the tabs are still running and ready to use. If all tabs are running on the same process, then when one becomes unresponsive, all tabs become unresponsive.

Extender process

It is responsible for running the plugin, and like the renderer process, it is not unique. The browser starts a process for each plugin. This design is also from the safety and stability considerations.

Servitization of processes

In 2016, the Chrome team proposed a service-oriented design model, in which the various modules of the browser’s main process are split into separate services as system resources allow, and each service runs in a separate process. Chrome is more stable and secure with its highly cohesive, low-coupling structure.

It also scales, aggregating these services into the main browser process when running on resource-limited devices, thereby reducing memory footprint.

conclusion

By analyzing the architecture of Chrome, we can get the following three inspirations

  1. Multiple processes have advantages in stability and security, but occupy more resources
  2. For complex applications, we can adopt a servitization design approach, separating functional modules into separate processes to provide services
  3. Proper use of THE GPU process can speed up rendering

— Public account “Grace front” —

For every aspiring “front-end ER” to lead the way, build dream aspirations.

Just to be an excellent front end Engineer!