Sous le capot de Chromium : pourquoi un simple git clone ne fonctionne pas ici

Si vous avez déjà tenté d'exécuter la commande git clone https://github.com/chromium/chromium.git, vous l'avez probablement regrettée en quelques minutes. Le dépôt a gonflé pour dépasser les 60 gigaoctets, et le README vous accueille avec un avertissement laconique : ne faites pas cela avec un git classique.

Chromium est la fondation de près de la moitié des applications de bureau sur nos ordinateurs. Il alimente Google Chrome, Microsoft Edge, Brave, Opera, le client de bureau Telegram, VS Code et Slack via Electron. Cependant, le dépôt GitHub du projet n'est qu'un miroir public de l'infrastructure interne de Google. Explorons comment ce projet colossal est structuré, comment le parcourir, et pourquoi un ingénieur ordinaire aurait besoin d'ouvrir son code source.

Pourquoi le flux de travail standard ne fonctionne pas ici

La plupart des projets open source sont configurés de la même manière : cloner le dépôt, installer les dépendances, ouvrir votre éditeur et créer une pull request. Cela ne fonctionne pas avec Chromium.

Il n'y a pas d'onglet Issues familier ni de section Pull Requests sur GitHub. Tout le développement se fait via un système Gerrit interne à chromium-review.googlesource.com, et les bugs sont suivis sur un portail dédié à crbug.com.

Pour récupérer le code source sur votre machine locale, l'équipe du projet a développé son propre ensemble d'utilitaires appelé depot_tools. À l'intérieur se trouve l'outil gclient, qui gère des centaines de dépendances, de bibliothèques tierces et de cross-compilers. Le dépôt lui-même est volumineux, mais avec l'historique complet des commits, la chaîne d'outils et les dépendances de build, vous aurez besoin d'environ 100 gigaoctets d'espace libre sur un SSD rapide et d'au moins 16 gigaoctets de RAM.

# Типичный процесс получения исходников через depot_tools выглядит так
git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
export PATH="$PATH:/path/to/depot_tools"

mkdir chromium && cd chromium
fetch --nohooks chromium
gclient sync

Si vous essayez de compiler l'ensemble du projet sur un ordinateur portable quadricœur typique, le compilateur saturera tous les cœurs pendant plusieurs heures. Pour accélérer les builds, les ingénieurs de Chromium utilisent un système de compilation distribuée et de mise en cache appelé Reclient, ainsi que leur propre système de build GN (Generate Ninja) associé à Ninja.

Comment la structure des répertoires est organisée

Quand vous ouvrez le dossier racine de Chromium, vos yeux commencent à tourner. À l'intérieur se trouvent des millions de lignes de code en C++, Rust, Python, Java et JavaScript. La documentation décrit des règles strictes pour l'organisation des répertoires :

1. src/content — le cœur du navigateur. C'est ici qu'est implémenté le moteur multi-processus : gestion des onglets, sandbox de rendu isolé, gestion des requêtes réseau et mécanismes de sécurité.
2. src/third_party/blink — le moteur de rendu de pages (un fork de WebKit). C'est ici que se trouvent les implémentations des spécifications HTML et CSS, ainsi que l'analyse de l'arbre DOM et les calculs de disposition.
3. src/v8 — le moteur JavaScript et WebAssembly. Dans le dépôt Chromium, il est inclus comme dépendance externe.
4. src/chrome — le code du navigateur Chrome lui-même. Cela inclut l'interface utilisateur, les favoris, les extensions, les profils utilisateur et les paramètres.

Au-delà de ces quatre blocs de construction principaux, le projet contient un répertoire components/ avec des modules réutilisables dans différents produits, comme Android WebView ou l'environnement Ash pour ChromeOS.

Ce qui est intéressant de caché dans l'architecture

Chromium est intéressant non seulement en tant que navigateur terminé, mais aussi en tant qu'exemple d'architecture système incroyablement complexe. La base de code contient des réponses aux questions qui se posent lors de la lecture des spécifications web.

Modèle multi-processus et sandbox

Le navigateur est délibérément divisé en processus isolés. Le Browser Process gère les fenêtres et les entrées utilisateur, le Network Process gère les téléchargements de ressources, et les Renderer Processes rendent les pages.

Si un script sur un onglet se bloque ou qu'une page déclenche une erreur mémoire critique, seul ce processus renderer spécifique plantera—le navigateur continuera à fonctionner. Les mécanismes d'isolation sont implémentés séparément pour chaque système d'exploitation via les namespaces Linux et les appels système seccomp-bpf, ou les niveaux d'intégrité Windows.

Communication inter-processus via Mojo

Comme différentes parties du navigateur résident dans des processus isolés, ils ont besoin d'un mécanisme rapide et type-safe pour communiquer. Chromium utilise le système Mojo pour cela.

Les développeurs décrivent les interfaces dans des fichiers .mojom, et un générateur de code crée des liaisons pour C++, Java et JS. Cela protège contre le passage de types de données incorrects entre le processus renderer non privilégié et le processus navigateur privilégié.

// Пример описания интерфейса в Mojo
module example.mojom;

interface PingResponder {
  Ping() => (string response);
};

Pourquoi les développeurs frontend et les programmeurs systèmes devraient lire ce code

Il peut sembler qu'un développeur web ordinaire n'ait aucune raison de fouiller dans le code source C++. Mais en pratique, le code source de Chromium est la source de vérité la plus précise sur la façon dont le navigateur interprète vos pages.

Voici quatre scénarios réels où la base de code du projet s'avère utile :

• Déboguer des bugs complexes du navigateur. Quand CSS Grid ou Flexbox se comporte étrangement dans Chrome mais que la spécification W3C est vaguement rédigée, vous pouvez ouvrir le code dans src/third_party/blink/renderer/core/layout et examiner les calculs derrière les размеры de boîte.
• Comprendre comment les Web APIs fonctionnent. Toutes les méthodes JavaScript du navigateur comme IntersectionObserver, WebSockets ou ServiceWorker ont un équivalent direct dans le code de Blink. En lisant leur implémentation, vous comprenez immédiatement quelles opérations créent une surcharge mémoire et CPU.
• Développer des navigateurs embarqués. Si vous avez besoin d'intégrer le rendu de pages web dans votre propre application C++ ou Rust, le Chromium Embedded Framework (CEF) s'appuie sur les interfaces publiques dans src/content.
• Trouver des exemples de code pour systèmes à forte charge. Vous y trouverez des implémentations d'allocateurs mémoire personnalisés (PartitionAlloc), d'algorithmes de compression, de protocoles réseau en streaming et de primitives cryptographiques.

Par où commencer l'apprentissage

Si vous êtes simplement intéressé par la consultation du code source, vous n'avez pas besoin de dépenser 100 gigaoctets d'espace disque. Pour la recherche de code, l'équipe du projet maintient une excellente interface web appelée Source Search à source.chromium.org. Elle offre une recherche instantanée de symboles, la navigation vers les déclarations de fonctions et la visualisation de l'historique des modifications de n'importe quel fichier.

La base de code de Chromium est intimidante par son échelle, mais c'est l'un des projets les mieux structurés de l'industrie. Même une familiarité superficielle avec le répertoire docs/ et le sous-système Blink vous aide à mieux comprendre la plateforme web et à écrire du code frontend plus optimisé.