splincode / chromium-architecture

Перевод схемы архитектуры chromium

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Chromium архитектура

Chromium — графический веб-браузер с открытым исходным кодом, основанный на движке Blink и разрабатываемый корпорацией Google совместно с сообществом The Chromium Authors и некоторыми другими корпорациями. На основе Chromium создан браузер Google Chrome, на сегодняшний день его доля превысила 60%. Поэтому хотелось бы поговорить о нем чуть больше, чем об остальных, хотя про Firefox, Edge, Safari и их организацию было бы тоже здорово посмотреть, но не сегодня. Отмечу, что не стоит под Chromium подразумевать Google Chrome, так как одно определение дополняет другое. Google Chrome = Chromium + Google Update + закрытые плагины и кодеки + отправка отчетов и статистики.

  • Общая схема img

Chromium / Chrome — это многопроцессорный браузер, если только он не запускается с опцией командной строки --single-process. Все процессы в браузере имеют разные обязанности, но есть некоторые вещи, которые являются общими для всех процессов:

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

Существует от 2 до 5 особо важных типов процесса (в зависимости от платформы). «Browser process» (процесс браузера) является основным процессом на всех платформах. Этот процесс является точкой входа приложения. Другим важным процессом, который доступен на всех платформах при работе в многопроцессорном режиме, является «Renderer process» (процесс рендеринга). Существует также «Utility process» (утилитный процесс), который выполняется на короткий промежуток времени, но выполняет важные задачи инициализации. В системах на базе ядра Linux есть также вспомогательный под названием «Zygote process» (протопроцесс). И последний, но не менее важный: если аппаратное ускорение доступно в системе, то появляется дополнительный процесс, называемый «GPU process» (процесс аппаратного ускорения).

  • Browser process

Как упоминалось ранее, «Browser process» является процессом запуска. Он также называется брокерским процессом, поскольку он имеет определенные привилегии, например, запуск или контроль за действиями других процессов (например, изолированных процессов).

«Browser process» генерирует отдельные потоки, чтобы упростить основные функции. Существует поток ввода-вывода, который отвечает за связь с «Renderer thread». Пользовательский интерфейс представляет собой основной поток процесса браузера, который гарантирует обработку событий в пользовательском интерфейсе браузера. Режимы DB, File и Cache отвечают за обработку соединений и запросов к базе данных, операций с файлами и управление кэшем, соответственно. Существует дополнительный поток «Process Launcher thread», который необходим для создания или развития новых процессов, например, процесса Zygote или GPU. Помимо упомянутых выше потоков, «Browser process» также порождает так называемые «Worker thread» (рабочие потоки). Рабочие потоки занимаются необходимыми задачами (такими как поиск DNS) и являются частью коллекции потоков «WorkerPool». Помимо обработки процессов и потоков, «Browser process» имеет много других важных обязательств. Его самая важная роль — управление песочницей. Песочница — специально выделенная среда для безопасного исполнения. Песочницы представляют собой пример виртуализации. В «Browser process» размещаются такие службы как движок песочницы, диспетчер перехвата и служба IPC. Эти службы способны выполнять действия от имени целевого процесса, разрешенные политикой. «Browser process» также отвечает за работу с сетевыми ресурсами и запросами URL.

  • Zygote process

Как упоминалось, в системах на базе ядра Linux, существует специальный процесс, называемый «Zygote process». Он создается при запуске, а затем из него выделяются необходимые процессы, такие как «Renderer process». Он имеет внутренний цикл, как и любой другой процесс в Chromium. Выполненные операции вызываются из объекта TaskAnnotator или TaskRunner. «Zygote process» имеет много обязанностей, включая разбор документов, задачи планирования, декодирования ресурсов, запуск сценариев, запуск задач компоновщика. На других платформах, где «Zygote process» не используется, эти задачи выполняются немедленно другим процессом, все на себя берет «Renderer process».

