Webkit браузеры что это

Обновлено: 06.07.2024

WebKit также является основой экспериментального браузера, включенного в электронную книгу Amazon Kindle, а также для браузера по умолчанию в Apple iOS, BlackBerry Browser в ОС 6 и выше и мобильных операционных систем Tizen. Интерфейс прикладного программирования (API) WebKit предоставляет набор классов для отображения веб-контента в окнах и реализует функции браузера, такие как следующие ссылки при нажатии пользователем, управление списком перемотки назад и управление историей недавно посещенных страниц.

HTML и JavaScript-код WebKit изначально были вилкой KHTML и KJS-библиотек от KDE и теперь были дополнительно разработаны людьми из KDE, Apple, Google, Nokia, Bitstream, BlackBerry, Igalia и других. macOS, Windows, Linux и некоторые другие UNIX-подобные операционные системы поддерживаются проектом. 3 апреля 2013 года компания Google объявила о том, что она использовала WebCore, компонент WebKit, который будет использоваться в будущих версиях Google Chrome и браузера Opera под названием Blink.

Содержание

Истоки

Код, который станет WebKit, начался в 1998 году как механизм компоновки KDE HTML (KHTML) и KDE JavaScript (KJS). Проект WebKit был начат в Apple от Дола Мелтона 25 июня 2001 года в качестве форком KHTML и KJS. Мелтон объяснил в электронном письме разработчикам KDE, что KHTML и KJS позволили упростить разработку, чем другие доступные технологии, благодаря небольшому (менее 140 000 строк кода), чисто разработанному и совместимому со стандартами. KHTML и KJS были перенесены в OS X с помощью библиотеки адаптеров и переименованы в WebCore и JavaScriptCore. JavaScriptCore был анонсирован в электронном письме в список рассылки KDE в июне 2002 года вместе с первой версией изменений Apple. WebCore был анонсирован на Macworld Expo в январе 2003 года генеральным директором Apple Стива Джобса с выпуском веб-браузера Safari. JavaScriptCore был впервые включен в Mac OS X 10.2 в качестве частной структуры, которую Apple использовала в своем приложении Sherlock, в то время как WebCore дебютировал с первой бета-версией Safari. Mac OS X 10.3 стала первой крупной версией операционной системы Apple для объединения WebKit, хотя она уже была выпущена с небольшим выпуском 10.2 [Источник 1] .

Согласно Apple, некоторые изменения включали специфические для OS X функции (например, Objective-C, KWQ, OS X-вызовы), которые отсутствуют в KHTML KDE, которые требуют различной тактики разработки.

Разделение разработки

Обмен кода между WebCore и KHTML стал все более трудным, поскольку база кода расходилась, потому что оба проекта имели разные подходы к кодированию и совместному использованию кода. В какой-то момент разработчики KHTML заявили, что вряд ли согласятся с изменениями Apple и заявили, что отношения между этими двумя группами были «горькой неудачей». Apple представила свои изменения в больших исправлениях, содержащих очень много изменений, с неадекватной документацией, часто связанной с будущими дополнениями. Таким образом, эти исправления были трудными для разработчиков KDE для интеграции обратно в KHTML. Кроме того, Apple потребовала от разработчиков подписывать соглашения о неразглашении, прежде чем смотреть на исходный код Apple, и даже тогда они не смогли получить доступ к базе данных ошибок Apple.

Во время опубликованного «развода» разработчик KDE Курт Пфайфл (pipitas) опубликовал статью, в которой разработчикам KHTML удалось заархивировать многие (но не все) улучшения Safari от WebCore до KHTML, и они всегда оценили улучшения, приходящие от Apple, и все еще делают так. В статье также отмечается, что Apple начала связываться с разработчиками KHTML о том, как улучшить взаимоотношения и пути будущего сотрудничества. Фактически, проект KDE смог включить некоторые из этих изменений, чтобы улучшить скорость рендеринга KHTML и добавить функции, включая соответствие с тестом на рендеринг Acid2.

Поскольку в новостях появилась новость о новостях, Apple опубликовала изменения исходного кода вилки WebKit в публичном репозитории контроля версий. Поскольку передача исходного кода в общедоступный репозиторий системы параллельных версий (CVS), разработчики Apple и KHTML расширяют сотрудничество. Многие разработчики KHTML стали рецензентами и отправителями для репозитория контроля версий WebKit.

Команда WebKit также отменила многие изменения, внесенные Apple в исходную базу кода WebKit, и реализовала уровни абстракции для конкретной платформы, чтобы значительно упростить передачу кода рендеринга ядра на другие платформы.

В июле 2007 года Ars Technica сообщила, что команда KDE переместится с KHTML на WebKit. Вместо этого, после нескольких лет интеграции, KDE Development Platform версии 4.5.0 была выпущена в августе 2010 года с поддержкой как WebKit, так и KHTML, а развитие KHTML продолжается.

Опенсорсинг

7 июня 2005 года разработчик Safari Дэйв Хаатт объявил в своем блоге, что Apple является открытым сайтом WebKit (ранее только WebCore и JavaScriptCore были с открытым исходным кодом) и открывали доступ к дереву контроля версий WebKit и к трекеру проблем. Об этом было объявлено на конференции Apple Worldwide Developers Conference 2005, старшим вице-президентом Apple по программной инженерии Бертраном Серлетом.

