Заглядываем под капот Chromium и разбираемся, почему обычный git clone тут не сработает

Logo

Если вы когда-нибудь пробовали выполнить команду git clone https://github.com/chromium/chromium.git, то наверняка пожалели об этом уже через пару минут. Объем репозитория перевалил за 60 гигабайт, а сам README встречает лаконичным предупреждением: не делайте этого через обычный git.

Chromium лежит в основе доброй половины десктопных приложений на наших компьютерах. На нем работают Google Chrome, Microsoft Edge, Brave, Opera, десктопный клиент Telegram, VS Code и Slack через Electron. При этом GitHub-репозиторий проекта — это лишь публичное зеркало внутренней инфраструктуры Google. Давайте разберем, как устроен этот монструозный проект, как в нем ориентироваться и зачем обычному инженеру открывать его исходники.

Почему здесь не работает стандартный рабочий процесс

Большинство open-source проектов устроены одинаково: склонировал репозиторий, поставил зависимости, открыл редактор и сделал pull request. С Chromium этот номер не пройдет.

Здесь нет привычных вкладки Issues и раздела Pull Requests на GitHub. Вся разработка ведется через внутреннюю систему Gerrit на chromium-review.googlesource.com, а баги трекаются на специальном портале crbug.com.

Чтобы забрать исходники себе на локальную машину, команда проекта разработала собственный набор утилит под названием depot_tools. Внутри него живет инструмент gclient, который управляет сотнями зависимостей, сторонних библиотек и кросс-компиляторов. Сам репозиторий весит много, но вместе с полной историей коммитов, тулчейном и сборочными зависимостями вам понадобится около 100 гигабайт свободного места на быстром SSD и минимум 16 гигабайт оперативной памяти.

# Типичный процесс получения исходников через 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

Если попытаться собрать проект целиком на среднем четырехъядерном ноутбуке, компилятор загрузит все ядра на несколько часов. Для ускорения сборки инженеры Chromium используют распределенную систему компиляции и кэширования Reclient, а также собственную сборочную систему GN (Generate Ninja) в связке с Ninja.

Как устроена структура каталогов

Когда открываешь корневую папку Chromium, глаза разбегаются. Внутри лежат миллионы строк кода на C++, Rust, Python, Java и JavaScript. В документации описаны строгие правила организации директорий:

src/content — ядро браузера. Здесь реализован многопроцессный движок: управление вкладками, изолированные песочницы для рендеринга, обработка сетевых запросов и механизмы безопасности.
src/third_party/blink — движок рендеринга страниц (форк WebKit). Именно тут находятся реализация спецификаций HTML, CSS, парсинг DOM-дерева и расчет макетов (layout).
src/v8 — движок JavaScript и WebAssembly. В репозитории Chromium он подключен как внешняя зависимость.
src/chrome — код самого браузера Chrome. Сюда входят пользовательский интерфейс, закладки, расширения, профили пользователей и настройки.

Помимо этих четырех основных блоков, в проекте есть каталог components/ с модулями, которые можно переиспользовать в разных продуктах, например в Android WebView или оболочке Ash для ChromeOS.

Что интересного скрыто в архитектуре

Chromium интересен не только как готовый браузер, но и как образец сложнейшей системной архитектуры. В кодовой базе можно найти ответы на вопросы, которые возникают при чтении веб-спецификаций.

Многопроцессная модель и песочницы

Браузер намеренно разбит на изолированные процессы. Браузерный процесс (Browser Process) управляет окнами и вводом пользователя, сетевой процесс отвечает за скачивание ресурсов, а процессы рендеринга (Renderer Processes) отрисовывают страницы.

Если скрипт на вкладке зависнет или страница вызовет критическую ошибку памяти, упадет только конкретный процесс рендерера, а браузер продолжит работать. Механизмы изоляции реализованы под каждую операционную систему отдельно через системные вызовы Linux namespaces, seccomp-bpf или Windows integrity levels.

Межпроцессное взаимодействие через Mojo

Поскольку разные части браузера живут в изолированных процессах, им нужен быстрый и типобезопасный механизм общения. В Chromium для этого используется система Mojo.

Разработчики описывают интерфейсы в файлах .mojom, а генератор кода создает обвязки для C++, Java и JS. Это защищает от передачи некорректных типов данных между ненадежным процессом рендерера и привилегированным процессом браузера.

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

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

Зачем фронтендеру и системному программисту читать этот код

Кажется, что обычному веб-разработчику незачем залезать в исходники на C++. Но на практике исходный код Chromium — это самый точный источник истины о том, как браузер интерпретирует ваши страницы.

Вот четыре реальных сценария, когда кодовая база проекта выручает:

Отладка сложных багов браузера. Когда CSS Grid или Flexbox ведет себя странно в Chrome, но спецификация W3C написана размыто, можно открыть код в src/third_party/blink/renderer/core/layout и посмотреть математику расчета размеров блоков.
Изучение работы Web API. Все методы браузерного JavaScript вроде IntersectionObserver, WebSockets или ServiceWorker имеют прямое отражение в коде Blink. Читая их реализацию, сразу понимаешь, какие операции создают накладные расходы по памяти и процессору.
Разработка встраиваемых браузеров. Если вам нужно встроить рендеринг веб-страниц в собственное C++ или Rust приложение, Chromium Embedded Framework (CEF) опирается именно на публичные интерфейсы src/content.
Поиск примеров высоконагруженного системного кода. Здесь можно подсмотреть реализацию собственных аллокаторов памяти (PartitionAlloc), алгоритмов сжатия, потоковых сетевых протоколов и криптографических примитивов.

С чего начать изучение

Если вам просто интересно посмотреть исходники, не нужно тратить 100 гигабайт диска. Для поиска по коду команда проекта поддерживает отличный веб-интерфейс Source Search на source.chromium.org. Там работают мгновенный поиск по символам, переход к объявлениям функций и просмотр истории изменений каждого файла.

Кодовая база Chromium пугает своими масштабами, но это один из самых структурированных проектов в индустрии. Даже поверхностное знакомство с каталогом docs/ и устройством подсистемы Blink помогает лучше понимать веб-платформу и писать более оптимизированный фронтенд-код.