Как известно из школьного курса биологии, зигота — это оплодотворенная и готовая к развитию яйцеклетка. Но в нашем случае, это имеет глубинный смысл. Ведь в Chrome каждая вкладка и каждое расширение — это отдельный процесс. Одна из важных особенностей Chrome — прозрачное автоматическое обновление. Допустим, во время работы браузера обновилась какая-то разделяемая библиотека. Затем пользователь открывает новую вкладку, запускается новый процесс для рендеринга страницы. Если просто делать exec бинарника с диска, то новый процесс подхватит уже новую библиотеку, которая может быть несовместима с той, что была при старте основного процесса браузера. Чтобы этого избежать, при первом запуске Chrome запускает протопроцесс (зиготу), который затем будет ответвляться (fork) каждый раз, когда нужно запустить новый процесс рендеринга. Таким образом, все последующие копии будут иметь один и тот же набор библиотек, который был при запуске браузера. Сам процесс-зигота ничего не делает, просто висит в памяти и ждет команды, чтобы разделиться и дать жизнь новой вкладке.

  • Renderer process

В системах на базе ядра Linux «Renderer process» порождается из «Zygote process», на других платформах он создается отдельно, в то же время он также является целевым процессом. «Renderer process» может существовать несколько, и они могут работать одновременно (в Chrome/Chromium, на одну вкладку один «Renderer process»). Другим важным свойством процесса является то, что он изолирован песочницей, поэтому любой потенциально опасный веб-сайт не может навредить системе. «Renderer process» является многопоточным. Он порождает следующие потоки: «I/O thread» (поток ввода-вывода), «Compositor thread» (поток композиции) и «Raster thread» (поток растеризации). Помимо основных обязанностей, связанных с песочницей (IPC песочницы, основной движок песочницы, диспетчер перехватов), данный процесс вызывает ScriptController и движок V8.

  • Utility process

В системах на базе ядра Linux «Utility process» порождается из «Browser process». «Utility process» создается сразу после запуска браузера. Он выполняет необходимые инициализации и завершает работу после их завершения. Он инициализирует ResourceBundle, icu и V8 Engine. Он также занимается извлечением расширений. «Utility process» может появляться многократно во время работы браузера. Например, добавление нового расширения вызывает обращение к уже созданному «Utility process», который обрабатывает интеграцию нового расширения с браузером.

  • GPU process

Пятый тип процесса, который следует упомянуть это процесс GPU. Он существует только в том случае, если аппаратное ускорение доступно в вашей системе. Этот процесс отвечает за общение с графическим процессором, его самой важной задачей является пересылка команд GL/GLES на графический процессор. Другие обязанности этого процесса: работа с шейдерами, текстурами, буфером.

Browser process