В середине декабря 2005 года поддержка масштабируемой векторной графики (SVG) была объединена с стандартной сборкой, а в начале января 2006 года исходный код был перенесен из системы параллельных версий (CVS) в Subversion (SVN) [Источник 2] .

Компоненты JavaScriptCore и WebCore от WebKit доступны в рамках лицензии GNU Lesser General Public License, а остальная часть WebKit доступна под лицензией BSD.

Дальнейшее развитие

Начиная с начала 2007 года команда разработчиков начала внедрять расширения Cascading Style Sheets (CSS), включая анимацию, переходы и 2D и 3D-преобразования, такие расширения были выпущены в качестве рабочих проектов в консорциум World Wide Web (W3C) в 2009 для стандартизации.

В ноябре 2007 года проект объявил о том, что он добавил поддержку мультимедийных функций спецификации черновика HTML5, позволяя встроенное видео визуально визуализироваться и контролироваться скриптом в WebKit.

2 июня 2008 года проект WebKit объявил, что они переработали JavaScriptCore как «SquirrelFish», интерпретатор байт-кода. Проект превратился в SquirrelFish Extreme (сокращенно SFX), объявленный 18 сентября 2008 года, который компилирует JavaScript в собственный машинный код, устраняя необходимость в интерпретаторе байт-кода и тем самым ускоряя выполнение JavaScript. Первоначально единственной поддерживаемой архитектурой процессора для SFX был x86, но в конце января 2009 года SFX был включен для OS X на x86-64, когда он прошел все тесты на этой платформе.

WebKit2

8 апреля 2010 года был анонсирован проект WebKit2 для перепроектирования WebKit. Цель состоит в том, чтобы абстрагироваться от компонентов, которые обеспечивают рендеринг веб-страниц, из своего окружающего интерфейса или оболочки приложения, создавая ситуацию, когда «веб-контент (JavaScript, HTML, макет и т.д.) Живет в отдельном процессе из пользовательского интерфейса приложения». Эта абстракция предназначена для повторного использования более простого процесса для WebKit2, чем для WebKit. WebKit2 имеет «несовместимое изменение API от исходного WebKit», которое мотивировало его изменение имени.

WebKit2 будет нацелен на MacOS, Windows, GTK+ и MeeGo-Harmattan. Safari для OS X переключился на новый API с версией 5.1. Safari для iOS переключился на WebKit2 с iOS 8.

Использование

Установленная база

Новые веб-браузеры были созданы вокруг WebKit, таких как браузер S60 на мобильных телефонах Symbian, браузере BlackBerry (версия 6.0+), Midori, браузере Chrome, в браузере Android до версии 4.4 KitKat и браузер, используемый в системном программном обеспечении PlayStation 3 версии 4.10. Веб-браузер KDE's Rekonq и Plasma Workspaces также используют его как собственный механизм рендеринга веб-страниц. WebKit был принят как движок рендеринга в OmniWeb, iCab и Web (ранее назывался Epiphany) и Sleipnir, заменив их исходные механизмы рендеринга. В течение некоторого времени веб-сайт GNOME поддерживал как Gecko, так и WebKit, но команда решила, что цикл выпуска Gecko и планы дальнейшего развития сделают его слишком громоздким, чтобы продолжать поддерживать его. WebOS использует WebKit в качестве основы для его времени выполнения. В последнем обновлении интерфейса для Steam Valve используется WebKit для отображения его интерфейса и встроенного браузера. WebKit используется для рендеринга HTML и запуска JavaScript на платформе приложений Adobe Integrated Runtime. В Adobe Creative Suite CS5 WebKit используется для отображения некоторых частей пользовательского интерфейса. По состоянию на первое полугодие 2010 года аналитик оценил совокупное количество мобильных телефонов, поставляемых с браузером на основе WebKit, на уровне 350 миллионов. К середине апреля 2015 года доля рынка браузера WebKit составляла 50,3%.

Порты

Через неделю после того, как Hyatt анонсировала open-sourcing от WebKit, Nokia объявила, что перенесла WebKit в операционную систему Symbian и разрабатывает браузер на основе WebKit для мобильных телефонов под управлением S60. Именованный веб-браузер для S60, он использовался на Nokia, Samsung, LG и других мобильных телефонах Symbian S60. Apple также перенесла WebKit на iOS для работы на iPhone, iPod Touch и iPad, где он используется для отображения контента в веб-браузере устройства и в программном обеспечении электронной почты. [50] Платформа Android для мобильных телефонов, использующая WebKit (и более поздние версии, ее вилка Blink) в качестве основы для своего веб-браузера, и Palm Pre, объявленная в январе 2009 года, имеет интерфейс на основе WebKit. Amazon Kindle 3 включает экспериментальный браузер на основе WebKit [Источник 3] .

В июне 2007 года Apple объявила, что WebKit был перенесен в Microsoft Windows как часть Apple.

WebKit также был перенесен на несколько наборов инструментальных средств, поддерживающих несколько платформ, таких как набор инструментов GTK+, Framework Qt, Adobe Integrated Runtime, библиотеки фонда Elight (EFL) и набор инструментов Clutter. Программное обеспечение Qt (принадлежащее Digia) включает Qt-порт в выпуске Qt 4.4. Порт Qt WebKit также доступен для использования в Konqueror с версии 4.1. Браузер Iris на Qt также использует WebKit. В качестве автономного браузера, виджетов-гаджетов, богатого текстового просмотра и композитора был разработан порт для проектов Efllenment Foundation Libraries (EFL) - EWebKit (Samsung и ProFusion), ориентированный на встроенные и мобильные системы. Порт Clutter разработан Collabora и спонсируется Robert Bosch GmbH.

