This article focuses on the main and renderer concepts mentioned in the previous chapter, and how they are used

If you have any questions or jokes about the content of this article, please comment directly below, and we can learn and improve together

Reading time: about 4 minutes

Main process and renderer process

Let’s review the basic directory structure given in the program directory Structure section

App -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- the application code directory ├ ─ main. Js -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- the program start entrance, Main process ├ ─ common -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- general module ├ ─ log -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - log module ├ ─ config -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- the configuration module ├ ─ the ipc -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- process module between ├ ─ appNetwork -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- application communication module └ ─ browserWindows -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- window management, Rendering process ├ ─ components -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- a common component module ├ ─ store -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- data sharing module ├ ─ the statics -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- static resource module └ ─ SRC -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- window business module ├ ─ window A -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- window └ ─ window B -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - the windowCopy the code

In the directory structure above, main.js is what we call the main process. A process created from a window file in the browserWindows directory is called a renderer. Renderers need to be created and managed by the main process. Now you might be wondering, what is a process? Why separate the main process from the renderer?

Concept of process

There is a lot of knowledge about computer processes that can be found in search engines, and we won’t go into that here. Readers can think of processes as the basic unit of operating system management applications, and resources between each process are not directly shared. Open the task manager for the operating system and you can see which processes are present on the current operating system, as shown below

The main process

Looking back at web development, our code, whether HTML, CSS, or Javascript, runs in the browser’s sandbox. We can’t access the system’s own resources beyond the browser’s permissions. The power of the code is limited in the browser. Browsers do this for security reasons. Imagine opening websites from a variety of different sources while using a browser, and how scary it would be if JavaScript code had the ability to access and manipulate the resources of your local operating system. If you accidentally open a malicious website one day, your files may be stolen from your hard drive (no need to repair your computer).

But we’re developing a desktop application, and you can’t do it if you don’t have access to local resources. Electron incorporates NodeJS into the process, making Nodejs the program’s steward. The butler has a high level of access to and manipulation of local resources, using advanced apis that are not originally available in the browser. The butler also manages the creation and destruction of renderer Windows. So, we call this steward the master process. In a program developed using Electron, main.js is used as the main entry point of the program. What the code executes in this file is what is executed in the main process.

Let’s take a look at what is typically done in the main process.

//main.js

var electron      = require('electron');
var app           = require('electron').app;

/ / initialization
app.on('ready'.function(){

    try{      
        //app ready
    }catch(err){ log.error(err); }});Copy the code

Here is the simplest main.js example. In our example, we first introduce the electron and electron.app modules. The electron. App object controls the entire life cycle of the program. Here we only register the ready event in the life cycle.

In a real-world application, the main process code would be far more complex than the above example. Many of the required features are implemented in the main process, as shown in the following example.

Process mutex

In some scenarios, applications are required to have only one running on the system at a time. So when something should already be running in the system, if you double-click the application icon again, the application should return itself, or the previously opened application.

(function(){

  app.makeSingleInstance(singleInstanceCallBack);

  function singleInstanceCallBack(commandLine, workingDirectory){

    console.log('command line: ', commandLine);
    console.log('working directory: ', workingDirectory);

    app.exit(0);        
  }
})();

Copy the code

Here are using the app. MakeSingleInstanceapi implement this function. The singleInstanceCallBack function is a callback that the first instance executes when the second instance is started, so the app used in singleInstanceCallBack actually points to the instance that was opened first. In the above code, When singleInstanceCallBack is executed, the app.exit method is called to exit the previously opened program. So how do we know that this is the second instance? MakeSingleInstance returns a Boolean value; a value of true indicates that the instance is a second instance. If the need is for the second instance to exit, call app.exit directly in the current scope.

Rendering process

Electron integrates Chromium to display the window interface, and the content seen in the window is rendered in HTML. Chromium itself is a multi-process rendering architecture (by default, Chromium’s default policy is to start a new process for each TAB to ensure that each page is independent and non-intrusive. Avoid the crash of one page and render all pages unusable), so Electron will also use Chromium’s multi-process architecture when displaying the window. This multi-process rendering architecture is called the render process in Electron.

In Electron, each time a new window is created, it is a separate process.

//main.js
const {BrowserWindow} = require('electron');
const window1 = new BrowserWindow({width: 200.height: 200})
const window2 = new BrowserWindow({width: 200.height: 200})

window1.loadURL('https://baidu.com');
window2.loadURL(`file://${__dirname}/index.html`)

Copy the code

In the code above, we created two Windows, Window1 and Window2. These two Windows are independent processes. Window1 window content points to baidu home page, Window2 window content points to our own development of HTML pages. In index.html, you can develop window content just as you would a normal Web page. Here is an example of index.html


      
<html lang="zh-cn">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1,user-scalable=0">
    <title>main page</title>
</head>
<body>
    <div id="app">Hello World</div>
    <script type="text/javascript" src="mainPage.js"></script>
</body>
</html>
Copy the code

In the main process section, we stated that only the main process has access to local resources. In actual scenarios, sometimes the local data obtained in the main process needs to be displayed in the window. How to achieve this?

In the next chapter, we’ll focus on how the main process communicates with the renderer.