image

  • Startup

    • Это точка входа всего приложения (Main)
    • Main запускает ContentMain и BrowserMain
    • BrowserMain запускает MainMessageLoop
  • Threads

    • Сразу после запуска запускаются необходимые потоки
    • I/O thread
      • Обеспечивает коммуникацию с задачами рендеринга
    • DB thread
      • Подключение базы данных sqlite и выполнение запросов
    • Cache thread
      • Хранение и извлечение кеша
    • Worker threads
      • Рабочие потоки запускают задачи, которые не требуют отдельных потоков или собственного цикла сообщений (event loop)
      • Существует пул потоков, называемый WorkerPool, который динамически добавляет потоки (при необходимости) для обработки всех задач
      • Существуют различные реализации для POSIX и не-POSIX-систем
  • Loop

    • MainMessageLoop
      • Используется для обработки событий определенного потока
      • Помещает входящие сообщения, а также задачи в очередь
      • Выдает задачу из очереди и запускает ее
      • Обеспечивает прочное соединениние с IPC
      • Имеет защиту от повторной установки задачи
        • Повторная задача не может быть запущена до завершения предыдущей задачи
  • IPC / Mojo

    • Это структура, используемая для межпроцессного взаимодействия
    • Подключается непосредственно к MainMessageLoop
    • Предоставляет каналы связи, через которые могут быть отправлены сообщения
    • Обеспечивает создание, отправку и получение сообщений
    • Обеспечивает асинхронную обработку сообщений
  • TaskAnnotator

    • Все входящие задачи проходят через TaskAnnotator, который аннотирует задачу перед выполнением
    • Реализует общие отладочные аннотации для размещенных задач. Сюда входят такие данные, как происхождение задачи, длительность очередей и использование памяти
    • Выполняет ранее поставленную задачу
  • ResourceLoader

    • Диспетчеризация ресурсов
    • Получает запросы от дочерних процессов (Renderer, Worker и т.д.)
    • Отправляет полученные запросы в URLRequests
    • Пересылает сообщения из URLRequests в корректный процесс обработки
  • URL

    • Эта группа содержит все соответствующие URL-адреса
    • Производит замену URL и/или расширяет URL-адреса
    • Автозаполнение URL
    • Извлечение поисковых запросов из URL-адреса
    • Разбор URL
    • Обеспечивает нормализацию (канонизация) URL
    • Использование Omnibox (многофункциональная адресная строка Chromium)
  • SQL

    • Включает наборв классов, которые взаимодействуют с базой данных sqlite3
    • Загрузка/обновление url при автозаполнении
    • Загрузка сохраненных favicons
  • net

    • Работа с NetworkDelegate
      • Выполняет действия до запуска URLRequest
    • Работа с URLRequests
    • Обработка файлов cookie
      • Загружает асинхронно все файлы cookie для заданного URL-адреса
      • Устанавливает все файлы cookie для данного URL-адреса
    • Работа с SSL-сертификатами
      • Обрабатывает действия, связанные с SSL
      • Подтверждение SSL
      • Подтверждение сертификации
      • Проверка подписи
  • Compositor (cc)

    • PaintFrame

      • Прорисовка основного кадра
      • Подготовка тайлов
      • Обновление слоев кадра
      • Обновление дополнительных слоев изображения
      • Работа со списком отображения обновлений (отрисовка, обновление)
      • Вызов ауры изображения
      • Работа с интерфейсным стеком Aura для работы с вкладками браузера
    • Swap

      • Работа с 2D-плоскостью
      • Работа со swap-буфером
    • RasterTask

      • Выполнение растеризации
      • Представление задач отрисовки в виде графа:
        • грани: это зависимости
        • узлы: являются задачами, вес узла определяет ее приоритет
      • Элементы в из списка отображения выводятся на 2D-плоскость
      • Растеризация вызывает определенные функции Skia, чтобы правильно отрисовать текущий холст (drawColor, drawPicture, drawRect, fillRect, и т.д.)
  • X11/Windows/Mac

    • Захватывание событий мыши, клавиатуры и передача их Chromium
  • UIEvent

    • Работа с классами представленными в пространстве имен ui (обеспечивают работу с пользовательским интерфейсом)
    • Одной из важных обязанностей является обработка событий пользовательского интерфейса, например, mousemove, mouseclick, keypress и т. д.
    • Эти события передаются из библиотеки рабочего окна
    • События попадают в цепочку обработки событий
    • Если пользователь вводит URL-адрес в адресную строку (URLBar), эти классы выполняют вставку символов в текстовое поле URLBar
    • Aura:
      • UI framework, диспетчер окон рабочего стола и среды оболочки
      • Кроссплатформенный
      • Также используется в качестве графической оболочки для Chrome OS / Chrome / Chromium
      • Используется Chrome OS, а также Chrome / Chromium
      • Aura обеспечивает взаимодействие окон и разных типов событий, контролирует поведение





Zygote process

image

  • Startup

    • Запускается после запуска родительского процесса "Browser process"
  • Zygote

    • После запуска родительского процесса создается Zygote-процесс
  • Fork

    • Zygote-процесс разветвляется (forked), чтобы создать процессы Renderer
  • Loop

    • MainMessageLoop
      • Используется для обработки событий определенного потока
      • Помещает входящие сообщения, а также задачи в очередь
      • Выдает задачу из очереди и запускает ее
      • Обеспечивает прочное соединениние с IPC
      • Имеет защиту от повторной установки задачи
        • Повторная задача не может быть запущена до завершения предыдущей задачи
  • IPC / Mojo

    • Это структура, используемая для межпроцессного взаимодействия
    • Подключается непосредственно к MainMessageLoop
    • Предоставляет каналы связи, через которые могут быть отправлены сообщения
    • Обеспечивает создание, отправку и получение сообщений
    • Обеспечивает асинхронную обработку сообщений
  • TaskAnnotator

    • Все входящие задачи проходят через TaskAnnotator, который аннотирует задачу перед выполнением
    • Реализует общие отладочные аннотации для размещенных задач. Сюда входят такие данные, как происхождение задачи, длительность очередей и использование памяти
    • Выполняет ранее поставленную задачу
  • callback

    • Этот блок представляет собой обратные вызовы, связанные с системой или сообщением
  • Scheduler

    • Пакет, который содержит набор классов работающих по расписанию
    • TaskQueueManager
      • Диспетчер очереди задач предоставляет N очередей задач и интерфейс селектора для выбора задачи из очереди. Каждая очередь задач состоит из двух дополнительных очередей:
        • Входящая очередь задач
        • Рабочая очередь
  • blink::HTMLDocumentParser

    • Парсинг HTML-документа
    • Построение дерева DOM
  • autofill

    • AutofillAgent занимается связью с Autofill, связанной между WebKit и браузером
    • Подсчет APR (AutofillAgent per RenderFrame)
    • Autofill охватывает:
      • Работа с Autocomplete
      • Работа с заполнением формы пароля, называемой автозаполнением пароля, и заполнение всей формы на основе одной записи поля, называемого формой автозаполнения.
  • icu

    • Это библиотека для работы с unicode в том числе содержит ряд инструментов для сравнения строк, получения даты и времени в самых разных форматах
    • В текущем контексте icu используется для сопоставления шаблонов регулярных выражений, чтобы определить, соответствует ли автозаполнение конкретному регулярному выражению
  • content::ResourceDispatcher

    • Этот комопонент служит интерфейсом для связи с диспетчером ресурсов
    • Он может использоваться из любого дочернего процесса
    • Отправляет входящие сообщения
  • blink::TimerBase

    • Базовый таймер
  • blink::FrameLoader

    • Управляет загрузкой определенного кадра (страницы)
  • blink::EventHandler

    • Обрабатывает события, такие как выделение, перетаскивание, жесты, перемещение мыши, нажатия клавиатуры
    • Выполняет hit-тесты (hit detection, picking, pick correlation)
  • blink::EventDispatcher

    • Рассылает простые события, скоординированные события или имитируемые клики
  • blink::Document

    • blink::DocumentLoader отвечает за загрузку документа
    • После применения CSS стилей (blink::StyleResolver) и расчета макета обновляет графические слои
  • media::DecoderStream

    • Обертывает DemuxerStream и список декодеров, и предоставляет вывод для клиента (Audio/VideoRendererImpl)
  • blink::ScriptRunner

    • Выполнение JavaScript
  • content::RenderThread

    • Поток, который используется для рендеринга задач в процессе Renderer и Zygote (запускается в однопоточном режиме)
  • blink::V8Initializer

    • Имеет только статические методы для инициализации контекста движка V8
      • В основном потоке
      • В рабочем потоке
  • extensions

    • Представляет собой extensions-модуль для работы с расширениями браузера
    • Реализует основные части расширения Chrome и может взаимодействовать с любым content-модулем
  • blink::WorkerThread

    • Поток, который может выполнять только определенные задачи
    • Определенные задачи могут быть отправлены в WorkerThread
    • Вызывает WorkerScriptController::initializeContextifNeeded для выполнения JavaScript посредством V8
  • Compositor (cc)

    • Использует несколько хранилищ резервных копий для кэширования и группировки фрагментов дерева рендеринга
    • Избегает ненужной перерисовки
    • Выполняет первичные задачи компоновки:
      • Определяет, как группировать содержимое в резервном хранилище (композитные слои)
      • Выполнение закрашивания каждого композитного слоя
      • Отрисовка окончательного изображения
    • Отрисовывает содержимое слоев из списка отображения
    • Обрабатывает обновления слоев
  • Skia

    • Использование Blink-библиотек отрисовки
    • Растеризация вызывает определенные функции Skia, для правильной отрисовки холста (drawColor, drawPicture, drawRect, fillRect и т.д.)
  • blink::ImageDecoder

    • ImageDecoder является основой для всех декодеров изображений, специфичных для определенных форматов (например, JPEGImageDecoder). Он управляет кэшем ImageFrame.
  • content::WebGraphicsContext3DCommandBuffer

    • Выполнение методов 3D отрисовки для графики
    • Отправляет инструкции в GpuChannelHost, которые:
      • Инкапсулирует IPC-канал между клиентом и одним GPU
      • На стороне GPU имеется соответствующий GpuChannel
      • Каждый метод может быть вызван в любом потоке, за исключением потока ввода-вывода
  • RasterTask

    • Выполнение растеризации
    • Представление задач отрисовки в виде графа:
      • грани: это зависимости
      • узлы: являются задачами, вес узла определяет их приоритет
    • Растеризация вызывает gpu::gles2::QueryTracker методы для создания запросов к графическому процессору
  • gpu::gles2

    • QueryTracker
      • Отслеживает запросы клиентской части командного буфера
    • QueryManager
      • Отслеживает запросы и их состояние, поскольку запросы не используются, есть один QueryManager для каждого контекста
    • Отправляет запросы в content::CommandBufferProxyImpl
      • Это клиентский прокси-сервер, который синхронно пересылает сообщения в CommandBufferStub