Существует также проект, синхронизированный с WebKit (спонсируемый Pleyo) под названием Origyn Web Browser, который обеспечивает мета-порт абстрактной платформы с целью упрощения и упрощения переноса в внедренные или легкие системы. Этот порт используется для встроенных устройств, таких как телеприставки, PMP, и он был перенесен в AmigaOS, AROS и MorphOS. Версия MorphOS 1.7 - первая версия веб-браузера Origyn (OWB), поддерживающая мультимедийные теги HTML5.

Форк от Google

3 апреля 2013 года компания Google объявила о выпуске вилки компонента WebCit WebCore под названием Blink. Разработчики Chrome решили использовать форк, чтобы обеспечить большую свободу в использовании функций WebCore в браузере, не вызывая конфликтов вверх по течению, и чтобы упростить свою кодовую базу, удалив код для компонентов WebCore, не используемых Chrome. В связи с объявлением Opera Software в начале года, когда он переключился на WebKit с помощью базы данных Chromium, было подтверждено, что браузер Opera также переключится на Blink. После анонса, разработчики WebKit начали обсуждения по удалению кода, специфичного для Chrome, для оптимизации его кодовой базы. WebKit больше не имеет какого-либо конкретного кода [Google Chrome|Chrome]] (например, buildsystem, V8 JavaScript-движки, код платформы и т.д.).

Компоненты

WebCore

WebCore - это библиотека макета, рендеринга и Document Object Model (DOM) для HTML и масштабируемой векторной графики (SVG), разработанная проектом WebKit. Его полный исходный код лицензируется по лицензии GNU Lesser General Public License (LGPL). Рамка WebKit обертывает WebCore и JavaScriptCore, предоставляя интерфейс прикладного программирования Objective-Cции WebCore на базе C++ и движку сценария JavaScriptCore, позволяя легко ссылаться на приложения на основе API Cocoa; более поздние версии также включают в себя кросс-платформенную абстракцию платформы C++, а различные порты предоставляют больше API.

WebKit передает тесты Acid2 и Acid3 с идеальным рендерингом в пикселях и отсутствием сроков или проблем с гладкостью на эталонном оборудовании.

JavaScriptCore

JavaScriptCore - это среда, которая предоставляет механизм JavaScript для реализации WebKit и предоставляет этот тип сценариев в других контекстах в macOS. JavaScriptCore первоначально получен из библиотеки KDE JavaScript engine (KJS) (которая является частью проекта KDE) и библиотеки регулярных выражений PCRE. Начиная с разветвления с KJS и PCRE, JavaScriptCore был улучшен с множеством новых функций и значительно улучшил производительность.

13 мая 2014 года был анонсирован оптимизированный компилятор «точно в срок» (JIT) по имени FTL. Он использует LLVM для генерации оптимизированного машинного кода. «FTL» означает «Fourth-Tier-LLVM», а неофициально - быстрее, чем свет, ссылаясь на его скорость. По состоянию на 15 февраля 2016 года бэкэнд FTL JIT заменяется «Bare Bones Backend» (или B3 для краткости) [Источник 4] .

Доброго времени суток, Хабр! В очередной раз читая комментарии, наткнулся на мысль о том, что далеко не все понимают, как обстоит ситуация с браузерами для Windows на данный момент. От чего хотелось бы провести небольшой обзор текущего положения. Ну, и сразу к делу!

Браузерные движки

Браузер — программа не простая, это целый набор компонентов, взаимодействующих между собой. Для краткого обзора потребуются всего два компонента из множества — движок отрисовки содержимого и движок исполнения JavaScript.

Существующие движки отрисовки содержимого

Trident (так же известный как MSHTML) — движок, ранее разрабатываемый Microsoft для браузера Internet Explorer;
EdgeHTML — преемник Trident, ранее разрабатываемый Microsoft для браузера Legacy Edge (ранее просто Edge);
WebKit — движок, разрабатываемый Apple для браузера Safari;
Blink — преемник WebKit, разрабатываемый Google для браузера Chrome;
Gecko — движок, разрабатываемый Mozilla для браузера Firefox;
Servo — исследовательский проект Mozilla, некоторые технологии со временем перетекают в Gecko.

Существующие движки исполнения JavaScript

Chakra JScript — движок JS, ранее разрабатываемый Microsoft для браузера Internet Explorer;
Chakra JavaScript — преемник Chakra JScript, ранее разрабатываемый Microsoft для браузера Legacy Edge;
Nitro — движок JS, разрабатываемый Apple для браузера Safari;
V8 — движок JS, разрабатываемый Google для браузера Chrome;
SpiderMonkey — движок JS, разрабатываемый Mozilla для браузера Firefox.

И тут вроде бы очевидно, какие браузеры какие движки используют, но Microsoft внёс не много путаницы в понимание данной темы, поэтому рассмотрим браузеры отдельно.

Браузеры

Chromium

