Dando Uma Olhada Por Trás do Capô do Chromium e Entendendo Por Que um git clone Comum Não Funciona Aqui

Se você já tentou executar o comando git clone https://github.com/chromium/chromium.git, provavelmente se arrependeu em poucos minutos. O repositório cresceu para mais de 60 gigabytes, e o README recebe você com um aviso breve: não faça isso com um git comum.

O Chromium é a base de boa metade dos aplicativos desktop em nossos computadores. Ele alimenta o Google Chrome, Microsoft Edge, Brave, Opera, o cliente desktop do Telegram, o VS Code e o Slack via Electron. No entanto, o repositório GitHub do projeto é apenas um espelho público da infraestrutura interna do Google. Vamos explorar como esse projeto monstruoso é estruturado, como navegar por ele e por que um engenheiro comum precisaria abrir seu código-fonte.

Por que o fluxo de trabalho padrão não funciona aqui

A maioria dos projetos de código aberto são configurados da mesma forma: clone o repositório, instale as dependências, abra seu editor e faça um pull request. Isso não funciona com o Chromium.

Não há aba de Issues familiar ou seção de Pull Requests no GitHub. Todo o desenvolvimento acontece através de um sistema Gerrit interno em chromium-review.googlesource.com, e os bugs são rastreados em um portal dedicado em crbug.com.

Para obter o código-fonte para sua máquina local, a equipe do projeto desenvolveu seu próprio conjunto de utilitários chamado depot_tools. Dentro dele está a ferramenta gclient, que gerencia centenas de dependências, bibliotecas de terceiros e compiladores cruzados. O repositório em si é grande, mas com o histórico completo de commits, toolchain e dependências de build, você precisará de cerca de 100 gigabytes de espaço livre em um SSD rápido e pelo menos 16 gigabytes 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

Se você tentar compilar o projeto inteiro em um laptop quad-core típico, o compilador vai maximizar todos os núcleos por várias horas. Para acelerar as compilações, os engenheiros do Chromium usam um sistema de compilação distribuída e cache chamado Reclient, junto com seu próprio sistema de build GN (Generate Ninja) combinado com Ninja.

Como a estrutura de diretórios é organizada

Quando você abre a pasta raiz do Chromium, seus olhos começam a girar. Dentro estão milhões de linhas de código em C++, Rust, Python, Java e JavaScript. A documentação descreve regras rigorosas para a organização de diretórios:

1. src/content — o núcleo do navegador. É aqui que o motor multi-processo é implementado: gerenciamento de abas, sandboxes de renderização isolada, tratamento de requisições de rede e mecanismos de segurança.
2. src/third_party/blink — o motor de renderização de páginas (um fork do WebKit). É aqui que vivem as implementações das especificações de HTML e CSS, junto com a análise da árvore DOM e cálculos de layout.
3. src/v8 — o motor JavaScript e WebAssembly. No repositório do Chromium, ele é incluído como uma dependência externa.
4. src/chrome — o código do próprio navegador Chrome. Isso inclui a interface do usuário, favoritos, extensões, perfis de usuário e configurações.

Além desses quatro blocos principais de construção, o projeto contém um diretório components/ com módulos que podem ser reutilizados em diferentes produtos, como o Android WebView ou o shell Ash para ChromeOS.

O que há de interessante escondido na arquitetura

O Chromium é interessante não apenas como um navegador finalizado, mas também como um exemplo de arquitetura de sistemas incrivelmente complexa. O código-fonte contém respostas para perguntas que surgem ao ler especificações web.

Modelo multi-processo e sandboxes

O navegador é deliberadamente dividido em processos isolados. O Browser Process gerencia janelas e entrada do usuário, o Network Process trata downloads de recursos, e os Renderer Processes renderizam páginas.

Se um script em uma aba travar ou uma página causar um erro crítico de memória, apenas aquele processo renderer específico vai falhar—o navegador continua rodando. Os mecanismos de isolamento são implementados separadamente para cada sistema operacional através de namespaces Linux e chamadas de sistema seccomp-bpf, ou níveis de integridade do Windows.

Comunicação entre processos via Mojo

Como diferentes partes do navegador vivem em processos isolados, eles precisam de um mecanismo rápido e type-safe para se comunicar. O Chromium usa o sistema Mojo para isso.

Os desenvolvedores descrevem interfaces em arquivos .mojom, e um gerador de código cria bindings para C++, Java e JS. Isso protege contra a passagem de tipos de dados incorretos entre o processo renderer não confiável e o processo navegador privilegiado.

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

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

Por que desenvolvedores frontend e de sistemas devem ler esse código

Pode parecer que um desenvolvedor web comum não tem motivo para vasculhar código-fonte em C++. Mas na prática, o código-fonte do Chromium é a fonte de verdade mais precisa sobre como o navegador interpreta suas páginas.

Aqui estão quatro cenários reais onde o código-fonte do projeto é útil:

• Depurando bugs complexos do navegador. Quando CSS Grid ou Flexbox se comporta de forma estranha no Chrome, mas a especificação W3C é vagamente escrita, você pode abrir o código em src/third_party/blink/renderer/core/layout e examinar a matemática por trás dos cálculos de tamanho de caixa.
• Aprendendo como as Web APIs funcionam. Todos os métodos JavaScript do navegador como IntersectionObserver, WebSockets ou ServiceWorker têm uma contrapartida direta no código do Blink. Ao ler sua implementação, você entende imediatamente quais operações criam overhead de memória e CPU.
• Desenvolvendo navegadores embarcados. Se você precisa embutir a renderização de páginas web em seu próprio aplicativo em C++ ou Rust, o Chromium Embedded Framework (CEF) depende das interfaces públicas em src/content.
• Encontrando exemplos de código de sistemas de alta carga. Aqui você pode encontrar implementações de allocators de memória personalizados (PartitionAlloc), algoritmos de compressão, protocolos de rede de streaming e primitivas criptográficas.

Por onde começar a aprender

Se você está apenas interessado em navegar pelo código-fonte, não precisa gastar 100 gigabytes de espaço em disco. Para busca de código, a equipe do projeto mantém uma excelente interface web chamada Source Search em source.chromium.org. Ela oferece busca instantânea de símbolos, navegação para declarações de funções e visualização do histórico de alterações de qualquer arquivo.

A base de código do Chromium é intimidadora em sua escala, mas é um dos projetos mais bem estruturados da indústria. Mesmo uma familiaridade superficial com o diretório docs/ e o subsistema Blink ajuda você a entender melhor a plataforma web e escrever código frontend mais otimizado.