Comment Google Chrome isole-t-il les onglets dans des processus distincts tout en ayant l'air d'une seule application ?

Question

Nous avons appris que Google Chrome exécute chaque onglet dans un processus séparé. Par conséquent, un crash dans un onglet ne causerait pas de problèmes dans les autres onglets.

À ma connaissance, les multiprocessus sont principalement utilisés dans les programmes sans interface graphique. Je n'ai jamais lu de technique pouvant intégrer plusieurs processus graphiques dans un seul.

Comment Chrome fait-il cela?

Je pose cette question car je conçois un logiciel de vidéosurveillance qui utilisera des SDK de décodage vidéo de plusieurs fabricants de caméras, certains étant loin d'être stables. J'ai donc préféré exécuter ces SDK dans des processus différents, ce qui me semblait similaire à Chrome.

Answer 1

Fondamentalement, ils utilisent un autre processus qui les colle tous ensemble dans l'interface graphique.

Google Chrome crée trois types différents de processus : le navigateur, les rendus et les plug-ins.

Navigateur: Il n'y a qu'un seul processus de navigateur, qui gère les onglets, les fenêtres et le "chrome" du navigateur. Ce processus gère également toutes les interactions avec le disque, le réseau, l'entrée utilisateur et l'affichage, mais il ne tente pas d'analyser ou de rendre un contenu provenant du web.

Rendus: Le processus de navigateur crée de nombreux processus de rendu, chacun étant responsable du rendu des pages web. Les processus de rendu contiennent toute la logique complexe pour gérer le HTML, le JavaScript, le CSS, les images, etc. Chrome réalise cela en utilisant le moteur de rendu WebKit open source, qui est également utilisé par le navigateur web Safari d'Apple. Chaque processus de rendu est exécuté dans un bac à sable, ce qui signifie qu'il a presque aucun accès direct au disque, au réseau ou à l'affichage. Toutes les interactions avec les applications web, y compris les événements d'entrée utilisateur et la peinture à l'écran, doivent passer par le processus de navigateur. Cela permet au processus de navigateur de surveiller les rendus pour toute activité suspecte, en les arrêtant s'il soupçonne qu'une exploitation s'est produite.

Plug-ins: Le processus de navigateur crée également un processus pour chaque type de plug-in utilisé, comme Flash, Quicktime ou Adobe Reader. Ces processus contiennent simplement les plug-ins eux-mêmes, ainsi que du code de liaison pour leur permettre d'interagir avec le navigateur et les rendus.

Source: Chromium Blog : Architecture multi-processus

Answer 2

Dans ce contexte, la conception fondamentale est intéressante.

Voici les documents de conception pertinents, en particulier la section sur l'architecture multi-processus.

Un aperçu architectural :

Answer 3

Téléchargez la source et voyez ! Cela vous serait très bénéfique si vous avez besoin d'une solution similaire. Google Chrome est open source.

Answer 4

J'ai juste donné la première réponse (celle expliquant la différence entre 'navigateur' vs 'renderers' vs 'plugins') une approbation... cela me semble être la plus complète et avoir du sens pour moi.

La seule chose que j'ajouterai sont quelques commentaires supplémentaires sur POURQUOI le design de Google est tel qu'il est, et donner un avis sur pourquoi c'est toujours été mon premier choix pour un navigateur global/de tous les jours. (Bien que je réalise que COMMENT (et non PAS POURQUOI) était la question posée.)

Concevoir de sorte que les composants individuels aient leur code dans des processus distincts permet au système d'exploitation de 'protéger en mémoire' les processus de se modifier accidentellement (ou intentionnellement) mutuellement de manière non explicitement conçue.

Les seules parties dans un tel design qui peuvent à la fois lire et écrire des données partagées sont celles qui sont conçues pour DEVOIR accéder à ces données, et permettent de contrôler si cet accès est juste un accès de 'lecture' ou un accès de 'lecture' et 'écriture', etc. Et, puisque ces contrôles d'accès sont implémentés dans le matériel, ils garantissent fermement que les règles d'accès ne peuvent pas être violées. Ainsi, les plugins et extensions d'autres auteurs et entreprises, s'exécutant dans des onglets/processus séparés, ne peuvent pas se casser mutuellement.

Un tel design a pour effet de minimiser les chances de modifier du code ou des données qui n'étaient pas destinés à être modifiés. Cela est fait pour des raisons de sécurité et aboutit à un code plus fiable, moins bogué.

Le simple fait que Google ait un design aussi complexe est, pour moi, une bonne preuve du fait que Google semble avoir une excellente compréhension de ces concepts et a construit un produit supérieur. (Cela dit, en tant que développeur web, nous devons toujours tester notre code web avec plusieurs navigateurs. Et, des navigateurs comme Firefox, étant présents depuis longtemps et ayant un excellent groupe de 'add-ons' liés aux développeurs web ont toujours certains avantages pour certaines tâches.)

Mais, pour une utilisation globale quotidienne du navigateur, pour presque toutes les tâches, le navigateur Chrome est devenu mon premier choix. (Juste mon avis, et bien sûr, vos expériences peuvent varier.)

Answer 5

La plupart du travail de rendu d'une page web consiste à déterminer exactement où vont les éléments (c'est-à-dire où placer chaque image, quelle couleur rendre chaque morceau de texte). Ce travail est effectué dans un processus séparé. Une fois que le processus séparé a déterminé où tout doit aller, il transmet ces informations au processus principal de Chrome qui dessine tous les éléments à l'écran.

Il n'est pas clair exactement comment votre système de sdk vidéo est configuré. Mais vous pourriez avoir un processus qui décompresse la vidéo et un autre processus qui la rend à l'écran. Cependant, il est très probable que vous utilisiez OpenGL ou DirectX. Ces API peuvent imposer certaines limites sur la manière dont vous répartissez les tâches entre différents processus.