Chromium — это open-source ответвление браузера Chrome. Браузеры на основе Chromium составляют большую часть из всех используемых браузеров на планете Земля.

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

Это в конечном итоге встанет разработчикам браузеров боком, потому что в любой момент главный разработчик Chromium — Google может вставить палки в колёса разработчикам модификаций.

Всех браузеров на основе Chromium подсчитать одному человеку вряд ли под силу, поэтому приведу список только тех, что помню:

Chrome — в представлении не нуждается, браузер от Google;
Chr Edge — новый браузер от Microsoft со старым названием. Поговаривают, отличается большей производительностью от Chrome. С некоторых пор предустанавливается в систему;
Brave — браузер с повышенной безопасностью настолько, что приватный режим использует Tor;
Яндекс.Браузер, Opera, Vivaldi, тысячи их.

Firefox

Firefox использует движки Gecko и SpiderMonkey для своей работы. Имеет небольшое количество базирующихся на Firefox браузеров, но самый известный — Tor Browser. Является единственным рубежом до полного перехода интернета на браузеры на основе Chromium.

Internet Explorer

Это любимая всеми утилита для скачивания браузеров. Как и Chrome — не нуждается в представлении. До 11 версии использовал движки Trident и Chakra JScript. В 11 версии, за исключением режима совместимости, стал использовать движки Trident и Chakra JavaScript. Этот браузер ещё долго будет использоваться для всякого рода систем видеонаблюдения, поскольку имеет, почему-то, популярный в узких кругах API для расширений. В Windows 8 и Windows 8.1 имел особую модификацию движка Trident на базе WinRT для Metro режима.

(Legacy) Edge

Браузер, начавший своё существование с кодовым названием Project Spartan, являлся новым браузером от Microsoft в 2015 году, использующим движки EdgeHTML и Chakra JavaScript. Конечной целью проекта была полная совместимость с сайтами, отлично работающими в Chrome. В итоге — получилось нечто своеобразное, но, очевидно, не выжившее под давлением Google.

Safari

Safari? А нет его больше, этого вашего Safari, кончился.

Нецелевое использование браузеров

Вроде бы браузеры — законченный продукт, ни добавить ни отнять. Однако, они используются в разного рода других приложениях. Причины в следующем (в порядке убывания значимости):

П р ограммистов на JS нечем занять;
На JS+HTML новичкам проще программировать;
Кроссплатформенность;
Требуется возможность отображать веб-страницы.

Приведу примеры подобного использования:

Chromium

Нынешние браузеры настолько сложны, что одному человеку создать собственный браузер не под силу (либо это должен быть гений). Они по сложности сравнимы с операционными системами! А, постойте, вот и первый кандидат на нецелевое использование — Chrome OS. Да, весь пользовательский интерфейс — просто модифицированный Chromium.
Однако, помимо этого, в виде CEF (Chromium Embedded Framework), Chromium используется в:

Internet Explorer

Почти любое Win32 приложение, умеющее отображать WEB-страницы и при этом в распакованном виде занимающее меньше 60 мегабайт использует внутри Internet Explorer. Кстати, это касается не только маленьких по размеру приложений, например, Visual Studio использует Internet Explorer для отображения WEB-страниц, когда это требуется в работе IDE. Ещё существуют HTA приложения — древний предшественник CEF на базе Internet Explorer. И ведь до сих пор работает.

(Legacy) Edge

Новым приложениям — новые движки! Любое UWP приложение, использующее внутри отображение WEB-страниц работает на базе Edge. Не то, чтобы Microsoft запрещали использовать что-то другое, но никто просто и не старался. Так же, пока что, в предварительных сборках Windows новая клавиатура с GIF панелью тоже использует Edge для рендеринга. В будущих версиях, полагаю, перейдут на Chr Edge.

Производительность

Постойте, столько приложений, а что там с производительностью? Лично я — не специалист в оценке производительности, но хочу поделится с вами некоторыми занимательными фактами.

Prefetcher

В Windows есть такая штука — Prefetcher. Она занимается подгрузкой программ в ОЗУ при старте ОС и на протяжении её работы. Штука эта достаточно умная, и она анализирует чаще всего запускаемые программы, чтобы в дальнейшем их подгружать.

Как это связано с браузерами? Идея в том, что это может смазать первый пользовательский опыт с другим браузером, например, пользуясь постоянно Chrome, имеете установленную версию Firefox. При запуске Firefox будет вести себя крайне медленно — медленнее, чем ваш основной браузер. Всё потому что он запылился в глазах Prefetcher. В конечном итоге всё будет работать быстро, но первое впечатление после долгого неиспользования будет ужасным. Особенно это касается пользователей с HDD или малым количеством ОЗУ.

Области распределённой памяти

Да, звучит не очень. Но суть, в данном случае, простая — если одна единица исполняемого кода требуется к исполнению больше одного раза, будь то exe или dll , то в память она загрузится лишь один раз. Поясню: если два различных приложения в ходе своей работы загрузят одну и ту же библиотеку, например, edgehtml.dll , то этот файл будет загружен в ОЗУ компьютера на самом деле только один раз, хотя, казалось бы, потребуется два или больше раз. Таким образом ОС экономит нам оперативную память.

Движки нормального человека

