движок браузерного рендеринга

задний план

Ядро браузера в основном делится на движок рендеринга и движок javascript.Эта статья в основном знакомит с принципом работы браузера вокруг движка рендеринга.

Во-первых, давайте посмотрим на несколько строк пользовательского агента:

Mozilla/ 1.0 (Windows NT 6.1;rv:2.0.1) Gecko/2010010Firefox/4.0.1
Mozilla/ 4. 0 (compatible; MSIE 7. 0; Windows NT 6. 0)
Mozilla/ 5. 0 (Linux; Android4. 0. 4; Galaxy Nexus Build/ IMM76B) AppleWebKit/ 535. 19 (KHTML, like Gecko) Chrome/ 18. 0. 1025. 133 Mobile Safari/ 535.

Это юзер-агент для 3 разных браузеров, первый для Firefox, второй для IE7 и третий для Chrome. Вы никогда не задумывались, почему все строки начинаются с Mozilla? И Chrome содержит много других логотипов браузеров, Android, Gecko, Safari..., почему эти производители браузеров создают такую строку пользовательского агента? Согласно обычному пониманию, пользовательский агент — это идентификатор браузера, включая операционную систему и информацию о браузере с номером версии.Почему производители браузеров так усложняют его?

Это нужно знатьистория строк пользовательского агента, примерно означает, что пользовательский агент раннего браузера NetscapeMozilla/Version [Language] (Platform; Encryption)Format, большинство серверов проверяют, является ли пользовательский агент браузером перед загрузкой страницы, но в 1995 году IE выпустил первый браузер, если он не совместим со строкой пользовательского агента Netscape, пользователь вообще не может получить доступ к странице. , поэтому IE разработал этот формат:Mozilla/2.0 (compatible; MSIE Version; Operating System). То же самое верно и для других новых выпусков браузеров, чтобы интегрироваться в основной поток и не быть выкинутым, поместите подробную информацию в строку пользовательского агента, чтобы обмануть веб-сайт и сделать его совместимым с другими популярными браузерами.

Далее краткий обзор истории браузера:

WorldWideWeb 1991
Мозаика 1993
Нетскейп 1994
Опера 1995
IE 1995 Первая мировая война
Сафари 2003
Firefox 2004 Вторая мировая война
Хром 2008
Край 2015

Многие думают, что самым ранним браузером является Netscape. На самом деле до Netscape существовало два браузера, WorldWideWeb и Mosaic. WorldWideWeb — это первый браузер в мире. Он также является редактором. http Версия по-прежнему 0.9 и поддерживает только запросы на получение.

Затем в 1993 году организованная NCSA Университета штата Иллинойс в штате Иллинойс, США, выпустила первый браузер, способный отображать картинки, под названием Mosaic. Затем NCSA перепродало права на коммерческую эксплуатацию Mosaic компании Spyglass, которая, в свою очередь, передала лицензию на технологию ряду компаний, включая Microsoft, и здесь появился браузер Microsoft IE.

В 1994 году, как основной член команды разработчиков браузера Mosaic, компания Netscape была восстановлена, и родился браузер Netscape.

В 1995 году местная норвежская телекоммуникационная компания Telenor разработала новый браузер Opera. Браузер Opera характеризуется высокой скоростью, но не очень хорошей совместимостью. Он создал множество функций в браузере. Например, просмотр с вкладками — это изобретение Opera. Да, Opera была приобретена Qihoo 360 в 2016 году после многих взлетов и падений.

В том же 1995 году, получив исходный код и авторизацию Spyglass Mosaic, Microsoft выпустила первый браузер Internet Explorer, с которого началась первая браузерная война.

В 1998 году внутри Netscape была создана организация Mozilla.

В 2003 году Apple выпустила свой первый браузер Safari, а два года спустя, в 2005 году, открыла исходный код собственного ядра браузера Webkit.

В 2004 году организация Mozilla выпустила браузер Firefox, и тогда началась вторая браузерная война.

