Concepts de base d'Electron

Electron est essentiellement un framework d'application de bureau multi-processus qui combineChromium (couche de rendu)etNode.js (couche système)et, grâce à un modèle de processus indépendant, permet l'affichage de l'interface utilisateur, le contrôle de la logique et une communication sécurisée.

Voici l'architecture de base d'Electron, montrant la relation entre le processus principal, le processus de rendu, la communication IPC et Preload.

Processus principal (A) :

• S'exécute sur Node.js, contrôle les fenêtres et interagit avec le système.
• Utilisez BrowserWindow pour créer le processus de rendu.

Processus de rendu (B) :

• Chaque fenêtre exécute indépendamment HTML/CSS/JS pour afficher l'interface.

Script de préchargement (B2) :

• S'exécute avant le chargement du processus de rendu, en connectant le processus principal et la couche de page web.
• Exposer des API de manière sécurisée via contextBridge.

Communication IPC (flèches en pointillés) :

• Le processus principal et le processus de rendu communiquent de manière bidirectionnelle via ipcMain et ipcRenderer.

Système d'exploitation (C) :

• Le processus principal peut accéder aux fonctionnalités du système, telles que les fichiers, la barre d'état, les notifications, etc.

Processus principal

Le processus principal est le « centre de commande » de l'application Electron, s'exécutant dans un environnement Node.js.
Il est responsable de la création des fenêtres, de la gestion du cycle de vie de l'application, de l'appel des API système et de la communication avec le processus de rendu.
Après le démarrage de l'application, le système exécute d'abord le script du processus principal (généralementmain.js）。

Responsabilités du processus principal

• Lancement et fermeture de l'application
• Création et destruction de BrowserWindow (fenêtres)
• Enregistrement des menus, de la zone de notification, des raccourcis globaux
• Appel des fonctions du système d'exploitation (système de fichiers, notifications, boîtes de dialogue)
• Écoute des événements envoyés par le processus de rendu

Cycle de vie du processus principal

Le cycle de vie du processus principal correspond au cycle de vie de l'application, à partir deappDémarrage du module :

• app.whenReady(): Déclenché après la fin de l'initialisation d'Electron.
• window-all-closed: Déclenché lorsque toutes les fenêtres sont fermées.
• app.quit(): Quitte toute l'application.
• Cas particulier courant sur macOS : lorsque l'utilisateur ferme toutes les fenêtres, le programme continue de s'exécuter en arrière-plan.

Module app en détail

appModule utilisé pour contrôler l'ensemble du cycle de vie de l'application :

• app.on('ready'): Déclenché lorsque l'initialisation d'Electron est terminée.
• app.quit(): Quitter l'application.
• app.getPath('userData'): Obtenir les chemins système.
• app.setAppUserModelId(id): Définir l'ID de la barre des tâches Windows.
• app.isPackaged: Déterminer si la version actuelle est empaquetée.

Gestion des fenêtres BrowserWindow

Processus principal viaBrowserWindowCréer une fenêtre visible :

• width, height: Taille de la fenêtre
• resizable: Indique si elle peut être redimensionnée

• webPreferences: Utilisé pour configurer le comportement du processus de rendu

  • preload: Script de préchargement
  • nodeIntegration: Indique s'il faut autoriser le processus de rendu à utiliser Node.js

Fonctionnalités natives telles que les menus, la zone de notification, les boîtes de dialogue, etc.

Electron fournit plusieurs modules pour accéder aux fonctions système :

• Menu / MenuItem: Barre de menus personnalisée
• Tray: Créer une icône de zone de notification
• Dialog: Invoquer le sélecteur de fichiers du système, la boîte de dialogue d'alerte
• Notification: Notifications natives

• shell: Ouvrir des liens ou fichiers externes, par exemple :

  const { dialog } = require('electron');
  dialog.showOpenDialog({ properties: ['openFile', 'multiSelections'] });

Processus de rendu

Le processus de rendu est responsable de l'affichage de l'interface et s'exécute dans un environnement Chromium.
chaqueBrowserWindowChacun dispose d'un processus de rendu indépendant.

Caractéristiques du processus de rendu

• Basé sur Chromium, exécute HTML/CSS/JS
• Par défautImpossible d'accéder directement aux API Node.js(Pour des raisons de sécurité)
• Peut utiliser des piles technologiques web : Vue, React, Svelte, etc.
• Chaque fenêtre correspond à un thread indépendant, et elles ne s'affectent pas mutuellement.

Fenêtres multiples et processus de rendu multiples

Chaque fenêtre Electron (BrowserWindow) démarrera un processus de rendu indépendant :
La fermeture d'une fenêtre n'affecte pas les autres fenêtres, comme dans le modèle multi-onglets d'un navigateur.
Cela rend l'application plus sûre et plus fiable lors de la récupération après un plantage.

Chargement et affichage de pages Web

Le contenu du processus de rendu est chargé par le processus principal :

win.loadFile('index.html');    // 加载本地页面
// 或者
win.loadURL('https://example.com'); // 加载远程网页

Limitations dans le processus de rendu

• Pour des raisons de sécurité, les modules Node.js ne peuvent pas être utilisés directement (tels quefs、path）。
• Il n'est pas recommandé d'effectuer des calculs lourds dans le processus de rendu (cela gèlera l'interface utilisateur).
• L'interaction avec le système nécessite une communication IPC ou des API exposées via preload.

Communication inter-processus (IPC)

L'un des mécanismes essentiels d'Electron estla communication entre le processus principal et le processus de rendu, appeléeIPC（communication inter-processus）。

ipcMain et ipcRenderer

• ipcMain: Utilisé dans le processus principal pour recevoir des messages.
• ipcRenderer: Utilisé dans le processus de rendu pour envoyer des messages.

Exemple de communication unidirectionnelle :

Exemple de communication bidirectionnelle (le processus principal renvoie des données) :

ipcMain.on('getVersion', (event) => {
  event.reply('getVersionResponse', app.getVersion());
});

Le côté renderer reçoit :

ipcRenderer.on('getVersionResponse', (event, version) => {
  console.log(version);
});

modèle invoke/handle (approche recommandée)

Electron fournit un moyen plus concis pour les requêtes asynchrones :

Processus principal :

ipcMain.handle('get-app-path', () => app.getPath('userData'));

Processus de rendu :

const result = await ipcRenderer.invoke('get-app-path');
console.log(result);

Cette approche est similaire àfetchRequêtes, évitant plusieurs couches de callbacks.

Bonnes pratiques pour le passage de messages

• UtilisationNom de canal explicite(comme"user:getData"）。
• Évitez de passer des objets complexes (JSON est recommandé).
• Les données provenant du processus de rendu doivent être validées en termes de source et de type.
• Essayez d'utiliserinvoke/handleImplémentez une communication structurée.

Scripts de préchargement (Preload Scripts)

Le script de préchargement s'exécute avant la création du processus de rendu, entre le processus principal et la page web.
Son rôle est de « relier » en toute sécurité les fonctionnalités Node.js à la page de rendu.

Le rôle et l'importance de preload

• Peut accéder aux API Node.js (en raison du contexte isolé)
• Peut exposer en toute sécurité un petit nombre d'API à la page de rendu
• Couramment utilisé pour la lecture/écriture de fichiers, la récupération de chemins système, la transmission d'informations d'application, etc.

// preload.js
const { contextBridge, ipcRenderer } = require('electron');

contextBridge.exposeInMainWorld('electronAPI', {
  getAppVersion: () => ipcRenderer.invoke('getVersion')
});

Le processus de rendu utilise :

// index.html
<script>
  window.electronAPI.getAppVersion().then(v => {
    console.log('App version:', v);
  });
</script>

Communication sécurisée contextBridge

contextBridgeest une API sécurisée fournie par Electron, utilisée pour :

• N'exposer que les fonctions requises (mécanisme de liste blanche)
• Empêcher les pages web malveillantes d'accéder à l'environnement Node.js
• DanscontextIsolation: truePeut toujours communiquer de manière sécurisée dans le

Utilisation en mode sandbox

Si le sandbox est activé (sandbox: truele renderer ne peut pas du tout utiliser Node.js.
À ce stade, preload est le seul pont, responsable de :

• Recevoir les appels côté renderer
• Transmettre au processus principal via IPC
• Renvoyer les résultats à la page web

Résumé

Compréhension en une phrase :
Le processus principal est comme la « salle de contrôle », le processus de rendu est comme « le personnel de chaque fenêtre »,
IPC est le "talkie-walkie", et Preload est le "canal sécurisé filtré".