К чему это я? А вот дело в том, что в отличии от других браузеров, Internet Explorer и (Legacy) Edge предустановлены в систему, а их движки хранятся в папке System32 . Это, вкупе с API для разработки приложений, означает, что все приложения в системе, использующие данные движки будут загружать их в память только однажды. И этот принцип распространяется на все приложения.

У людей часто возникают проблемы с UWP приложениями, а точнее — с их скоростью запуска. Всё дело в WinRT — огромном наборе библиотек, при помощи которых UWP приложение взаимодействует с ОС. Если не использовать UWP приложения часто, то этот набор библиотек не будет прогружен в памяти полностью, и придётся ожидать окончания этого процесса перед использованием приложения. Но забавный факт — используя два и более UWP приложения время их старта и общая производительность резко увеличиваются и часто даже превосходят Win32 программы. Исключением из этого является приложение "Фотографии" — тут отдельная история, покрытая туманом.

Движки курильщика

А вот с приложениями (в том числе и браузерами) на основе Chromium это так не работает. Каждое приложение комплектует с собой собственную сборку библиотеки CEF, что, кроме раздувания размера приложения, не позволяет операционной системе иметь только одну копию dll в ОЗУ. Итого это сильно замедляет производительность при использовании множества подобных приложений. Помимо того, сам размер CEF довольно удручающий.

Microsoft Store

У многих возникает вопрос — почему в Microsoft Store нет ни одного браузера(не считая нескольких кривых поделок на EdgeHTML)? Ответ, на самом деле, прост — все браузеры, включая Chr Edge имеют собственную систему обновления, что прямо запрещено правилами Microsoft Store. В остальном никто никого не ограничивает.

Как удалить новый Microsoft Edge

Это не очень сложно. Для начала требуется найти папку с Microsoft Edge, она расположена по пути:
C:\Program Files (x86)\Microsoft\Edge\Application
Далее заходим в любую версию Edge и переходим в папку Installer . Полный путь может выглядеть следующим образом:
C:\Program Files (x86)\Microsoft\Edge\Application\83.0.478.58\Installer
Далее необходимо открыть командную строку от имени администратора в данной папке и выполнить следующую команду:
setup.exe --uninstall --system-level --verbose-logging --force-uninstall
Готово! Через несколько секунд этот браузер исчезнет из системы. Но при следующем же обновлении он появится снова, будте бдительны.

Заключение

Пожалуй, эта статья получилась даже больше, чем я предполагал. В любом случае, какой браузер использовать — выбор ваш, но, зато, вы теперь знаете чуточку больше. Всем спасибо.

Администраторы Хабра, пожалуйста, почините HabraStorage в Legacy Edge! Совсем не дело.

Для многих из нас, разработчиков, WebKit — черный ящик. Мы бросаем в него HTML, CSS, JS и кучу изображений, и WebKit, как-то… магически, выдает нам веб-страницу, которая выглядит и работает хорошо.
Но на самом деле, как говорит мой коллега Илья Григорик:

Веб-кит не является черным ящиком. Это — белый ящик. И не просто белый, но и открытый ящик.

Что такое WebKit?
Чем WebKit не является?
Как WebKit используется WebKit-браузерами?
Почему многие WebKit не одинаковые?

Стандартные компоненты веб-браузера

Давайте перечислим несколько компонентов современных браузеров:

Парсинг (Разбор HTML, XML, CSS, Javascript)
Макет (Layout)
Рендеринг текста и графики
Декодировка изображений
Взаимодействия с GPU
Доступ к сети
Аппаратное ускорение

Остальные компоненты каждый WebKit «порт» реализует по своему. Давайте разберемся что это значит.

WebKit порты

Существует множество WebKit «портов», и я предоставляю Ария Хидаят, WebKit хакер и тех. директор в Sencha право рассказать об этом:

Самым популярной ассоциацией к понятию WebKit, обычно является вид WebKit от Apple's, который работает на Mac OS X (первая и оригинальная WebKit библиотека). Как вы можете догадаться, различные интерфейсы реализованы, используя различные нативные библиотеки Mac OS X, в основном сосредоточенные в компоненте CoreFoundation. Например, если вы определяете цветную плоскую кнопку, с особым радиусом контура, WebKit знает где и как рисовать эту кнопку. В тоже время, окончательный рендеринг кнопки (в виде пикселей на мониторе пользователя) ложится на плечи CoreGraphics.

Как я упоминал выше, используемый CoreGraphics, уникален для каждого WebKit порта. Chrome для Mac, к примеру, использует Skia.

В какой-то момент, WebKit был «портирован» под разные платформы, как десктопные, так и мобильные. Такая вариация обычно называется «WebKit порт». Для Safari Windows, Apple также самостоятельно «портировала WebKit» для запуска под Windows, используя Windows версию своей (с ограниченной реализацией) CoreFoundation библиотеки.

… не смотря на факт, что Safari под Windows теперь мертв.

Кроме этого, также было множество других «портов» (см. полный список). Google создал и продолжает поддерживать свой Chromium порт. Также существует WebKitGtk, основанный на Gtk+. Nokia (а теперь Trolltech, который перекупил его) поддерживает WebKit Qt порт, который стал популярен в качестве QtWebKit модуля.

Некоторые порты WebKit

