Unter der Haube von Chromium: Warum ein gewöhnliches git clone hier nicht funktioniert

Wenn Sie jemals versucht haben, den Befehl git clone https://github.com/chromium/chromium.git auszuführen, haben Sie es wahrscheinlich innerhalb weniger Minuten bereut. Das Repository ist auf über 60 Gigabyte angewachsen, und die README begrüßt Sie mit einer knappen Warnung: Verwenden Sie kein gewöhnliches Git dafür.

Chromium ist das Fundament etwa der Hälfte der Desktop-Anwendungen auf unseren Computern. Es betreibt Google Chrome, Microsoft Edge, Brave, Opera, den Telegram-Desktop-Client, VS Code und Slack über Electron. Das GitHub-Repository des Projekts ist jedoch nur ein öffentlicher Spiegel von Googles interner Infrastruktur. Lassen Sie uns erkunden, wie dieses gewaltige Projekt strukturiert ist, wie man sich darin zurechtfindet und warum ein gewöhnlicher Entwickler den Quellcode überhaupt öffnen müsste.

Warum der Standard-Workflow hier nicht funktioniert

Die meisten Open-Source-Projekte sind gleich aufgebaut: Repository klonen, Abhängigkeiten installieren, Editor öffnen und einen Pull Request erstellen. Bei Chromium funktioniert das nicht.

Es gibt keinen vertrauten Issues-Tab oder Pull-Requests-Bereich auf GitHub. Die gesamte Entwicklung findet über ein internes Gerrit-System unter chromium-review.googlesource.com statt, und Fehler werden auf einem dedizierten Portal unter crbug.com verfolgt.

Um den Quellcode auf Ihren lokalen Rechner zu holen, hat das Projektteam einen eigenen Satz von Werkzeugen namens depot_tools entwickelt. Darin befindet sich das Tool gclient, das Hunderte von Abhängigkeiten, Bibliotheken von Drittanbietern und Cross-Compiler verwaltet. Das Repository selbst ist groß, aber mit der vollständigen Commit-Historie, der Toolchain und den Build-Abhängigkeiten benötigen Sie etwa 100 Gigabyte freien Speicherplatz auf einer schnellen SSD und mindestens 16 Gigabyte 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

Wenn Sie versuchen, das gesamte Projekt auf einem typischen Quad-Core-Laptop zu bauen, wird der Compiler alle Kerne für mehrere Stunden auslasten. Um Builds zu beschleunigen, verwenden Chromium-Entwickler ein verteiltes Kompilierungs- und Caching-System namens Reclient, zusammen mit ihrem eigenen Build-System GN (Generate Ninja) in Kombination mit Ninja.

Wie die Verzeichnisstruktur organisiert ist

Wenn Sie den Chromium-Stammordner öffnen, dreht sich Ihnen der Kopf. Darin befinden sich Millionen von Codezeilen in C++, Rust, Python, Java und JavaScript. Die Dokumentation beschreibt strenge Regeln für die Verzeichnisorganisation:

1. src/content — der Browser-Kern. Hier wird die Multi-Prozess-Engine implementiert: Tab-Verwaltung, isolierte Rendering-Sandboxes, Netzwerkanfragen-Behandlung und Sicherheitsmechanismen.
2. src/third_party/blink — die Seiten-Rendering-Engine (ein WebKit-Fork). Hier befinden sich die Implementierungen der HTML- und CSS-Spezifikationen sowie das Parsing des DOM-Baums und Layout-Berechnungen.
3. src/v8 — die JavaScript- und WebAssembly-Engine. Im Chromium-Repository ist sie als externe Abhängigkeit enthalten.
4. src/chrome — der Chrome-Browser-Code selbst. Dies umfasst die Benutzeroberfläche, Lesezeichen, Erweiterungen, Benutzerprofile und Einstellungen.

Über diese vier Hauptbausteine hinaus enthält das Projekt ein components/-Verzeichnis mit Modulen, die in verschiedenen Produkten wiederverwendet werden können, wie Android WebView oder die Ash-Shell für ChromeOS.

Was Interessantes in der Architektur verborgen ist