2008 год был годом многих бедствий.Было сильное землетрясение в провинции Сычуань.Когда я возвращался домой на Новый год, я столкнулся со снежной катастрофой.Как фронтенд-разработчик, я начну быть совместимым с новым Браузер Chrome, разработанный Google. Но опыт, который приносит Chrome, доставляет удовольствие.

В 2015 году Microsoft выпустила браузер Edge вместе с Windows 10, а IE, который разбил всем сердца, считается непригодным для сопровождения.

Текущая доля браузеров на рынке — это браузер Chrome, за которым следуют IE и Firefox.Подробности см. в статистике Net Marketshare.

ядро браузера

ядро	браузер	год рождения	JS-движок	Открытый исходный код
Trident	IE4 - IE11	1997	JScript, чакра (ie9+)
Gecko	Firefox	2004	SpiderMonkey	MPL
WebKit	Safari, Chromium, Chrome (-2013), браузер Android, ChromeOS, WebOS и т. д.	2005	JavascriptCore	BSD
Blink	Chrome, Opera	2013	V8	GPL
Edge	Edge	2015	Chakra	MIT(chakra)

Браузеры на рынке имеют свои собственные ядра, и некоторые из ядер все еще имеют некоторые отношения между собой. WebKit – это ядро с открытым исходным кодом, выпущенное Apple в 2005 году. Сначала Apple использовала KHTML, а KHTML поддерживался сообществом KDE. Техническая группа Apple также участвовала в разработке KHTML, но в процессе разработки сообществу KDE не понравилась команда Apple.Отправил код. Так люди Apple стали независимыми, создали ядро WebKit на основе KHTML и сделали его открытым исходным кодом в 2005 году. В 2008 году Google выпустил браузер Chrome, который также использует ядро Webkit.При этом техническая команда также участвовала в разработке проекта WebKit, но были разногласия с командой Apple в дизайне, поэтому люди Google стали независимый и разработанный Blink на базе WebKit.Kernel, Blink добавляет многопроцессорность, песочницу и многие другие технологии на основе Webkit.

Хочешь быть совместим с отечественной банковской системой - переходи на ядро Trident.Хочешь скорость доступа - переходи на ядро Webkit. После выхода Blink замени WebKit стал Blink.

Браузер QQ Trident+Webkit (Blink)
360 Secure Browser Trident + Webkit (Blink)
Браузер Cheetah Trident+Webkit (Blink)
Окно в мир Trident+Webkit (Blink)
Скоростной браузер Sogou Trident+Webkit (Blink)
Браузер UC Trident+Webkit (Blink)
....

Архитектура вебкита

Далее входим в Webkit, сначала смотрим на схему архитектуры WebKit

На приведенном выше рисунке часть сплошной линии, то есть WebCore, в основном используется различными браузерами, а часть пунктирной линии различается в каждом браузере. WebCore — это механизм рендеринга, включающий интерпретатор HTML, интерпретатор CSS и обрабатывающий рендеринг макета страницы и другие функции. JavascriptCore — это механизм Javascript, встроенный в WebKit. На верхнем уровне находятся встроенные интерфейсы WebKit, которые предназначены для вызовов браузера, но на рисунке мы видим два встроенных интерфейса, WebKit и WebKit2.В чем разница между ними?

WebKit 2 был выпущен в апреле 2010 года, абстрагируя новый набор программных интерфейсов для использования разработчиками и в то же время используя несколько процессов: процесс пользовательского интерфейса, процесс, который обрабатывает интерфейс между веб-платформой и браузером, еще один веб-процесс. , Процесс рендеринга веб-страницы. Изоляция веб-процесса от процесса пользовательского интерфейса дает преимущества с точки зрения надежности, безопасности и лучшего использования многоядерных процессоров. Ниже приведено сравнение WebKit и WebKit2:

Подробнее можно прочитать: https://trac.webkit.org/wiki/WebKit2

Большой областью рядом с Javascript является порт Webkit.Так называемый порт WebKit не имеет точной формы, его можно рассматривать как комбинацию ОС, платформы (среды приложений), механизма Javacsript и различных сторонних библиотек. WebKit Port предоставляет различные интерфейсы порта для использования внешними программами,