Safari
— Safari под OS X и Safari под Windows два разных порта
— Ночная сборка WebKit это сборка исходного кода Mac «порта», который используется для Safari, только новее
Мобильный Safari
— Развивался в приватной ветке, но позднее былоткрыт.
— Chrome под iOS (использует Apple’s WebView; чуть позже о разнице)
Chrome (Chromium)
— Chrome под Android (использует непосредственно «порт» Chromium)
— Chromium также является основой для браузеров: Yandex, 360, Sogou, и скоро, Opera.
Android браузер
— Использует последний исходный код WebKit, доступный на момент релиза.
: Amazon Silk, Dolphin, Blackberry, QtWebKit, WebKitGTK+, The EFL port (Tizen), wxWebKit, WebKitWinCE, etc

Что общее во всех WebKit браузерах

Для начала давайте рассмотрим общие функции, которые используются во всех WebKit-браузерах:

Знаете это смешно, я сделал несколько попыток, чтобы написать этот абзац. И каждый раз члены команды Chrome поправляли меня, как вы увидите…

И так, во первых, WebKit разбирает HTML одинаково. Ну, за исключением того, что Chromium единственный порт, на данный момент, где включена поддержка потоков для разбора HTML.
… Хорошо, но после разбора HTML, DOM дерево конструируется одинаково. Ну, на самом деле Shadow DOM включен только для Chromium порта, тоесть построение DOM варьируется. Тоже для пользовательских элементов (custom elements).
… Хорошо, WebKit создает window и document объекты для всех одинаково. Правда, хотя свойства и конструкции которые они предоставляют, могут зависит от использования переключателей функций (feature flags).
… Разбор CSS одинаков. Поедание вашего CSS и преобразование его в CSSOM довольно таки стандартно. Ага, хотя Chrome поддерживает только -webkit- префиксы, когда Apple и другие браузеры поддерживают устаревшие префиксы -khtml- и -apple-.
… Макет… позиционирование? Это же как хлеб с маслом. Везде одинаково, правильно? Ну уже! Субпиксельный макет и насыщенная макетная арифметика является частью WebKit, но отличается от порта к порту.
Супер.

Так что, это сложно.

Точно также как Flickr и Github прячут реализованные функции за специальными флагами, WebKit делает тоже самое. Это позволяет портам включать/выключать любую функциональность на стадии компиляции с помощью WebKit compile-time Feature Flags. Функции также могут быть включены в режиме работы, с помощью параметров в командной строке (для Chromium) или конфигураций, таких как about:flags.

Теперь, давайте попробуем подвести итог, что общего в мире WebKit…

Что общего для каждого WebKit порта.

DOM, window, document
более или менее
CSSOM
Разбор CSS, свойство/значение
различия в префиксах производителей
Разбор HTML и построение DOM
Одинаково, если мы забудем про Web Components.
Макет и позиционирование
Flexbox, Floats, block formating context… все общее
Инструменты пользовательского интерфейса, и инструменты разработчика, типа Chrome DevTools он же WebKit inspector.
Хотя с прошлого апреля, Safari использует свой собственный Safari инспектор, не-WebKit, с закрытыми исходниками.
Такие функции как contenteditable, pushState, File API, большинство SVG, математика CSS трансформаций, Web Audio API, localStorage
Хотя реализация может отличаться. Каждый порт может использовать свою собственную систему хранения для localStorage и может использовать разное audio API для Web Audio API.
Множество других функций.

Теперь, что не является общим для WebKit портов:

Все связанное с GPU
— 3D трансформации
— WebGL
— Декодирование видео
Отрисовка 2D на экран
— Технологии сглаживания
— Рендеринг SVG и CSS градиентов
Рендеринг текста и переносы
Сетевые технологии (SPDY, пре-рендеринг, WebSocket транспорт)
JavaScript движок
— Движок JavaScriptCore лежит в репозитории WebKit. Но существуют биндинги в WebKit и для него, и для V8.
Рендеринг элементов форм
Поведение тэгов video и audio и поддержка кодеков
Декодирование изображений
Навигация назад/вперед
— Часть pushState()
SSL функции, такие как Strict Transport Security и Public Key Pins

Или если вдаваться в подробности, недавно добавленная функция: CSS.supports() была включена для всех портов, за исключением win и wincairo, для которых не включены условные функции css3 (css3 conditional features).

Теперь, мы вдаемся в технические подробности… время стать педантичным. Даже сказанное выше не совсем корректно. На самом деле это WebCore, является общим компонентом. WebCore это макет, рендеринг, и DOM библиотека для HTML и SVG, и в основном то, что люди думают, когда они говорят WebKit. В самом деле «WebKit» технически — это слой биндингов между WebCore и «портами», хотя в обычной беседе это различие в основном не важно.

Диаграмма должна помочь:

Многие из компонентов WebKit переключаемые (показаны серыми).

Например, JavaScript движок WebKit, JavaScriptCore, является движком по-умолчанию в WebKit. Изначально он основан на KJS (от KDE) с дней, когда WebKit начинался как ответвление KHTML. В тоже время, Chromium порт, переключается на V8 движок и использует уникальные DOM биндинги.

Шрифты и рендеринг текста являются очень большой частью платформы. Существует 2 отдельных пути для текста в WebKit: Быстрый и Сложный. Оба требуют поддержку специфичную для платформы (реализованную на стороне порта), но Быстрый только должен знать как блитировать глифы (которые WebKit кэширует для платформы), когда Сложный полностью переносит рендеринг строк на уровень платформы и просто говорит «нарисуй это, пожалуйста».

