Distinction entre le moteur de rendu et les processus principaux dans Electron
À l'origine, je pensais que le processus de rendu dans Electron était mis en bac à sable dans un environnement de type chrome, ce qui signifie que tout ce que vous pouvez faire est de jouer avec le DOM. Cependant, j'ai récemment appris que vous pouvez accéder au système de fichiers, exécuter des processus enfants et obtenir leur sortie, et importer tout autre module de nœud que vous souhaitez.
Si tel est le cas, quelle est exactement la distinction entre le processus principal et le processus de rendu? N'est-ce pas une séparation difficile? Quel type de code va dans le processus principal et quel type de code va dans le processus de rendu?
Si quelqu'un a une bonne lecture/présentation approfondie de l'architecture de l'application Electron, j'aimerais aussi y regarder; pourrait aider à dissiper une partie de la confusion
La distinction processus principal/moteur de rendu n'est pas en fait un concept Electron en soi - il est hérité de Chromium (voici un article sur l'architecture de Chromium et le raisonnement derrière elle). Il s'agit de l'architecture que Chrome utilise pour des raisons de performances et de stabilité. Chaque instance de webContents s'exécute dans son propre processus (un processus de "rendu"). Le processus principal (il ne peut y en avoir qu'un seul) gère entre autres les instances de webContents.
Il y a bonne discussion ici sur les différences entre les deux.
Certaines API ne sont disponibles que dans un processus ou dans l'autre, ce qui peut vous aider à savoir quelle logique va où. Par exemple, les notifications (utilise l'interface HTML5 mais sont implémentées en tant que notifications natives) ne peuvent être créées qu'à partir d'un processus de rendu. La classe Men ne peut être appelée que depuis le processus principal. Lisez les documents API des modules Electron et voyez ce qui se passe où. Vous pouvez utiliser IPC , remote module, ou electron-remote pour coordonner les deux processus ( lequel vous utilisez dépend de votre cas d'utilisation).
Je dirais que c'est une séparation "dure". Ce sont tous des processus distincts et ne partagent donc aucune ressource ni aucun état. C'est un changement de paradigme pour la plupart des développeurs JS je pense (du moins c'était pour moi). Par exemple, si j'avais un module avec état dans lequel j'ai défini un état dans le processus principal, puis que j'avais besoin de ce module dans le moteur de rendu, cet état ne serait pas là. Ce sont deux instances entièrement différentes de ce module. Le partage d'état comme celui-ci serait probablement le meilleur dans le processus principal, puis utilisez l'une des méthodes décrites ci-dessus pour partager cet état entre les processus de rendu.
Voici une liste de applications réelles et quelques exemples d'applications.
Shawn Rakowski l'a bien dit (dans les commentaires ci-dessous): "Il peut être une bonne règle de mettre du code traitant du code d'infrastructure de la plate-forme (c'est-à-dire créer des fenêtres, enregistrer des raccourcis globaux, etc.) dans le processus principal et le code spécifique à l'application (ce que votre application est en train de faire) dans les processus de rendu. "
[La fonctionnalité de mon application est-elle] analyse certains fichiers, puis affiche les informations à l'écran
Il y a beaucoup d'approches que vous pouvez adopter dans Electron car le module fs (et tous les modules node.js) sont à votre disposition dans le processus de rendu.
Si vous ne traitez qu'avec une seule instance de fenêtre de navigateur et que vous n'effectuez pas d'analyse intensive du processeur, je dirais d'exécuter tout le code associé à fs dans cette instance de processus de rendu. C'est le moyen le plus simple.
Si vous faites un travail intensif sur ces fichiers, vous ne voulez pas verrouiller l'interface utilisateur, ce qui signifie que vous ne pouvez pas faire le rendu de la fenêtre de votre navigateur de traitement, et vous ne pouvez pas le faire dans le principal (cela verrouillera tous vos moteurs de rendu!). Je voudrais donc examiner quelque chose comme électron-remote ou créer une instance de fenêtre de navigateur invisible qui exécute le gros du travail.
Cet article sur les processus principal et de rend parle de ces sujets plus en profondeur (divulgation: je l'ai écrit).