Zajrzenie pod maskę Chromium i wyjaśnienie, dlaczego zwykły git clone tutaj nie zadziała

Jeśli kiedykolwiek próbowałeś uruchomić polecenie git clone https://github.com/chromium/chromium.git, prawdopodobnie po kilku minutach tego żałowałeś. Rozmiar repozytorium urósł do ponad 60 gigabajtów, a README wita cię zwięzłym ostrzeżeniem: nie rób tego za pomocą zwykłego git.

Chromium jest fundamentem dobrych połowy aplikacji desktopowych na naszych komputerach. Zasila Google Chrome, Microsoft Edge, Brave, Operę, desktopowego klienta Telegram, VS Code i Slacka poprzez Electron. Jednak repozytorium projektu na GitHubie to tylko publiczne mirrorowanie wewnętrznej infrastruktury Google. Przyjrzyjmy się, jak zbudowany jest ten potężny projekt, jak się po nim poruszać i dlaczego zwykły inżynier miałby potrzebować zaglądać do jego kodu źródłowego.

Dlaczego standardowy workflow tutaj nie działa

Większość projektów open source jest skonfigurowana w ten sam sposób: sklonuj repozytorium, zainstaluj zależności, otwórz edytor i utwórz pull request. Z Chromium tak to nie działa.

Nie ma tu znajomej zakładki Issues ani sekcji Pull Requests na GitHubie. Cały rozwój odbywa się przez wewnętrzny system Gerrit pod adresem chromium-review.googlesource.com, a błędy są śledzone na dedykowanym portalu pod adresem crbug.com.

Aby pobrać kod źródłowy na lokalną maszynę, zespół projektowy opracował własny zestaw narzędzi o nazwie depot_tools. Znajduje się w nim narzędzie gclient, które zarządza setkami zależności, bibliotek zewnętrznych i kompilatorów krzyżowych. samo repozytorium jest duże, ale wraz z pełną historią commitów, toolchainem i zależnościami do kompilacji potrzebujesz około 100 gigabajtów wolnego miejsca na szybkim SSD i co najmniej 16 gigabajtów 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

Jeśli spróbujesz zbudować cały projekt na typowym laptopie z czterema rdzeniami, kompilator będzie maxował wszystkie rdzenie przez kilka godzin. Aby przyspieszyć kompilację, inżynierowie Chromium używają rozproszonego systemu kompilacji i cache'owania o nazwie Reclient, w połączeniu z własnym systemem budowania GN (Generate Ninja) sparowanym z Ninja.

Jak zorganizowana jest struktura katalogów

Gdy otworzysz główny folder Chromium, oczy zaczną ci się kręcić. Wewnątrz znajdują się miliony linii kodu w C++, Rust, Python, Java i JavaScript. Dokumentacja opisuje ścisłe zasady organizacji katalogów:

1. src/content — rdzeń przeglądarki. Tutaj zaimplementowany jest wieloprocesowy silnik: zarządzanie kartami, izolowane piaskownice renderowania, obsługa żądań sieciowych i mechanizmy bezpieczeństwa.
2. src/third_party/blink — silnik renderowania stron (fork WebKit). Tutaj znajdują się implementacje specyfikacji HTML i CSS, wraz z parsowaniem drzewa DOM i obliczeniami układu.
3. src/v8 — silnik JavaScript i WebAssembly. W repozytorium Chromium jest dołączony jako zewnętrzna zależność.
4. src/chrome — sam kod przeglądarki Chrome. Obejmuje interfejs użytkownika, zakładki, rozszerzenia, profile użytkowników i ustawienia.

Oprócz tych czterech głównych bloków budulcowych, projekt zawiera katalog components/ z modułami, które można wykorzystać ponownie w różnych produktach, takich jak Android WebView czy powłoka Ash dla ChromeOS.

Co interesującego kryje się w architekturze

Chromium jest interesujący nie tylko jako gotowa przeglądarka, ale także jako przykład niesamowicie złożonej architektury systemu. W bazie kodu znajdują się odpowiedzi na pytania, które pojawiają się podczas czytania specyfikacji internetowych.

Wieloprocesowy model i piaskownice

Przeglądarka jest celowo podzielona na izolowane procesy. Proces przeglądarki zarządza oknami i danymi wejściowymi użytkownika, proces sieciowy obsługuje pobieranie zasobów, a procesy renderera wyświetlają strony.

Jeśli skrypt na karcie się zawiesi lub strona wywoła krytyczny błąd pamięci, tylko ten konkretny proces renderera ulegnie awarii — przeglądarka będzie nadal działać. Mechanizmy izolacji są implementowane osobno dla każdego systemu operacyjnego poprzez przestrzenie nazw Linuksa i wywołania systemowe seccomp-bpf lub poziomy integralności Windows.

Komunikacja międzyprocesowa przez Mojo

Ponieważ różne części przeglądarki żyją w izolowanych procesach, potrzebują szybkiego, bezpiecznego typowo mechanizmu komunikacji. Chromium używa do tego systemu Mojo.

Deweloperzy opisują interfejsy w plikach .mojom, a generator kodu tworzy powiązania dla C++, Javy i JS. Chroni to przed przekazywaniem nieprawidłowych typów danych między niezaufanym procesem renderera a uprzywilejowanym procesem przeglądarki.

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

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

Dlaczego frontendowcy i programiści systemowi powinni czytać ten kod

Może się wydawać, że zwykły web developer nie ma powodu, żeby grzebać w kodzie źródłowym C++. Ale w praktyce kod źródłowy Chromium jest najdokładniejszym źródłem prawdy o tym, jak przeglądarka interpretuje twoje strony.

Oto cztery realne scenariusze, w których kod projektu się przydaje:

• Debugowanie złożonych błędów przeglądarki. Gdy CSS Grid lub Flexbox zachowuje się dziwnie w Chrome, ale specyfikacja W3C jest mętnie napisana, możesz otworzyć kod w src/third_party/blink/renderer/core/layout i przeanalizować matematykę stojącą za obliczeniami rozmiaru pudełek.
• Poznanie działania Web API. Wszystkie metody JavaScript przeglądarki, jak IntersectionObserver, WebSockets czy ServiceWorker, mają bezpośredni odpowiednik w kodzie Blink. Czytając ich implementację, od razu rozumiesz, które operacje generują obciążenie pamięci i CPU.
• Tworzenie osadzonych przeglądarek. Jeśli musisz osadzić renderowanie stron internetowych we własnej aplikacji C++ lub Rust, Chromium Embedded Framework (CEF) opiera się na publicznych interfejsach w src/content.
• Znajdowanie przykładów kodu systemów wysokiego obciążenia. Tutaj można znaleźć implementacje niestandardowych alokatorów pamięci (PartitionAlloc), algorytmów kompresji, strumieniowych protokołów sieciowych i prymitywów kryptograficznych.

Od czego zacząć naukę

Jeśli interesuje cię tylko przeglądanie kodu źródłowego, nie musisz wydawać 100 gigabajtów miejsca na dysku. Do wyszukiwania kodu zespół projektowy udostępnia doskonały interfejs webowy o nazwie Source Search pod adresem source.chromium.org. Oferuje błyskawiczne wyszukiwanie symboli, nawigację do deklaracji funkcji i przeglądanie historii zmian dowolnego pliku.

Baza kodu Chromium jest onieśmielająca swoją skalą, ale to jeden z najlepiej zorganizowanych projektów w branży. Nawet powierzchowna znajomość katalogu docs/ i podsystemu Blink pomaga lepiej zrozumieć platformę webową i pisać bardziej zoptymalizowany kod frontendowy.