«WebKit это как сэндвич. В прочем, в случае Chromium, это больше как тако. Вкусное тако из веб-технологий.
Dmitri Glazkov, Chrome WebKit hacker. Champion of Web Componets, and shadow dom.

Теперь, давайте расширим обзор, и посмотрим на несколько портов и несколько подсистем. Ниже представлены пять портов WebKit, обратите внимание, как различается набор инструментов для каждого из них, несмотря на общие компоненты:

Chrome (OS X)	Safari (OS X)	QtWebKit	Android Browser	Chrome for iOS
Rendering	Skia	CoreGraphics	QtGui	Android stack/Skia	CoreGraphics
Networking	Chromium network stack	CFNetwork	QtNetwork	Fork of Chromium’s network stack	Chromium stack
Fonts	CoreText via Skia	CoreText	Qt internals	Android stack	CoreText
JavaScript	V8	JavaScriptCore	JSC (V8 is used elsewhere in Qt)	V8	JavaScriptCore (without JITting) *

* Сноска про Chrome для IOS. Он использует UIWebView, как вы вероятно знаете. В соответствии с возможностями UIWebView, это означает что он может использовать только такой же рендеринг движок, как и Мобильный Safari, JavaScriptCore (а не V8) и однопоточную модель. Тем неменее, некоторый код заимствован из Chromium, такой как подсистема для работы с сетью, синхронизация инфраструктура закладок, omnibox, метрики и отчеты о сбоях (crash reporting). (Также, JavaScript настолько редко является узким местом на мобильных устройствах, что отсутствие JITting компилятора имеет минимальное влияние.)

Хорошо, так к чему же мы пришли?

И так, все WebKit полностью различные теперь. Я напуган.

Не стоит! Покрытие WebKit тестами «layoutTest» огромное. (28,000 тестов по последним подсчетам), и не только для существующих функций, но также для всех найденных регрессий. На самом деле, когда бы вы не изучали новые или «тайные» функции DOM/CSS/HTML-5, наборы тестов «layoutTest» обычно имеют отличную минимальную демонстрацию.

В дополнении, W3C предпринимает усилия для стандартизации набора тестов. Это означает, что мы можем ожидать что и WebKit порты, и все другие браузеры будут тестироваться одинаковыми наборами тестов, что приведет нас к уменьшению quirks and a more interoperable web. Для всех тех, кто приложил свои усилия, посетив событие Test The Web Forward… спасибо вам!

Опера только что переехала на WebKit. Что из этого получится?

Роберт Найман и Роб Хоукс уже коснулись этой темы, но я добавлю что, одной из важной частью анонса было то, что Opera переходит на Chromium. Это означает, что WebGL, Canvas, HTML5 формы, имплементация 2D graphics, все эти вещи будут одинаковыми на Chrome и Opera теперь. Одинаковое API, и низкоуровневая реализация. Так как Opera основана на Chromium, вы можете ощущать, что вы сокращаете свою работу, по проверке совместимости на Opera и Chrome.
Я также должны обратить внимание, что все Opera браузеры будут переведены на Chromium. То есть, Opera для Windows, Mac, Linux и Opera Mobile (полноценный мобильный браузер). Даже Opera Mini, тонкий клиент, будет переключена с текущей рендеринг-фермы основанной на Presto, на другую, основанную на Chromium.

… и ночная сборка WebKit. Что это?

Это mac порт WebKit, работающий на том же коде что и Safari (хотя некоторые внутренние библиотеки были изменены). В основном Apple руководит им, так что поведение и набор функций соответствует тому, что вы сможете найти в Safari. Во многих случаях Apple ведет себя консервативно, когда речь заходит о включении функций, которые другие порты реализуют или с которыми ведут эксперементы. В любом случае, если использовать аналогии, думайте что… ночная сборка WebKit для Safari, это как Chromium для Chrome.
Chrome Canary также использует последние исходные коды WebKit, однодневной давности или около того.

Современные браузеры предоставляют к просмотру пользователю не только изображения и текст в соответствие с HTML кодом на полученной странице. Функциональность зависит от конкретного браузера. В наши дни веб обозреватели обладают очень большими возможностями: закладки, интеграция поиска в адресную строку, всевозможные расширения и т.д. [Источник 2]

Содержание

История

Первый браузер, который имел графический интерфейс, т.е. не только просто текст на черном фоне, был разработан в 1993 году и имел название NCSA Mosaic. Именно он послужил основой для создания других веб-обозревателей, так как, разработчики в свое время открыли его исходный код для всех желающих. Так, на основе NCSA Mosaic был разработан самый популярный в свое время браузер Netscape Navigator, произошло это в 1994 году, он имел ошеломительный успех и приносил неплохую прибыль компании его разработчика. Хочется отметить, что внутренним именем Netscape Navigator был — Mozilla.

Компания Microsoft не могла не заметить такой успех Netscape Navigator и разработала свой собственный браузер в 1995 году, так же сделанный на основе NCSA Mosaic. Как вы наверное уже догадались, название ему дали — Internet Explorer. Вследствие именно Internet Explorer (IE) стал неотъемлемой частью всех операционных систем этой компании. Так, как ОС Windows пользовалось огромное количество пользователей, IE быстро завоевал данную нишу и завоевал около 95% всего рынка. Это и привело к закрытию проекта Netscape Navigator, ведь конкурировать с такой монополией было невозможно.