Chromium ist nicht nur als fertiger Browser interessant, sondern auch als Beispiel für eine unglaublich komplexe Systemarchitektur. Die Codebasis enthält Antworten auf Fragen, die beim Lesen von Web-Spezifikationen auftauchen.

Multi-Prozess-Modell und Sandboxes

Der Browser ist bewusst in isolierte Prozesse aufgeteilt. Der Browser-Prozess verwaltet Fenster und Benutzereingaben, der Netzwerk-Prozess bearbeitet Ressourcen-Downloads und Renderer-Prozesse rendern Seiten.

Wenn ein Skript auf einem Tab einfriert oder eine Seite einen kritischen Speicherfehler auslöst, stürzt nur dieser spezifische Renderer-Prozess ab — der Browser läuft weiter. Isolierungsmechanismen werden für jedes Betriebssystem separat über Linux-Namespaces und seccomp-bpf-Systemaufrufe oder Windows-Integritätsebenen implementiert.

Inter-Prozess-Kommunikation über Mojo

Da verschiedene Teile des Browsers in isolierten Prozessen leben, benötigen sie einen schnellen, typsicheren Mechanismus zur Kommunikation. Chromium verwendet dafür das Mojo-System.

Entwickler beschreiben Schnittstellen in .mojom-Dateien, und ein Code-Generator erstellt Bindings für C++, Java und JS. Dies schützt vor der Übergabe falscher Datentypen zwischen dem nicht vertrauenswürdigen Renderer-Prozess und dem privilegierteren Browser-Prozess.

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

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

Warum Frontend- und Systemprogrammierer diesen Code lesen sollten

Es könnte so aussehen, als hätte ein gewöhnlicher Webentwickler keinen Grund, sich in C++-Quellcode zu vertiefen. Aber in der Praxis ist der Chromium-Quellcode die genaueste Quelle der Wahrheit darüber, wie der Browser Ihre Seiten interpretiert.

Hier sind vier reale Szenarien, in denen die Codebasis des Projekts nützlich ist:

• Komplexe Browser-Bugs debuggen. Wenn sich CSS Grid oder Flexbox seltsam in Chrome verhält, aber die W3C-Spezifikation vage geschrieben ist, können Sie den Code in src/third_party/blink/renderer/core/layout öffnen und die Mathematik hinter den Box-Größen-Berechnungen untersuchen.
• Lernen, wie Web-APIs funktionieren. Alle Browser-JavaScript-Methoden wie IntersectionObserver, WebSockets oder ServiceWorker haben ein direktes Gegenstück im Blink-Code. Wenn Sie deren Implementierung lesen, verstehen Sie sofort, welche Operationen Speicher- und CPU-Overhead verursachen.
• Entwicklung eingebetteter Browser. Wenn Sie Webseiten-Rendering in Ihre eigene C++- oder Rust-Anwendung einbetten müssen, stützt sich das Chromium Embedded Framework (CEF) auf die öffentlichen Schnittstellen in src/content.
• Beispiele für hochbelastbare Systeme finden. Hier finden Sie Implementierungen von benutzerdefinierten Speicherallokatoren (PartitionAlloc), Kompressionsalgorithmen, Streaming-Netzwerkprotokollen und kryptografischen Grundbausteinen.

Wo Sie mit dem Lernen beginnen

Wenn Sie sich nur für das Durchsuchen des Quellcodes interessieren, müssen Sie keine 100 Gigabyte Festplattenspeicher belegen. Für die Codesuche pflegt das Projektteam eine ausgezeichnete Weboberfläche namens Source Search unter source.chromium.org. Sie bietet sofortige Symbolsuche, Navigation zu Funktionsdeklarationen und die Ansicht des Änderungsverlaufs jeder Datei.

Die Chromium-Codebasis ist aufgrund ihrer Größe einschüchternd, aber sie ist eines der am besten strukturierten Projekte der Branche. Selbst eine oberflächliche Vertrautheit mit dem docs/-Verzeichnis und dem Blink-Subsystem hilft Ihnen, die Webplattform besser zu verstehen und optimierteren Frontend-Code zu schreiben.