Вокруг Webkit есть много портов:

Apple's Mac Port
Apple's Windows Port
Cairo-based Windows Port
JSCOnly Port
WebKitGTK+ Port
QTWebKit
...

Порты WebKit обычно служат следующим целям:

Используйте WebKit в качестве ядра анализа страниц, макета и рендеринга для браузеров (или аналогичных пользовательских агентов), таких как Safari, Chrome.
Инкапсулируйте WebKit и предоставьте интерфейс API для создания браузера (или аналогичного UA), такого как Qt.
Оба вышеперечисленных, такие как Android, iOS, BlackBerry

У разных портов разные проблемы

Порт Mac фокусируется на разделении браузера и операционной системы и встраивает механизм рендеринга (WebKit) в собственные приложения через код Obj-C и C++.
Порт Chromium ориентирован на браузер.
QtWebKit использует свою реализацию WebKit в качестве библиотеки времени выполнения или механизма рендеринга вместе со своей кросс-платформенной инфраструктурой приложений с графическим интерфейсом для использования другими приложениями. Например, безголовый браузер Phantomjs реализован на основе QtWebKit.

Подробнее можно прочитать: https://trac.webkit.org/wiki#WebKitPorts

Далее давайте взглянем на браузеры, основанные на порте Chromium.

На рисунке мы видим, что в левом нижнем углу находится ядро WebKit, и оно находится на том же уровне, что и:

GPU/Command Buffer, Command Buffer — это средство связи для потоков GPU, обеспечивающее аппаратное ускорение GPU.
V8, движок Javascript
Модель песочницы, дизайн защиты безопасности браузера
CC (композитор Chromium), раздельный рендеринг RenderLayer Tree
IPC,UI,PPAPI ...

Верхний уровень — это контент.Если контента нет, он может отображаться в обычном режиме, но вышеупомянутые функции, такие как ускорение графического процессора, модель песочницы, HTML 5 и т. д., будут недоступны. API контента предоставляет открытый и стабильный интерфейс, и цель состоит в том, чтобы поддерживать все функции, такие как функции HTML5 и аппаратное ускорение графического процессора.

«Браузер Chromium» и «ContentShell» — это два «браузера», построенные поверх ContentAPI. Chromium обладает полной функциональностью браузера, то есть стилем браузера, который мы видим при его компиляции. И «ContentShell» — это простая «оболочка», обернутая ContentAPI, но это также и простой «браузер», пользователи могут использовать модуль Content для рендеринга и отображения веб-контента. Роль ContentShell очевидна, его можно использовать для проверки корректности многих функций модуля Content, таких как рендеринг, аппаратное ускорение и т. д. Различные типы проектов.

В системе Android ContentShell играет большую роль, потому что код в части «Браузер Chromium» слева рядом с ним вообще не является открытым исходным кодом, что напрямую заставляет разработчиков полагаться на ContentShell.

«Android WebView», который предназначен для соответствия WebView в системе Android, идея состоит в том, чтобы использовать реализацию Chromium для замены стандартного WebView исходной системы Android.

процесс рендеринга

Ниже приведены механизмы рендеринга браузера и зависимые модули.

Механизм рендеринга в основном включает интерпретатор HTML, интерпретатор CSS, механизм макета и JavaScript и т. Д. Механизм JavaScript теперь независим. Ниже приведены зависимые модули, включая сетевые ресурсы, хранилище, 2D/3D-графику, аудио и видео, декодеры изображений и т. д., а ниже представлена поддержка, связанная с операционной системой.

Общий процесс рендеринга и диаграмма взаимосвязей модулей зависимостей выглядит следующим образом:

Далее давайте подробно рассмотрим процесс рендеринга в WebKit:

