Guardare sotto il cofano di Chromium e capire perché un normale git clone non funziona qui

Se hai mai provato a eseguire il comando git clone https://github.com/chromium/chromium.git, probabilmente te ne sei pentito entro un paio di minuti. Il repository è cresciuto fino a superare i 60 gigabyte e il README ti accoglie con un avvertimento laconico: non farlo con un git normale.

Chromium è la base di circa la metà delle applicazioni desktop sui nostri computer. Alimenta Google Chrome, Microsoft Edge, Brave, Opera, il client desktop di Telegram, VS Code e Slack tramite Electron. Tuttavia, il repository GitHub del progetto è solo un mirror pubblico dell'infrastruttura interna di Google. Esploriamo come è strutturato questo progetto mastodontico, come navigarlo e perché un ingegnere ordinario avrebbe bisogno di aprire il suo codice sorgente.

Perché il workflow standard qui non funziona

La maggior parte dei progetti open source sono configurati allo stesso modo: clona il repository, installa le dipendenze, apri il tuo editor e crea una pull request. Con Chromium questo non funziona.

Non c'è la familiare scheda Issues o la sezione Pull Requests su GitHub. Tutto lo sviluppo avviene attraverso un sistema Gerrit interno su chromium-review.googlesource.com, e i bug vengono tracciati su un portale dedicato su crbug.com.

Per scaricare il codice sorgente sulla tua macchina locale, il team del progetto ha sviluppato un proprio set di utility chiamate depot_tools. Al suo interno vive lo strumento gclient, che gestisce centinaia di dipendenze, librerie di terze parti e cross-compiler. Il repository stesso è grande, ma con la cronologia completa dei commit, la toolchain e le dipendenze di build, avrai bisogno di circa 100 gigabyte di spazio libero su un SSD veloce e almeno 16 gigabyte di 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

Se provi a buildare l'intero progetto su un tipico laptop quad-core, il compilatore terrà tutti i core al massimo per diverse ore. Per velocizzare le build, gli ingegneri di Chromium usano un sistema di compilazione distribuita e caching chiamato Reclient, insieme al proprio sistema di build GN (Generate Ninja) accoppiato con Ninja.

Come è organizzata la struttura delle directory

Quando apri la cartella root di Chromium, i tuoi occhi iniziano a girare. Dentro ci sono milioni di righe di codice in C++, Rust, Python, Java e JavaScript. La documentazione descrive regole rigorose per l'organizzazione delle directory:

1. src/content — il core del browser. Qui è implementato il motore multi-processo: gestione delle tab, sandbox di rendering isolate, gestione delle richieste di rete e meccanismi di sicurezza.
2. src/third_party/blink — il motore di rendering delle pagine (un fork di WebKit). Qui si trovano le implementazioni delle specifiche HTML e CSS, insieme al parsing dell'albero DOM e ai calcoli del layout.
3. src/v8 — il motore JavaScript e WebAssembly. Nel repository Chromium è incluso come dipendenza esterna.
4. src/chrome — il codice stesso del browser Chrome. Include l'interfaccia utente, i segnalibri, le estensioni, i profili utente e le impostazioni.

Oltre a questi quattro blocchi costitutivi principali, il progetto contiene una directory components/ con moduli che possono essere riutilizzati in prodotti diversi, come Android WebView o la shell Ash per ChromeOS.

Cosa c'è di interessante nascosto nell'architettura

Chromium è interessante non solo come browser finito ma anche come esempio di architettura di sistema incredibilmente complessa. Il codebase contiene risposte a domande che emergono quando si leggono le specifiche web.

Modello multi-processo e sandbox

Il browser è deliberatamente suddiviso in processi isolati. Il Browser Process gestisce le finestre e l'input dell'utente, il Network Process gestisce il download delle risorse e i Renderer Process renderizzano le pagine.

Se uno script in una tab si blocca o una pagina genera un errore critico di memoria, solo quel processo renderer specifico andrà in crash—il browser continuerà a funzionare. I meccanismi di isolamento sono implementati separatamente per ogni sistema operativo attraverso i namespace Linux e le system call seccomp-bpf, o i livelli di integrità di Windows.

Comunicazione inter-processo tramite Mojo

Dato che diverse parti del browser vivono in processi isolati, hanno bisogno di un meccanismo rapido e type-safe per comunicare. Chromium usa il sistema Mojo per questo.

Gli sviluppatori descrivono le interfacce in file .mojom, e un generatore di codice crea i binding per C++, Java e JS. Questo protegge dal passaggio di tipi di dati errati tra il processo renderer non attendibile e il processo browser privilegiato.

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

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

Perché sviluppatori frontend e sistemi dovrebbero leggere questo codice

Potrebbe sembrare che uno sviluppatore web ordinario non abbia motivo di scavare nel codice sorgente C++. Ma in pratica, il codice sorgente di Chromium è la fonte di verità più accurata su come il browser interpreta le tue pagine.

Ecco quattro scenari reali in cui il codebase del progetto risulta utile:

• Debug di bug complessi del browser. Quando CSS Grid o Flexbox si comporta in modo strano in Chrome ma la specifica W3C è scritta in modo vago, puoi aprire il codice in src/third_party/blink/renderer/core/layout ed esaminare la matematica dietro i calcoli delle dimensioni dei box.
• Imparare come funzionano le Web API. Tutti i metodi JavaScript del browser come IntersectionObserver, WebSockets o ServiceWorker hanno un corrispondente diretto nel codice di Blink. Leggendo la loro implementazione, capisci immediatamente quali operazioni creano overhead di memoria e CPU.
• Sviluppo di browser embedded. Se hai bisogno di embedere il rendering di pagine web nella tua applicazione C++ o Rust, Chromium Embedded Framework (CEF) si basa sulle interfacce pubbliche in src/content.
• Trovare esempi di codice per sistemi ad alto carico. Qui puoi trovare implementazioni di allocatori di memoria personalizzati (PartitionAlloc), algoritmi di compressione, protocolli di rete in streaming e primitive crittografiche.

Da dove iniziare per imparare

Se sei solo interessato a navigare il codice sorgente, non hai bisogno di spendere 100 gigabyte di spazio su disco. Per la ricerca nel codice, il team del progetto mantiene un'eccellente interfaccia web chiamata Source Search su source.chromium.org. Offre ricerca istantanea dei simboli, navigazione alle dichiarazioni delle funzioni e visualizzazione della cronologia delle modifiche di qualsiasi file.

Il codebase di Chromium è imponente per la sua scala, ma è uno dei progetti più ben strutturati del settore. Anche una familiarità superficiale con la directory docs/ e il sottosistema Blink ti aiuta a comprendere meglio la piattaforma web e a scrivere codice frontend più ottimizzato.