Перед тем, как полностью кануть в лету, Netscape покупает компания AOL Time Warner, которая делает исходный код Navigator открытым. Далее AOL, в связи со своим закрытием, передает все права и свои разработки в новую компанию — Mozilla Foundation, которая продолжила развивать их идеи.

В 1996 году появилась Opera, которая, благодаря маленькому весу и быстрой загрузке страниц, стала в то время самой популярной альтернативой Internet Explorer в России и странах СНГ, да и по всему свету.

Internet Explorer же стал терять свои позиции, т.к. Microsoft не обновлял его аж до октября 2006 года, т.к. у них была завоевана и так большая часть рынка. Но Internet Explorer был к этому времени уже настолько глючным и имел множество дыр в безопасности, что со временем стал одним из самых нелюбимых и не популярных браузеров — так продолжается и в наше время, не смотря на появление его новых, намного улучшенных версий.

В ноябре 2004 года появился любимый многими веб-обозреватель Mozilla Firefox, который основывался на проекте Mozilla Suite. В 2006 году компания Apple выпустила свой продукт под названием Safari, а в 2008 году на рынок вступила и компания Google, выпустив свое детище под названием Google Chrome.

К сегодняшнему дню было создано и выпущено огромное множество различных интересных веб-обозревателей, как уже писалось выше — каждый из них обладает своими уникальными функциями и фишками. [Источник 3]

Основное функциональное назначение браузера

Прежде всего, браузеры предназначены для представления выбранного вами веб-ресурса, путем его запроса у сервера и отображения в окне браузера. Ресурсом, как правило, является HTML документ, но это может быть изображение, файл PDF или другого формата. Адрес, по которому находится ресурс, определяется по введенному пользователем URL. То, как браузер интерпретирует и отображает HTML файлы, определено в HTML и CSS спецификациях. Эти спецификации ведутся такой организацией как W3C (Word Wide Web Консорциум), которая занимается стандартизацией Web пространства.

Как ни странно, но ни в одной существующей формальной спецификации не затрагивается вопрос используемого в браузерах пользовательского интерфейса, он просто основан на лучших практических приемах, отточенных годами опыта и формировался в результате подражания друг друга браузерами. Новая HTML5 спецификация также не определяет какие элементы должен включать UI, однако она перечисляет некоторые наиболее распространенные из них. К их числу относится адресная строка, строка состояния и панель инструментов. Существуют, конечно же, особенности, характерные исключительно отдельным браузерам, к примеру, менеджер загрузок в Firefox. [Источник 4]

Принцип работы браузера

Браузер — это клиентская программа, позволяющая в простой форме посылать запросы серверам на загрузку веб-страниц. В задачи браузера помимо простейших операций по связи с серверами входит: обработка полученной HTML-разметки, интерпретация стилей и скриптов, контроль ошибок и по возможности их исправление, хранение пользовательской информации. Браузеры, представленные различными компаниями, могут по-разному реализовывать эти механизмы или игнорировать какие-либо из них. Такие возможности, объединенные в виде программы, называется браузерным движком.

Этапы рабочего процесса браузера:

При вводе имени сайта в адресной строке, клике по ссылке в поисковой системе или на любом сайте, браузер посылает запрос серверу на загрузку определенной страницы
Сервер получает запрос и проверяет, есть ли такая страница
Сервер осуществляет передачу HTML-разметки страницы браузеру
Браузер обрабатывает разметку и выводит результат пользователю
Механизм рендеринга

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

Интерфейс пользователя

Это буфер между пользователем и сердцем браузера — его движком. Именно ему приходится принимать все пожелания от пользователя и обрабатывать его действия.

Интерфейс пользователя обеспечивает стандартный набор функций (ввод информации, печать, визуализация процесса загрузки данных, панели инструментов и настроек) — в общем все то, что пользователь ждет от обычного ПО.

Высокоуровневый движок браузера

тот модуль отвечает за высокоуровневые действия браузера: начало загрузки страниц, их обновление, переходы вперед/назад, работа с закладками, историей и настройками браузера. Эти настройки влияют на работу графического движка. Например, ярким примером будет отключение стилей или javascript, выбор кодировки, масштаб и т.п.

Дополнительной задачей этого движка является информирование пользователя о текущей сессии браузера: ход загрузки документа, оповещение о javascript ошибках.

Графический движок

Это и есть самая главная часть любого веб браузера, его сердце и мозг. Графический движок отображает на экране содержимое запрашиваемого ресурса.

Именно эта часть браузера анализирует полученный HTML или XML, при этом учитывает влияние CSS и Javascript, а так же других объектов, расположенных на веб странице (например, изображения или flash). На основе всех этих данных, движок создает макет (разметку) страницы, который видит пользователь на экране.

Ключевыми компонентами графического движка являются HTML и CSS парсеры — сложные программные комплексы, поскольку они позволяет графическому движку отобразить документ даже при наличии ошибок в HTML и CSS.

Самые распространенные движки браузеров на сегодня:

Trident — Internet Explorer; Gecko — браузеры Mozilla; Webkit — Chrome, Safari; Presto — Opera. Некоторые из этих движков совмещают в себе графический и высокоуровневый движки.

Читайте также: