└── README.md /README.md: -------------------------------------------------------------------------------- 1 | # Chromium архитектура 2 | 3 | Chromium — графический веб-браузер с открытым исходным кодом, основанный на движке Blink и разрабатываемый корпорацией Google совместно с сообществом The Chromium Authors и некоторыми другими корпорациями. На основе Chromium создан браузер Google Chrome, на сегодняшний день его доля превысила 60%. Поэтому хотелось бы поговорить о нем чуть больше, чем об остальных, хотя про Firefox, Edge, Safari и их организацию было бы тоже здорово посмотреть, но не сегодня. Отмечу, что не стоит под Chromium подразумевать Google Chrome, так как одно определение дополняет другое. Google Chrome = Chromium + Google Update + закрытые плагины и кодеки + отправка отчетов и статистики. 4 | 5 | 6 | - Общая схема 7 | ![img](https://hsto.org/getpro/habr/post_images/930/d37/40b/930d3740bad95d2c9c7cd5f8694705bb.png) 8 | 9 | Chromium / Chrome — это многопроцессорный браузер, если только он не запускается с опцией командной строки --single-process. Все процессы в браузере имеют разные обязанности, но есть некоторые вещи, которые являются общими для всех процессов: 10 | 11 | 1. Все процессы имеют внутренний цикл, который обрабатывает аннотацию задачи и связь с другими процессами; 12 | 2. Процессы взаимодействуют друг с другом посредством сообщений. Для достижения этой цели используются структуры IPC и Mojo. 13 | 14 | Существует от 2 до 5 особо важных типов процесса (в зависимости от платформы). «Browser process» (процесс браузера) является основным процессом на всех платформах. Этот процесс является точкой входа приложения. Другим важным процессом, который доступен на всех платформах при работе в многопроцессорном режиме, является «Renderer process» (процесс рендеринга). Существует также «Utility process» (утилитный процесс), который выполняется на короткий промежуток времени, но выполняет важные задачи инициализации. В системах на базе ядра Linux есть также вспомогательный под названием «Zygote process» (протопроцесс). И последний, но не менее важный: если аппаратное ускорение доступно в системе, то появляется дополнительный процесс, называемый «GPU process» (процесс аппаратного ускорения). 15 | 16 | 17 | - Browser process 18 | 19 | Как упоминалось ранее, «Browser process» является процессом запуска. Он также называется брокерским процессом, поскольку он имеет определенные привилегии, например, запуск или контроль за действиями других процессов (например, изолированных процессов). 20 | 21 | «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. 22 | 23 | - Zygote process 24 | 25 | Как упоминалось, в системах на базе ядра Linux, существует специальный процесс, называемый «Zygote process». Он создается при запуске, а затем из него выделяются необходимые процессы, такие как «Renderer process». Он имеет внутренний цикл, как и любой другой процесс в Chromium. Выполненные операции вызываются из объекта TaskAnnotator или TaskRunner. «Zygote process» имеет много обязанностей, включая разбор документов, задачи планирования, декодирования ресурсов, запуск сценариев, запуск задач компоновщика. На других платформах, где «Zygote process» не используется, эти задачи выполняются немедленно другим процессом, все на себя берет «Renderer process». 26 | 27 | Как известно из школьного курса биологии, зигота — это оплодотворенная и готовая к развитию яйцеклетка. Но в нашем случае, это имеет глубинный смысл. Ведь в Chrome каждая вкладка и каждое расширение — это отдельный процесс. Одна из важных особенностей Chrome — прозрачное автоматическое обновление. Допустим, во время работы браузера обновилась какая-то разделяемая библиотека. Затем пользователь открывает новую вкладку, запускается новый процесс для рендеринга страницы. Если просто делать exec бинарника с диска, то новый процесс подхватит уже новую библиотеку, которая может быть несовместима с той, что была при старте основного процесса браузера. Чтобы этого избежать, при первом запуске Chrome запускает протопроцесс (зиготу), который затем будет ответвляться (fork) каждый раз, когда нужно запустить новый процесс рендеринга. Таким образом, все последующие копии будут иметь один и тот же набор библиотек, который был при запуске браузера. Сам процесс-зигота ничего не делает, просто висит в памяти и ждет команды, чтобы разделиться и дать жизнь новой вкладке. 28 | 29 | - Renderer process 30 | 31 | В системах на базе ядра Linux «Renderer process» порождается из «Zygote process», на других платформах он создается отдельно, в то же время он также является целевым процессом. «Renderer process» может существовать несколько, и они могут работать одновременно (в Chrome/Chromium, на одну вкладку один «Renderer process»). Другим важным свойством процесса является то, что он изолирован песочницей, поэтому любой потенциально опасный веб-сайт не может навредить системе. «Renderer process» является многопоточным. Он порождает следующие потоки: «I/O thread» (поток ввода-вывода), «Compositor thread» (поток композиции) и «Raster thread» (поток растеризации). Помимо основных обязанностей, связанных с песочницей (IPC песочницы, основной движок песочницы, диспетчер перехватов), данный процесс вызывает ScriptController и движок V8. 32 | 33 | - Utility process 34 | 35 | В системах на базе ядра Linux «Utility process» порождается из «Browser process». «Utility process» создается сразу после запуска браузера. Он выполняет необходимые инициализации и завершает работу после их завершения. Он инициализирует ResourceBundle, icu и V8 Engine. Он также занимается извлечением расширений. «Utility process» может появляться многократно во время работы браузера. Например, добавление нового расширения вызывает обращение к уже созданному «Utility process», который обрабатывает интеграцию нового расширения с браузером. 36 | 37 | - GPU process 38 | 39 | Пятый тип процесса, который следует упомянуть это процесс GPU. Он существует только в том случае, если аппаратное ускорение доступно в вашей системе. Этот процесс отвечает за общение с графическим процессором, его самой важной задачей является пересылка команд GL/GLES на графический процессор. Другие обязанности этого процесса: работа с шейдерами, текстурами, буфером. 40 | 41 |

Browser process

42 | 43 | ![image](http://szeged.github.io/sprocket/img/arch/Browser_Process.png) 44 | 45 | - **Startup** 46 | - Это точка входа всего приложения (Main) 47 | - Main запускает ContentMain и BrowserMain 48 | - BrowserMain запускает MainMessageLoop 49 | 50 | - **Threads** 51 | 52 | - Сразу после запуска запускаются необходимые потоки 53 | - **I/O thread** 54 | - Обеспечивает коммуникацию с задачами рендеринга 55 | - **DB thread** 56 | - Подключение базы данных sqlite и выполнение запросов 57 | - **Cache thread** 58 | - Хранение и извлечение кеша 59 | - **Worker threads** 60 | - Рабочие потоки запускают задачи, которые не требуют отдельных потоков или собственного цикла сообщений (event loop) 61 | - Существует пул потоков, называемый WorkerPool, который динамически добавляет потоки (при необходимости) для обработки всех задач 62 | - Существуют различные реализации для POSIX и не-POSIX-систем 63 | 64 | - **Loop** 65 | - MainMessageLoop 66 | - Используется для обработки событий определенного потока 67 | - Помещает входящие сообщения, а также задачи в очередь 68 | - Выдает задачу из очереди и запускает ее 69 | - Обеспечивает прочное соединениние с IPC 70 | - Имеет защиту от повторной установки задачи 71 | - Повторная задача не может быть запущена до завершения предыдущей задачи 72 | 73 | - **IPC / Mojo** 74 | - Это структура, используемая для межпроцессного взаимодействия 75 | - Подключается непосредственно к MainMessageLoop 76 | - Предоставляет каналы связи, через которые могут быть отправлены сообщения 77 | - Обеспечивает создание, отправку и получение сообщений 78 | - Обеспечивает асинхронную обработку сообщений 79 | 80 | - **TaskAnnotator** 81 | - Все входящие задачи проходят через TaskAnnotator, который аннотирует задачу перед выполнением 82 | - Реализует общие отладочные аннотации для размещенных задач. Сюда входят такие данные, как происхождение задачи, длительность очередей и использование памяти 83 | - Выполняет ранее поставленную задачу 84 | 85 | - **ResourceLoader** 86 | - Диспетчеризация ресурсов 87 | - Получает запросы от дочерних процессов (Renderer, Worker и т.д.) 88 | - Отправляет полученные запросы в URLRequests 89 | - Пересылает сообщения из URLRequests в корректный процесс обработки 90 | 91 | - **URL** 92 | - Эта группа содержит все соответствующие URL-адреса 93 | - Производит замену URL и/или расширяет URL-адреса 94 | - Автозаполнение URL 95 | - Извлечение поисковых запросов из URL-адреса 96 | - Разбор URL 97 | - Обеспечивает нормализацию (канонизация) URL 98 | - Использование Omnibox (многофункциональная адресная строка Chromium) 99 | 100 | - **SQL** 101 | - Включает наборв классов, которые взаимодействуют с базой данных sqlite3 102 | - Загрузка/обновление url при автозаполнении 103 | - Загрузка сохраненных favicons 104 | 105 | - **net** 106 | - Работа с NetworkDelegate 107 | - Выполняет действия до запуска URLRequest 108 | - Работа с URLRequests 109 | - Обработка файлов cookie 110 | - Загружает асинхронно все файлы cookie для заданного URL-адреса 111 | - Устанавливает все файлы cookie для данного URL-адреса 112 | - Работа с SSL-сертификатами 113 | - Обрабатывает действия, связанные с SSL 114 | - Подтверждение SSL 115 | - Подтверждение сертификации 116 | - Проверка подписи 117 | 118 | - **Compositor (cc)** 119 | - PaintFrame 120 | - Прорисовка основного кадра 121 | - Подготовка тайлов 122 | - Обновление слоев кадра 123 | - Обновление дополнительных слоев изображения 124 | - Работа со списком отображения обновлений (отрисовка, обновление) 125 | - Вызов ауры изображения 126 | - Работа с интерфейсным стеком Aura для работы с вкладками браузера 127 | 128 | - Swap 129 | - Работа с 2D-плоскостью 130 | - Работа со swap-буфером 131 | 132 | - RasterTask 133 | - Выполнение растеризации 134 | - Представление задач отрисовки в виде графа: 135 | - грани: это зависимости 136 | - узлы: являются задачами, вес узла определяет ее приоритет 137 | - Элементы в из списка отображения выводятся на 2D-плоскость 138 | - Растеризация вызывает определенные функции Skia, чтобы правильно отрисовать текущий холст (drawColor, drawPicture, drawRect, fillRect, и т.д.) 139 | 140 | - **X11/Windows/Mac** 141 | - Захватывание событий мыши, клавиатуры и передача их Chromium 142 | 143 | - **UIEvent** 144 | - Работа с классами представленными в пространстве имен ui (обеспечивают работу с пользовательским интерфейсом) 145 | - Одной из важных обязанностей является обработка событий пользовательского интерфейса, например, mousemove, mouseclick, keypress и т. д. 146 | - Эти события передаются из библиотеки рабочего окна 147 | - События попадают в цепочку обработки событий 148 | - Если пользователь вводит URL-адрес в адресную строку (URLBar), эти классы выполняют вставку символов в текстовое поле URLBar 149 | - Aura: 150 | - UI framework, диспетчер окон рабочего стола и среды оболочки 151 | - Кроссплатформенный 152 | - Также используется в качестве графической оболочки для Chrome OS / Chrome / Chromium 153 | - Используется Chrome OS, а также Chrome / Chromium 154 | - Aura обеспечивает взаимодействие окон и разных типов событий, контролирует поведение 155 | 156 |


157 |
158 | 159 |

Zygote process

160 | 161 | ![image](http://szeged.github.io/sprocket/img/arch/Zygote_Process.png) 162 | 163 | - **Startup** 164 | - Запускается после запуска родительского процесса "Browser process" 165 | 166 | - **Zygote** 167 | - После запуска родительского процесса создается Zygote-процесс 168 | 169 | - **Fork** 170 | - Zygote-процесс разветвляется (forked), чтобы создать процессы Renderer 171 | 172 | - **Loop** 173 | - MainMessageLoop 174 | - Используется для обработки событий определенного потока 175 | - Помещает входящие сообщения, а также задачи в очередь 176 | - Выдает задачу из очереди и запускает ее 177 | - Обеспечивает прочное соединениние с IPC 178 | - Имеет защиту от повторной установки задачи 179 | - Повторная задача не может быть запущена до завершения предыдущей задачи 180 | 181 | - **IPC / Mojo** 182 | - Это структура, используемая для межпроцессного взаимодействия 183 | - Подключается непосредственно к MainMessageLoop 184 | - Предоставляет каналы связи, через которые могут быть отправлены сообщения 185 | - Обеспечивает создание, отправку и получение сообщений 186 | - Обеспечивает асинхронную обработку сообщений 187 | 188 | - **TaskAnnotator** 189 | - Все входящие задачи проходят через TaskAnnotator, который аннотирует задачу перед выполнением 190 | - Реализует общие отладочные аннотации для размещенных задач. Сюда входят такие данные, как происхождение задачи, длительность очередей и использование памяти 191 | - Выполняет ранее поставленную задачу 192 | 193 | - **callback** 194 | - Этот блок представляет собой обратные вызовы, связанные с системой или сообщением 195 | 196 | - **Scheduler** 197 | - Пакет, который содержит набор классов работающих по расписанию 198 | - TaskQueueManager 199 | - Диспетчер очереди задач предоставляет N очередей задач и интерфейс селектора для выбора задачи из очереди. Каждая очередь задач состоит из двух дополнительных очередей: 200 | - Входящая очередь задач 201 | - Рабочая очередь 202 | 203 | - **blink::HTMLDocumentParser** 204 | - Парсинг HTML-документа 205 | - Построение дерева DOM 206 | 207 | - **autofill** 208 | - AutofillAgent занимается связью с Autofill, связанной между WebKit и браузером 209 | - Подсчет APR (AutofillAgent per RenderFrame) 210 | - Autofill охватывает: 211 | - Работа с Autocomplete 212 | - Работа с заполнением формы пароля, называемой автозаполнением пароля, и заполнение всей формы на основе одной записи поля, называемого формой автозаполнения. 213 | 214 | - **icu** 215 | - Это библиотека для работы с unicode в том числе содержит ряд инструментов для сравнения строк, получения даты и времени в самых разных форматах 216 | - В текущем контексте icu используется для сопоставления шаблонов регулярных выражений, чтобы определить, соответствует ли автозаполнение конкретному регулярному выражению 217 | 218 | - **content::ResourceDispatcher** 219 | - Этот комопонент служит интерфейсом для связи с диспетчером ресурсов 220 | - Он может использоваться из любого дочернего процесса 221 | - Отправляет входящие сообщения 222 | 223 | - **blink::TimerBase** 224 | - Базовый таймер 225 | 226 | - **blink::FrameLoader** 227 | - Управляет загрузкой определенного кадра (страницы) 228 | 229 | - **blink::EventHandler** 230 | - Обрабатывает события, такие как выделение, перетаскивание, жесты, перемещение мыши, нажатия клавиатуры 231 | - Выполняет hit-тесты (hit detection, picking, pick correlation) 232 | 233 | - **blink::EventDispatcher** 234 | - Рассылает простые события, скоординированные события или имитируемые клики 235 | 236 | - **blink::Document** 237 | - blink::DocumentLoader отвечает за загрузку документа 238 | - После применения CSS стилей (blink::StyleResolver) и расчета макета обновляет графические слои 239 | 240 | - **media::DecoderStream** 241 | - Обертывает DemuxerStream и список декодеров, и предоставляет вывод для клиента (Audio/VideoRendererImpl) 242 | 243 | - **blink::ScriptRunner** 244 | - Выполнение JavaScript 245 | 246 | - **content::RenderThread** 247 | - Поток, который используется для рендеринга задач в процессе Renderer и Zygote (запускается в однопоточном режиме) 248 | 249 | - **blink::V8Initializer** 250 | - Имеет только статические методы для инициализации контекста движка V8 251 | - В основном потоке 252 | - В рабочем потоке 253 | 254 | - **extensions** 255 | - Представляет собой extensions-модуль для работы с расширениями браузера 256 | - Реализует основные части расширения Chrome и может взаимодействовать с любым content-модулем 257 | 258 | - **blink::WorkerThread** 259 | - Поток, который может выполнять только определенные задачи 260 | - Определенные задачи могут быть отправлены в WorkerThread 261 | - Вызывает WorkerScriptController::initializeContextifNeeded для выполнения JavaScript посредством V8 262 | 263 | - **Compositor (cc)** 264 | - Использует несколько хранилищ резервных копий для кэширования и группировки фрагментов дерева рендеринга 265 | - Избегает ненужной перерисовки 266 | - Выполняет первичные задачи компоновки: 267 | - Определяет, как группировать содержимое в резервном хранилище (композитные слои) 268 | - Выполнение закрашивания каждого композитного слоя 269 | - Отрисовка окончательного изображения 270 | - Отрисовывает содержимое слоев из списка отображения 271 | - Обрабатывает обновления слоев 272 | 273 | - **Skia** 274 | - Использование Blink-библиотек отрисовки 275 | - Растеризация вызывает определенные функции Skia, для правильной отрисовки холста (drawColor, drawPicture, drawRect, fillRect и т.д.) 276 | 277 | - **blink::ImageDecoder** 278 | - ImageDecoder является основой для всех декодеров изображений, специфичных для определенных форматов (например, JPEGImageDecoder). Он управляет кэшем ImageFrame. 279 | 280 | - **content::WebGraphicsContext3DCommandBuffer** 281 | - Выполнение методов 3D отрисовки для графики 282 | - Отправляет инструкции в GpuChannelHost, которые: 283 | - Инкапсулирует IPC-канал между клиентом и одним GPU 284 | - На стороне GPU имеется соответствующий GpuChannel 285 | - Каждый метод может быть вызван в любом потоке, за исключением потока ввода-вывода 286 | 287 | - **RasterTask** 288 | - Выполнение растеризации 289 | - Представление задач отрисовки в виде графа: 290 | - грани: это зависимости 291 | - узлы: являются задачами, вес узла определяет их приоритет 292 | - Растеризация вызывает gpu::gles2::QueryTracker методы для создания запросов к графическому процессору 293 | 294 | - **gpu::gles2** 295 | - QueryTracker 296 | - Отслеживает запросы клиентской части командного буфера 297 | - QueryManager 298 | - Отслеживает запросы и их состояние, поскольку запросы не используются, есть один QueryManager для каждого контекста 299 | - Отправляет запросы в content::CommandBufferProxyImpl 300 | - Это клиентский прокси-сервер, который синхронно пересылает сообщения в CommandBufferStub 301 | 302 |

303 |
304 | 305 |

Renderer process

306 | 307 | ![image](http://szeged.github.io/sprocket/img/arch/Renderer_Process.png) 308 | 309 | - **Startup** 310 | - Запускается после запуска родительского процесс "Browser process" (и запущенного Zygote-процесс) 311 | 312 | - **Renderer** 313 | - Renderer-процесс является разветвлением (forked) Zygote-процесса 314 | 315 | - **Loop** 316 | - MainMessageLoop 317 | - Используется для обработки событий определенного потока 318 | - Помещает входящие сообщения, а также задачи в очередь 319 | - Выдает задачу из очереди и запускает ее 320 | - Стабильное соединениние с IPC 321 | - Имеет защиту от повторной установки задачи 322 | - Повторная задача не может быть запущена до завершения предыдущей задачи 323 | 324 | - **IPC / Mojo** 325 | - Это структура, используемая для межпроцессного взаимодействия 326 | - Подключается непосредственно к MainMessageLoop 327 | - Предоставляет каналы связи, через которые могут быть отправлены сообщения 328 | - Обеспечивает создание, отправку и получение сообщений 329 | - Обеспечивает асинхронную обработку сообщений 330 | 331 | - **TaskAnnotator** 332 | - Все входящие задачи проходят через TaskAnnotator, который аннотирует задачу перед выполнением 333 | - Реализует общие отладочные аннотации для размещенных задач. Сюда входят такие данные, как происхождение задачи, длительность очередей и использование памяти 334 | - Выполняет ранее поставленную задачу 335 | 336 | - **Scheduler** 337 | - Пакет, который содержит набор классов, работающих по расписанию 338 | - TaskQueueManager 339 | - Диспетчер очереди задач предоставляет N очередей задач и интерфейс селектора для выбора задачи из очереди. Каждая очередь задач состоит из двух дополнительных очередей: 340 | - Входящая очередь задач 341 | - Рабочая очередь 342 | 343 | - **content::MessageRouter** 344 | - MessageRouter обрабатывает все входящие сообщения, отправленные ему, перенаправляя их правильному подписчику, основываясь на идентификаторе маршрутизации сообщения 345 | - Маршрутизация основана на идентификаторе маршрутизации сообщения 346 | - Поскольку идентификаторы маршрутизации обычно назначаются асинхронно в процессе работы браузера, MessageRouter имеет ожидающие идентификаторы для подписчиков, которым еще не присвоен идентификатор маршрутизации 347 | 348 | - **content::RenderWidget** 349 | - RenderWidget обеспечивает коммуникационный мост между WebWidget и RenderWidgetHost, последний из которых работает в другом процессе 350 | - Обрабатывает входящее сообщение в методе OnMessageReceived 351 | - Обрабатывает входящие события в цепочке blink::handleInputEvent 352 | - В случае, наведения курсора мыши на требуемый элемент, срабатывает соответствующее событие, у которого установлен tooltip, выполняется hit-тест 353 | - Отправляет ответы через IPC 354 | 355 | - **content::InputHandler** 356 | - content::InputHandlerManager 357 | - Управляет экземплярами InputHandlerProxy для WebView в рендеринге 358 | - content::InputHandlerProxy 359 | - Этот класс является прокси-сервером, фильтрирующим события ввода и обработки композиции. Экземпляры InputHandlerProxy полностью связаны с потоком компоновщика. Каждый экземпляр InputHandler обрабатывает входные события, предназначенные для определенного WebWidget 360 | - Вызывает конкретные функции Compositor компонента в результате входного события 361 | 362 | - **Compositor (cc)** 363 | - Compositor вызывает конкретные функции gfx и GL/GLES для выполнения правильной отрисовки 364 | 365 | - **blink::ScriptController** 366 | - Интерпретирует JavaScript и получает возвращаемое значение через объект V8ScriptRunner 367 | 368 | - **V8** 369 | - Это JavaScript-движок встроенный в Blink 370 | - JavaScript 371 | - Парсит 372 | - Компилирует 373 | - Выполняет 374 | - Выполняет обратные вызовы для изменения DOM-дерева 375 | - Работает с памятью 376 | - Выделение памяти 377 | - Сборка мусора 378 | 379 |


380 |
381 | 382 |

Utility process

383 | 384 | ![image](http://szeged.github.io/sprocket/img/arch/Utility_process.png) 385 | 386 | - **Startup** 387 | - Является точкой входа данного процесса 388 | 389 | - **Utility** 390 | - Представляет собой служебную утилиту 391 | 392 | - **Loop** 393 | - MainMessageLoop 394 | - Используется для обработки событий определенного потока 395 | - Помещает входящие сообщения, а также задачи в очередь 396 | - Выдает задачу из очереди и запускает ее 397 | - Обеспечивает прочное соединениние с IPC 398 | - Имеет защиту от повторной установки задачи 399 | - Повторная задача не может быть запущена до завершения предыдущей задачи 400 | 401 | - **IPC / Mojo** 402 | - Это структура, используемая для межпроцессного взаимодействия 403 | - Подключается непосредственно к MainMessageLoop 404 | - Предоставляет каналы связи, через которые могут быть отправлены сообщения 405 | - Обеспечивает создание, отправку и получение сообщений 406 | - Обеспечивает асинхронную обработку сообщений 407 | 408 | - **Extensions** 409 | - ExtensionsHandler 410 | - Отправляет в IPC служебные сообщения расширений Chrome 411 | - UtilityHandler 412 | - Является обработчиком для входящих сообщений IPC, связанных с расширениями, из внутренних процессов 413 | - unpack extensions 414 | - extensions::Unpacker 415 | - Этот класс распаковывает расширения 416 | - Он предназначен для использования расширения в изолированном дочернем процессе 417 | - Различные биты расширения анализируются, затем сообщаются обратно в родительский процесс, который затем перекодирует предварительно разобранные биты и записывает их обратно на диск для последующего использования 418 | 419 | - **ResourceBundle** 420 | - Инициализирует ResourceBundle 421 | - Возвращает выбранную локализацию 422 | 423 | - **icu** 424 | - Инициализирует icu 425 | - Создает TimeZone по умолчанию 426 | 427 | - **V8Initializer** 428 | - Инициализирует V8 429 | - Загружает нативные библиотеки V8 430 | 431 | 432 |


433 |
434 | 435 |

GPU process

436 | 437 | ![image](http://szeged.github.io/sprocket/img/arch/GPU_Process.png) 438 | 439 | 440 | - **Startup** 441 | - Является точкой входа процесса для работы GPU 442 | 443 | - **Loop** 444 | - MainMessageLoop 445 | - Используется для обработки событий определенного потока 446 | - Помещает входящие сообщения, а также задачи в очередь 447 | - Выдает задачу из очереди и запускает ее 448 | - Обеспечивает прочное соединениние с IPC 449 | - Имеет защиту от повторной установки задачи 450 | - Повторная задача не может быть запущена до завершения предыдущей задачи 451 | 452 | - **IPC / Mojo** 453 | - Это структура, используемая для межпроцессного взаимодействия 454 | - Подключается непосредственно к MainMessageLoop 455 | - Предоставляет каналы связи, через которые могут быть отправлены сообщения 456 | - Обеспечивает создание, отправку и получение сообщений 457 | - Обеспечивает асинхронную обработку сообщений 458 | 459 | - **TaskAnnotator** 460 | - Все входящие задачи проходят через TaskAnnotator, который аннотирует задачу перед выполнением 461 | - Реализует общие отладочные аннотации для размещенных задач. Сюда входят такие данные, как происхождение задачи, длительность очередей и использование памяти 462 | - Выполняет ранее поставленную задачу 463 | 464 | - **GPU Command Buffer** 465 | - Реализует методы IPC (прием, передача) 466 | - Обрабатывает сообщения (Set/Get buffer, Flush, Create/Destroy Images и т.д.) и отправляет команды 467 | 468 | - **gfx::GLSurface** 469 | - Инкапсулирует поверхность, которую можно визуализировать с помощью GL, скрывая управление платформой 470 | 471 | - **gfx::GLContext** 472 | - Инкапсулирует контекст OpenGL, скрывая конкретное управление платформой 473 | 474 | - **GLES2 Decoder** 475 | - Декодирует команды GLES2 из командного буфера 476 | - Вызывает методы GL 477 | 478 | - **Shader, Texture, …, Draw elements** 479 | - Вызывает функции OpenGL 480 | - Компилирует и выполняет шейдерные коды 481 | - Манипулирует текстурами (bind, remove, setTarget и т. д.) 482 | - Выполняет другие вызовы состояния GLContext 483 | 484 | - **Swap buffers** 485 | - Обрабатывает swap кадров 486 | - Если буфер выключен, то отображаемый кадр копируется в другой фреймбуфер 487 | --------------------------------------------------------------------------------