Renderer process

image

  • Startup

    • Запускается после запуска родительского процесс "Browser process" (и запущенного Zygote-процесс)
  • Renderer

    • Renderer-процесс является разветвлением (forked) Zygote-процесса
  • Loop

    • MainMessageLoop
      • Используется для обработки событий определенного потока
      • Помещает входящие сообщения, а также задачи в очередь
      • Выдает задачу из очереди и запускает ее
      • Стабильное соединениние с IPC
      • Имеет защиту от повторной установки задачи
        • Повторная задача не может быть запущена до завершения предыдущей задачи
  • IPC / Mojo

    • Это структура, используемая для межпроцессного взаимодействия
    • Подключается непосредственно к MainMessageLoop
    • Предоставляет каналы связи, через которые могут быть отправлены сообщения
    • Обеспечивает создание, отправку и получение сообщений
    • Обеспечивает асинхронную обработку сообщений
  • TaskAnnotator

    • Все входящие задачи проходят через TaskAnnotator, который аннотирует задачу перед выполнением
    • Реализует общие отладочные аннотации для размещенных задач. Сюда входят такие данные, как происхождение задачи, длительность очередей и использование памяти
    • Выполняет ранее поставленную задачу
  • Scheduler

    • Пакет, который содержит набор классов, работающих по расписанию
    • TaskQueueManager
      • Диспетчер очереди задач предоставляет N очередей задач и интерфейс селектора для выбора задачи из очереди. Каждая очередь задач состоит из двух дополнительных очередей:
        • Входящая очередь задач
        • Рабочая очередь
  • content::MessageRouter

    • MessageRouter обрабатывает все входящие сообщения, отправленные ему, перенаправляя их правильному подписчику, основываясь на идентификаторе маршрутизации сообщения
    • Маршрутизация основана на идентификаторе маршрутизации сообщения
    • Поскольку идентификаторы маршрутизации обычно назначаются асинхронно в процессе работы браузера, MessageRouter имеет ожидающие идентификаторы для подписчиков, которым еще не присвоен идентификатор маршрутизации
  • content::RenderWidget

    • RenderWidget обеспечивает коммуникационный мост между WebWidget и RenderWidgetHost, последний из которых работает в другом процессе
    • Обрабатывает входящее сообщение в методе OnMessageReceived
    • Обрабатывает входящие события в цепочке blink::handleInputEvent
    • В случае, наведения курсора мыши на требуемый элемент, срабатывает соответствующее событие, у которого установлен tooltip, выполняется hit-тест
    • Отправляет ответы через IPC
  • content::InputHandler

    • content::InputHandlerManager
      • Управляет экземплярами InputHandlerProxy для WebView в рендеринге
    • content::InputHandlerProxy
      • Этот класс является прокси-сервером, фильтрирующим события ввода и обработки композиции. Экземпляры InputHandlerProxy полностью связаны с потоком компоновщика. Каждый экземпляр InputHandler обрабатывает входные события, предназначенные для определенного WebWidget
      • Вызывает конкретные функции Compositor компонента в результате входного события
  • Compositor (cc)

    • Compositor вызывает конкретные функции gfx и GL/GLES для выполнения правильной отрисовки
  • blink::ScriptController

    • Интерпретирует JavaScript и получает возвращаемое значение через объект V8ScriptRunner
  • V8

    • Это JavaScript-движок встроенный в Blink
    • JavaScript
      • Парсит
      • Компилирует
      • Выполняет
    • Выполняет обратные вызовы для изменения DOM-дерева
    • Работает с памятью
      • Выделение памяти
      • Сборка мусора





Utility process

image

  • Startup

    • Является точкой входа данного процесса
  • Utility

    • Представляет собой служебную утилиту
  • Loop

    • MainMessageLoop
      • Используется для обработки событий определенного потока
      • Помещает входящие сообщения, а также задачи в очередь
      • Выдает задачу из очереди и запускает ее
      • Обеспечивает прочное соединениние с IPC
      • Имеет защиту от повторной установки задачи
        • Повторная задача не может быть запущена до завершения предыдущей задачи
  • IPC / Mojo

    • Это структура, используемая для межпроцессного взаимодействия
    • Подключается непосредственно к MainMessageLoop
    • Предоставляет каналы связи, через которые могут быть отправлены сообщения
    • Обеспечивает создание, отправку и получение сообщений
    • Обеспечивает асинхронную обработку сообщений
  • Extensions

    • ExtensionsHandler
      • Отправляет в IPC служебные сообщения расширений Chrome
    • UtilityHandler
      • Является обработчиком для входящих сообщений IPC, связанных с расширениями, из внутренних процессов
    • unpack extensions
      • extensions::Unpacker
        • Этот класс распаковывает расширения
        • Он предназначен для использования расширения в изолированном дочернем процессе
        • Различные биты расширения анализируются, затем сообщаются обратно в родительский процесс, который затем перекодирует предварительно разобранные биты и записывает их обратно на диск для последующего использования
  • ResourceBundle

    • Инициализирует ResourceBundle
    • Возвращает выбранную локализацию
  • icu

    • Инициализирует icu
    • Создает TimeZone по умолчанию
  • V8Initializer

    • Инициализирует V8
      • Загружает нативные библиотеки V8





GPU process

image

  • Startup

    • Является точкой входа процесса для работы GPU
  • Loop

    • MainMessageLoop
      • Используется для обработки событий определенного потока
      • Помещает входящие сообщения, а также задачи в очередь
      • Выдает задачу из очереди и запускает ее
      • Обеспечивает прочное соединениние с IPC
      • Имеет защиту от повторной установки задачи
        • Повторная задача не может быть запущена до завершения предыдущей задачи
  • IPC / Mojo

    • Это структура, используемая для межпроцессного взаимодействия
    • Подключается непосредственно к MainMessageLoop
    • Предоставляет каналы связи, через которые могут быть отправлены сообщения
    • Обеспечивает создание, отправку и получение сообщений
    • Обеспечивает асинхронную обработку сообщений
  • TaskAnnotator

    • Все входящие задачи проходят через TaskAnnotator, который аннотирует задачу перед выполнением
    • Реализует общие отладочные аннотации для размещенных задач. Сюда входят такие данные, как происхождение задачи, длительность очередей и использование памяти
    • Выполняет ранее поставленную задачу
  • GPU Command Buffer

    • Реализует методы IPC (прием, передача)
    • Обрабатывает сообщения (Set/Get buffer, Flush, Create/Destroy Images и т.д.) и отправляет команды
  • gfx::GLSurface

    • Инкапсулирует поверхность, которую можно визуализировать с помощью GL, скрывая управление платформой
  • gfx::GLContext

    • Инкапсулирует контекст OpenGL, скрывая конкретное управление платформой
  • GLES2 Decoder

    • Декодирует команды GLES2 из командного буфера
    • Вызывает методы GL
  • Shader, Texture, …, Draw elements

    • Вызывает функции OpenGL
    • Компилирует и выполняет шейдерные коды
    • Манипулирует текстурами (bind, remove, setTarget и т. д.)
    • Выполняет другие вызовы состояния GLContext
  • Swap buffers

    • Обрабатывает swap кадров
    • Если буфер выключен, то отображаемый кадр копируется в другой фреймбуфер

About

Перевод схемы архитектуры chromium