Onder de motorkap van Chromium kijken en begrijpen waarom een gewone git clone hier niet werkt

Als je ooit hebt geprobeerd de git clone https://github.com/chromium/chromium.git opdracht uit te voeren, had je daar waarschijnlijk binnen een paar minuten al spijt van. De repository is opgezwollen tot meer dan 60 gigabyte en de README begroet je met een korte waarschuwing: doe dit niet met een reguliere git.

Chromium is de basis van ongeveer de helft van de desktopapplicaties op onze computers. Het voedt Google Chrome, Microsoft Edge, Brave, Opera, de Telegram desktopclient, VS Code en Slack via Electron. Echter, de GitHub-repository van het project is slechts een openbare mirror van Google's interne infrastructuur. Laten we verkennen hoe dit monumentale project is gestructureerd, hoe je erdoorheen navigeert, en waarom een gewone ontwikkelaar de broncode zou willen openen.

Waarom de standaard workflow hier niet werkt

De meeste open-source projecten zijn op dezelfde manier opgezet: clone de repository, installeer dependencies, open je editor en maak een pull request. Dat werkt niet bij Chromium.

Er is geen vertrouwd Issues-tabblad of Pull Requests-sectie op GitHub. Alle ontwikkeling vindt plaats via een intern Gerrit-systeem op chromium-review.googlesource.com, en bugs worden bijgehouden op een speciale portal op crbug.com.

Om de broncode naar je lokale machine te halen, heeft het projectteam hun eigen set utilities ontwikkeld genaamd depot_tools. Daarin leeft het gclient hulpmiddel, dat honderden dependencies, bibliotheken van derden en cross-compilers beheert. De repository zelf is groot, maar met de volledige commitgeschiedenis, toolchain en build-dependencies heb je ongeveer 100 gigabyte vrije ruimte op een snelle SSD nodig en minstens 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

Als je probeert het hele project te bouwen op een typische quad-core laptop, zal de compiler alle cores urenlang maximaal belasten. Om builds te versnellen gebruiken Chromium-ingenieurs een gedistribueerd compilatie- en caching-systeem genaamd Reclient, samen met hun eigen build-systeem GN (Generate Ninja) gekoppeld aan Ninja.

Hoe de directorystructuur is georganiseerd

Wanneer je de Chromium-rootmap opent, beginnen je ogen te draaien. Erin bevinden zich miljoenen regels code in C++, Rust, Python, Java en JavaScript. De documentatie beschrijft strikte regels voor directory-organisatie:

1. src/content — de browser core. Hier wordt de multi-process engine geïmplementeerd: tabbeheer, geïsoleerde rendering-sandboxes, netwerkverzoekafhandeling en beveiligingsmechanismen.
2. src/third_party/blink — de pagina-rendering engine (een WebKit-fork). Hier bevinden zich de HTML- en CSS-specificatie-implementaties, samen met DOM-boom-parsing en layout-berekeningen.
3. src/v8 — de JavaScript- en WebAssembly-engine. In de Chromium-repository is het opgenomen als een externe dependency.
4. src/chrome — de Chrome-browsercode zelf. Dit omvat de gebruikersinterface, bladwijzers, extensies, gebruikersprofielen en instellingen.

Naast deze vier hoofd bouwstenen bevat het project een components/ directory met modules die kunnen worden hergebruikt in verschillende producten, zoals Android WebView of de Ash-shell voor ChromeOS.

Wat interessant is verborgen in de architectuur

Chromium is interessant niet alleen als afgewerkte browser, maar ook als voorbeeld van ongelooflijk complexe systeemarchitectuur. De codebase bevat antwoorden op vragen die ontstaan bij het lezen van web-specificaties.

Multi-process model en sandboxes

De browser is bewust opgesplitst in geïsoleerde processen. Het Browser Process beheert vensters en gebruikersinvoer, het Network Process verwerkt resource-downloads en Renderer Processes renderen pagina's.

Als een script op een tab bevriest of een pagina een kritieke geheugenfout veroorzaakt, zal alleen dat specifieke renderer process crashen — de browser blijft draaien. Isolatiemechanismen zijn apart geïmplementeerd voor elk besturingssysteem via Linux namespaces en seccomp-bpf systeemcalls, of Windows integrity levels.

Inter-process communicatie via Mojo

Omdat verschillende delen van de browser in geïsoleerde processen leven, hebben ze een snel, type-veilig mechanisme nodig om te communiceren. Chromium gebruikt hiervoor het Mojo-systeem.

Ontwikkelaars beschrijven interfaces in .mojom bestanden en een codegenerator maakt bindings voor C++, Java en JS. Dit beschermt tegen het doorgeven van onjuiste datatypes tussen het niet-vertrouwde renderer process en het bevoorrechte browser process.

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

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

Waarom frontend- en systeemprogrammeurs deze code moeten lezen

Het zou kunnen lijken alsof een gewone webontwikkelaar geen reden heeft om in C++-broncode te duiken. Maar in de praktijk is de Chromium-broncode de meest accurate bron van waarheid over hoe de browser je pagina's interpreteert.

Hier zijn vier realistische scenario's waar de codebase van het project van pas komt:

• Complexe browserbugs debuggen. Wanneer CSS Grid of Flexbox zich vreemd gedraagt in Chrome maar de W3C-specificatie vaag is geschreven, kun je de code in src/third_party/blink/renderer/core/layout openen en de wiskunde achter box-grootteberekeningen onderzoeken.
• Leren hoe Web API's werken. Alle browser-JavaScript-methoden zoals IntersectionObserver, WebSockets of ServiceWorker hebben een direct equivalent in Blink's code. Door hun implementatie te lezen, begrijp je meteen welke operaties geheugen en CPU-overhead creëren.
• Embedded browsers ontwikkelen. Als je webpaginaring naar je eigen C++- of Rust-applicatie moet insluiten, vertrouwt het Chromium Embedded Framework (CEF) op de publieke interfaces in src/content.
• Voorbeelden vinden van high-load systeemcode. Hier kun je implementaties vinden van custom memory allocators (PartitionAlloc), compressie-algoritmen, streaming netwerkprotocollen en cryptografische primitieven.

Waar te beginnen met leren

Als je alleen geïnteresseerd bent in het doorzoeken van de broncode, hoef je geen 100 gigabyte schijfruimte te gebruiken. Voor code search onderhoudt het projectteam een uitstekende webinterface genaamd Source Search op source.chromium.org. Het beschikt over instant symbol-zoekfunctie, navigatie naar functiedeclaraties en het bekijken van de wijzigingsgeschiedenis van elk bestand.

De Chromium-codebase is intimiderend in zijn schaal, maar het is een van de best gestructureerde projecten in de industrie. Zelfs een oppervlakkige bekendheid met de docs/ directory en het Blink-subsysteem helpt je beter te begrijpen hoe het webplatform werkt en meer geoptimaliseerde frontendcode te schrijven.