Во-первых, после того, как браузер вводит URL-адрес, он полагается на сетевой модуль для загрузки различных ресурсов для получения HTML-кода. HTML-код передается анализатору HTML для анализа, и, наконец, создается дерево DOM. процесс повторного анализа, он будет передан движку Javascript для обработки. , обработка завершена и возвращена в дерево DOM. Основная цель этой ссылки - построить дерево DOM.

Затем взгляните на дерево DOM в контексте рисования.

После того, как код CSS будет получен в сетевом ресурсе, CSS будет передан парсеру CSS для обработки, при этом будет просчитан макет. Дерево DOM будет встроено в дерево RenderObject, которое соответствует узлам дерева DOM один к одному, а затем объединено и проанализировано с проанализированным CSS для создания дерева RenderLayer, которое является окончательным деревом для рендеринга, а затем рисует контекст.

Ниже приведены несколько изображений, найденных в Интернете, которые кратко объясняют окончательный процесс преобразования дерева DOM в дерево RenderLayer.

Этот простой HTML-код, который содержит такие элементы, как body, сценарий div canvas и т. д., анализируется синтаксическим анализатором HTML и CSS, и, наконец, будет сгенерировано дерево RenderLayer. Синтезатор CC упоминался на диаграмме архитектуры Chromium. Расширенные возможности аппаратного обеспечения графического процессора, в том числе на многих небольших устройствах, позволили браузерам ускорить рендеринг, используя преимущества своей графической производительности. Вместо того, чтобы рисовать все слои вместе, слои визуализируются, компонуются, а затем отображаются на экране.

Структура дерева RenderLayer ниже показывает, что все дерево разделено на 3 слоя.Под слоем находятся узлы рендеринга, такие как RenderBlock и RenderText.Координаты, размер и цвет фона, содержащиеся в каждом узле, зависят от рендеринга. .

RenderBlock на самом деле является элементом уровня блока в нашем HTML. Мы все знаем, что элемент блочного уровня можно изменить с помощью CSS. Следовательно, структура дерева RenderLayer также будет меняться в соответствии с изменениями CSS. затронутого элемента Изменения будут пересчитаны по всему дереву, что мы называем обратным потоком. Объяснение перекомпоновки см. по адресу: https://www-archive.mozilla.org/newlayout/doc/reflow.html.

Наконец, давайте кратко рассмотрим Shadow DOM. В процессе разработки интерфейса все знают, что React, Vue и эти фреймворки имеют концепцию компонентов. На странице много повторяющихся компонентов и много основных элементов HTML. внутри компонента.Эти элементы могут образовывать поддерево дерева DOM. Такой компонент можно использовать везде, но проблема в том, что каждое место, где используется компонент, будет знать структуру этого поддерева. Когда разработчику веб-страницы необходимо получить доступ к дереву DOM веб-страницы, поддерево DOM внутри этих элементов управления будет открыто.Эти открытые узлы могут не только создать много проблем для обхода дерева DOM, но также могут вызвать выбор стиля CSS.Проблемы, потому что селекторы могут непреднамеренно изменить стили этих внутренних узлов, что приведет к очень странному интерфейсу.

Есть ли способ инкапсулировать эти внутренние узлы? Точно так же, как мы пишем модульность javascript, рабочая группа W3C придумала концепцию Shadow DOM, например, в поддержке HTML5.<Video>Внутри тегов, таких как воспроизведение и пауза, есть много сложных структур, но мы не можем напрямую найти соответствующие узлы в дереве DOM для таких кнопок, как воспроизведение и пауза.Это собственно и есть идея Shadow DOM. Shadow DOM можно настроить и создать с помощью Javascript, и он может поддерживать внутри себя собственный DOM, CSS, события и т. Д. С хорошей герметизацией. Custom Shadow DOM в настоящее время поддерживается только Chrome, но я верю, что Shadow DOM принесет больше удовольствия при разработке компонентов в ближайшем будущем.

использованная литература

"Инсайдер технологии WebKit"
Расшифровка браузера http://www.nowamagic.net/academy/part/48/115/#
WebKit Wiki https://trac.webkit.org/wiki

Оригинальный адрес: http://blog.hypers.io/2018/04/04/webkit-render/