Electron cross-end principle
In the design of a cross-end framework, there are three issues to consider, namely UI rendering, native API and client-side construction methods. How does Electron solve the above problems?
Electron's cross-end principle is not difficult to understand: it integrates the browser kernel, uses front-end technology to achieve rendering under different platforms, and combines Chromium, Node.js and API for calling system local functions.
Chromium provides Electron with powerful UI rendering capabilities. Since Chromium itself is cross-platform, there is no need to consider code compatibility. Most importantly, Electron development can be done using the front-end three-axes.
Chromium does not have the ability to operate native GUI, so Electron integrates Node.js internally, and can also call the underlying API of the operating system while writing the UI, such as path, fs, crypto and other modules.
Native API provides Electron with native system GUI support, through which Electron can call native application program interfaces.
To sum up, Chromium is responsible for page UI rendering, Node.js is responsible for business logic, and Native API provides native capabilities and cross-platform.
The above briefly explains Electron's cross-end principle, let's take a closer look.
Chromium's multi-process mode is mainly composed of three parts: browser side (Browser), renderer side (Render), browser and renderer communication (IPC)
1. The browser process
There is only one browser process Browser, and when Chrome is opened, the process starts. The browser maintains the corresponding RenderProcessHost for each rendering process, which is responsible for the interaction between the browser and the renderer. RenderViewHost interacts with the RenderView object to render the content of the web page. The browser communicates with the renderer via IPC.
2. Rendering process management
Each renderer process has a global RenderProcess object that manages its communication with the parent browser process and maintains its global state.
Each renderer can maintain multiple RenderView objects. When a new tab or pop-up window is opened, the rendering process will create a RenderView. The RenderView object communicates with its corresponding RenderViewHost in the browser process and the Webkit embedded layer to render the web page. Web page content (this is where our main focus is on a day-to-day basis).
Electron Architecture Analysis
The Electron architecture refers to Chromium's multi-process architecture mode, which isolates the main process from the rendering process, and makes certain extensions based on Chromium's multi-process architecture.
Simplify the complex Chromium architecture above:
The Chromium runtime consists of a Browser Process and one or more Renderer Processes. Renderer Process is responsible for rendering page Web, Browser Process is responsible for managing each Renderer Process and other functions (menu bar, favorites, etc.)
Let's take a look at what changes have been made to the Electron architecture?
Compared with the Chromium architecture, Electron has made a lot of changes to the Browser thread and renamed it Main Process. Each application can only have one main thread. The main thread runs under Node.js, so it can call the underlying functions of the system. It is mainly responsible for: the creation of the rendering process; the invocation of the underlying system functions and native resources; the control of the application life cycle (package startup, launch, and some event monitoring)
After the above analysis, the system architecture of Electron multi-process can be summarized as the following figure:
It can be found that both the main thread and the rendering thread integrate Native API and Node.js, and the rendering thread also integrates the Chromium kernel to successfully achieve cross-end development.
Node and Chromium
Node's event loop is significantly different from the browser's event loop. Since Chromium is an experimental version of Chrome, it is naturally the same as the browser's implementation.
Node's event loop is implemented based on libuv, while Chromium's implementation is based on message bump. The main thread can only run one event loop at a time, so two completely different event loops need to be integrated.
There are two solutions:
Integrating Chromium into Node.js with libuv for message bump
Integrate Node.js into Chromium
Electron's original solution is the first one, which uses libuv to achieve message bump, but the GUI event loops of different OS systems are very different, such as NSRunLoop for mac and glib for Linux. The implementation process is particularly complicated, and the resource consumption and delay problems cannot be effectively solved. Solved, and finally gave up the first solution.
Electron's second attempt to use a small interval timer to poll the GUI event loop, but this solution has high CPU usage and slow GUI responsiveness.
Later, libuv introduced the concept of backend_fd. Backend_fd polls the file descriptor of the event loop. Therefore, Electron obtains new events from libuv by polling backend_fd to realize the fusion of Node.js and Chromium event loop (the second solution).
The following PPT perfectly describes the above process (Source: Electron: The Event Loop Tightrope - Shelley Vohr | JSHeroes 2019)
Cross-platform technology in action! Baidu Wenku's cross-platform technology quickly implements the whole process
Electron Internals: Message Loop Integration
Electron development actual combat documentation
I am Battlefield Xiaobao, a small front-end that is growing rapidly, and I hope to make progress with everyone.
If you like Xiaobao, you can follow me at Nuggets, and you can also pay attention to my small public account - the front end of Xiaobao Learning.
Go all the way to the future!!!
The epidemic will end soon and the world will return to peace
Knowledge Base Team
Knowledge Base Team
Knowledge Base Team
Knowledge Base Team
Explore More Special Offers
50,000 email package starts as low as USD 1.99, 120 short messages start at only USD 1.00