Андрей Смирнов
Время чтения: ~24 мин.
Просмотров: 4

Движки веб-браузеров – что это и какие бывают

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

dvizhki-brauzerov1-670x335.png

Общие сведения

Использование движков (Rendering engine) для создания обозревателей имеет множество преимуществ:

  • Облегчается поиск и устранение ошибок кода.
  • Удобная возможность улучшить отдельный компонент сразу в нескольких программах.
  • Облегчается процесс изменения графического интерфейса приложения.
  • Простота создания новых программ под желания конкретного разработчика или нужны конкретного пользователя.

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

Яркий пример – движок Trident от компании Microsoft. Он один используется в большом множестве приложений данной корпорации. Развивается основа – развиваются и производные проекты.

Каждое решением имеет свои плюсы и минусы. Например, многие пользователи замечают, что Mozilla Firefox гораздо лучше работает с большим количеством открытых вкладок, чем конкуренты. Это достижение платформы, на основе которой создан обозреватель.

Trident

Когда пользователь устанавливает новую операционную систему Windows, первый веб-обозреватель, с которым он сталкивается – это Internet Explorer. Поэтому его движок рассмотрен в обзоре первым.

Trident, или MSHTML – довольно старый программный компонент, разработанный корпорацией Microsoft для своих нужд. Проект непрерывно развивается с 1997 года. Используется в веб-обозревателе от Майкрософт – Internet Explorer, почтовом клиенте Outlook, Проводнике Виндовс (программа для работы с файлами) и множестве других приложений данного разработчика.

Пользователями считается одним из наиболее неудачных движков для браузеров. Не поддерживает сторонние модульные  расширения – плагины, некорректно отображает многие интернет-страницы, имеет не самую быструю скорость работы.

С выходом Windows 10 платформа Trident эволюционировала в EdgeHTML.Разработчики взяли устаревший неудачный движок за основу и создали новую, отвечающий всем требованиям современным пользователей. Судя по проведенным бенчмаркам (программный тест производительности и скорости работы), Microsoft Edge (обозреватель, созданный на основе EdgeHTML) догнал и даже перегнал популярные программы, использованные для создания браузеров Google Chrome и Mozilla Firefox.

Gecko

Gecko – движок, используемый в популярном интернет-обозревателе Мозилла Фаерфокс и множестве других программ. Исходный код программы находится в свободном доступе, то есть каждый желающий может абсолютно бесплатно создать на основе Gecko свой собственный браузер или почтовый клиент.

Другое преимущество Геко – кроссплатформенность. Он работает на подавляющем большинстве современных операционных систем: как для персональных компьютеров, так и для мобильных устройств (в отличие от Internet Explorer, который функционирует только на ОС Windows).

dvizhki-brauzerov3-670x473.jpeg

Gecko поддерживает все современные стандарты и технологии, используемые при создании вебсайтов. Является одной из двух наиболее популярных браузерных платформ. Поддерживает подключение плагинов. Бенчмарки и личный опыт пользователей показывают, что браузеры на данном движке потребляют меньше всего ресурсов персонального компьютера и стабильно работают с большим количеством вкладок (например, несколько сотен).

На основе Геко создан популярный интернет-обозреватель Mozilla Firefox, почтовый клиент Thunderbird, планировщик задач Sunbird, а также анонимный веб-браузер с встроенной поддержкой VPN-технологий Tor.

KHTML

Не особо известная платформа, используемая для создания Konqueror — файлового менеджера среды KDE. Для пользователей, не знакомых с операционными системами семейства Linux, интересен тем, что на основе данного проекта создан самый популярный движок в мире, речь о котором пойдет дальше.

dvizhki-brauzerov4-670x507.png

WebKit

Этот движок разработан всемирно известной корпорацией Apple на основе вышеупомянутого решения – KHTML. Выпущенный в 2001 году, этот проект получил колоссальное развитие и стал одним из самых используемых в мире.

На основе WebKit был создан веб-обозреватель Safari, используемый по умолчанию в iOS-устройствах и лидер по известности среди браузеров – Google Chrome. Подавляющее число современных программ для обработки содержимого веб-страниц имеют в своей основе ВебКит. Кроме того, он используется в популярном приложении Steam, предназначенном для цифровой дистрибуции компьютерных игр от компании Valve.

dvizhki-brauzerov5.png

Аналогично с Gecko, WebKit является кроссплатформенным и отлично запускается на всех популярных платформах. Показывает высокую стабильность и производительность работы. Ввиду огромной известности, под данное решение разрабатывается подавляющее большинство расширений. Также используется в популярных мобильных платформах, таких как Android и iOS. Является свободным движком, то есть может быть бесплатно использован любым человеком для создания собственных приложений.

В 2013 году от WebKit отделилась новая ветка, принадлежащая корпорации Google – Blink. Этот проект лег в основу Chrome 28-й версии (и всех последующих), а также его собрата с открытым исходным кодом – Chromium. Chromium использован для создания популярного в России Yandex Browser. Начиная с 15-й версии на Blink перешел и браузер Opera.

dvizhki-brauzerov6.jpeg

Presto

Созданный в 2003 году, браузерный движок Presto использовался в качестве основы для Opera. Развивался на протяжении 10-ти лет. В 2013 разработчики Оперы решили отказаться от использования Presto в пользу более мощного и популярного Blink от Google. В данный момент развития проекта остановлено.

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

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

Так-что, давайте попробуем разобраться в некоторых вещах:

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

Теперь, особенно после новости, что Опера перешла на WebKit, нас окружает множество WebKit-браузеров, и достаточно сложно сказать, что их объединяет, а где они идут своим путем. Ниже, я надеюсь, мы постараемся пролить немного света на этот вопрос. В итоге, вы сможете лучше определять отличия браузера, отправлять баги в правильный трэкер, и вести кроссбраузерную разработку более эффективно.

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

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

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

Какие из них общие для всех WebKit браузеров? В значительной степени только первые два. Остальные компоненты каждый 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

Разные порты могут фокусироваться на разных задачах. Фокус Mac порта — разделение между браузером и операционной системой, и предоставление биндигов Obj-C и С++ для встраивание рендеринг движка в нативные приложения. Фокус Chromium порта — всецело на браузере. QtWebKit предлагает свой порт использовать вместе со своей кросс-платформенной архитектурой приложений, в качестве движка для рендеринга.

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

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

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

Так что, это сложно. Точно также как 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 портов:

  • Рендеринг текста и переносы
  • Сетевые технологии (SPDY, пре-рендеринг, WebSocket транспорт)
  • Рендеринг элементов форм
  • Поведение тэгов video и audio и поддержка кодеков
  • Декодирование изображений
  • SSL функции, такие как Strict Transport Security и Public Key Pins

Давайте взглянем на один из них: 2D графика зависит от порта, мы используем совершенно разные библиотеки для рендеринга на экран:d6e046825f903a621d625b87184bbfb8.png Или если вдаваться в подробности, недавно добавленная функция: CSS.supports() была включена для всех портов, за исключением win и wincairo, для которых не включены условные функции css3 (css3 conditional features). Теперь, мы вдаемся в технические подробности… время стать педантичным. Даже сказанное выше не совсем корректно. На самом деле это WebCore, является общим компонентом. WebCore это макет, рендеринг, и DOM библиотека для HTML и SVG, и в основном то, что люди думают, когда они говорят WebKit. В самом деле «WebKit» технически — это слой биндингов между WebCore и «портами», хотя в обычной беседе это различие в основном не важно. Диаграмма должна помочь:ea3ca76288dff23eb1b92621da070944.png Многие из компонентов WebKit переключаемые (показаны серыми). Например, JavaScript движок WebKit, JavaScriptCore, является движком по-умолчанию в WebKit. Изначально он основан на KJS (от KDE) с дней, когда WebKit начинался как ответвление KHTML. В тоже время, Chromium порт, переключается на V8 движок и использует уникальные DOM биндинги. Шрифты и рендеринг текста являются очень большой частью платформы. Существует 2 отдельных пути для текста в WebKit: Быстрый и Сложный. Оба требуют поддержку специфичную для платформы (реализованную на стороне порта), но Быстрый только должен знать как блитироватьглифы (которые WebKit кэширует для платформы), когда Сложный полностью переносит рендеринг строк на уровень платформы и просто говорит «нарисуй это, пожалуйста». Теперь, давайте расширим обзор, и посмотрим на несколько портов и несколько подсистем. Ниже представлены пять портов 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, однодневной давности или около того.

Расскажи мне еще про внутренности WebKit.

Держи.ea72db90a4f8f1fa815a65c08d95daa4.png

330
109.8k 330
  (Redirected from Webkit)

Jump to navigationJump to search

WebKit
220px-WebKit_logo_%282015%29.svg.png
The WebKit logo, as of 2015
Original author(s) KDE[1][2]
Developer(s) Apple Inc., Adobe Systems, KDE, Igalia, and others
Initial release November 4, 1998 (1998-11-04) (KHTML released)June 7, 2005 (2005-06-07) (WebKit sourced)
Preview release
Nightly[3]
Repository 10px-OOjs_UI_icon_edit-ltr-progressive.svg.png
Written in C++[4]
Operating system macOS, Linux[5]
Type Browser engine
License LGPLv2.1 (rendering engine, JavaScript engine), BSD (additional contributions from Apple)
Website

WebKit is a browser engine developed by Apple and primarily used in its Safari web browser, as well as all the iOS web browsers. WebKit is also used by the BlackBerry Browser, the Tizen mobile operating systems, and a browser included with the AmazonKindlee-book reader. WebKit’s C++application programming interface (API) provides a set of classes to display Web content in windows, and implements browser features such as following links when clicked by the user, managing a back-forward list, and managing a history of pages recently visited.

WebKit’s HTML and JavaScript engine started as a fork of the KHTML and KJS libraries from KDE,[1][6] and has since been further developed by KDE contributors, Apple, Google, Nokia, Bitstream, BlackBerry, Igalia, and others.[7] WebKit supports macOS, Windows, Linux, and various other Unix-likeoperating systems.[8] On April 3, 2013, Google announced that it had forked WebCore, a component of WebKit, to be used in future versions of Google Chrome and the Opera web browser, under the name Blink.[9][10]

WebKit is available under a BSD-form license[11] with the exception of the WebCore and JavaScriptCore components, which are available under the GNU Lesser General Public License. As of March 7, 2013, WebKit is a trademark of Apple, registered with the U.S. Patent and Trademark Office.[12]

Origins[edit]

The code that would become WebKit began in 1998 as the KDE HTML (KHTML) layout engine and KDE JavaScript (KJS) engine. The WebKit project was started within Apple by Don Melton on June 25, 2001,[13] as a fork of KHTML and KJS. Melton explained in an e-mail to KDE developers[1] that KHTML and KJS allowed easier development than other available technologies by virtue of being small (fewer than 140,000 lines of code), cleanly designed and standards-compliant. KHTML and KJS were ported to OS X with the help of an adapter library and renamed WebCore and JavaScriptCore.[1] JavaScriptCore was announced in an e-mail to a KDE mailing list in June 2002, alongside the first release of Apple’s changes.[14] WebCore was announced at the Macworld Expo in January 2003 by Apple CEOSteve Jobs with the release of the Safari web browser. JavaScriptCore was first included with Mac OS X v10.2 as a private framework which Apple used in their Sherlock application, while WebCore debuted with the first beta of Safari. Mac OS X v10.3 was the first major release of Apple’s operating system to bundle WebKit, although it had already been bundled with a minor release of 10.2.

According to Apple, some changes involved OS X-specific features (e.g., Objective-C, KWQ,[15] OS X calls) that are absent in KDE’s KHTML, which called for different development tactics.[16]

Split development[edit]

The exchange of code between WebCore and KHTML became increasingly difficult as the code base diverged because both projects had different approaches in coding and code sharing.[17] At one point KHTML developers said they were unlikely to accept Apple’s changes and claimed the relationship between the two groups was a «bitter failure».[18] Apple submitted their changes in large patches containing very many changes with inadequate documentation, often to do with future additions. Thus, these patches were difficult for the KDE developers to integrate back into KHTML.[19] Also, Apple had demanded that developers sign non-disclosure agreements before looking at Apple’s source code and even then they were unable to access Apple’s bug database.[20]

During the publicized «divorce» period, KDE developer Kurt Pfeifle (pipitas) posted an article claiming KHTML developers had managed to backport many (but not all) Safari improvements from WebCore to KHTML, and they always appreciated the improvements coming from Apple and still do so. The article also noted Apple had begun to contact KHTML developers about discussing how to improve the mutual relationship and ways of future cooperation.[21] In fact, the KDE project was able to incorporate some of these changes to improve KHTML’s rendering speed and add features, including compliance with the Acid2 rendering test.[22]

Following the story of the fork’s appearance in the news, Apple released changes of the source code of WebKit fork in a public revision-control repository.[23] Since the transfer of the source code into a public Concurrent Versions System (CVS) repository, Apple and KHTML developers have had increasing collaboration. Many KHTML developers have become reviewers and submitters for WebKit revision control repository.

The WebKit team had also reversed many Apple-specific changes in the original WebKit code base and implemented platform-specific abstraction layers to make committing the core rendering code to other platforms significantly easier.[24]

In July 2007, Ars Technica reported that the KDE team would move from KHTML to WebKit.[25] Instead, after several years of integration, KDE Development Platform version 4.5.0 was released in August 2010 with support for both WebKit and KHTML, and development of KHTML continues.[26]

Open-sourcing[edit]

On June 7, 2005, Safari developer Dave Hyatt announced on his weblog that Apple was open-sourcing WebKit (formerly, only WebCore and JavaScriptCore were open source) and opening up access to WebKit’s revision control tree and the issue tracker.[23] This was announced at Apple’s Worldwide Developers Conference 2005 by Apple Senior Vice President of Software Engineering Bertrand Serlet.

In mid-December 2005, support for Scalable Vector Graphics (SVG) was merged into the standard build[27] and in early January 2006 the source code was migrated from Concurrent Versions System (CVS) to Subversion (SVN).

WebKit’s JavaScriptCore and WebCore components are available under the GNU Lesser General Public License, while the rest of WebKit is available under a BSD-style license.

Further development[edit]

Beginning in early 2007, the development team began to implement Cascading Style Sheets (CSS) extensions, including animation, transitions and both 2D and 3D transforms;[28] such extensions were released as working drafts to the World Wide Web Consortium (W3C) in 2009 for standardization.[29]

In November 2007, the project announced that it had added support for media features of the HTML5 draft specification, allowing embedded video to be natively rendered and script-controlled in WebKit.[30]

On June 2, 2008, the WebKit project announced they rewrote JavaScriptCore as «SquirrelFish», a bytecodeinterpreter.[31][32] The project evolved into SquirrelFish Extreme (abbreviated SFX), announced on September 18, 2008, which compiles JavaScript into native machine code, eliminating the need for a bytecode interpreter and thus speeding up JavaScript execution.[33] Initially, the only supported processor architecture for SFX was the x86, but at the end of January 2009, SFX was enabled for OS X on x86-64 as it passes all tests on that platform.[34]

WebKit2[edit]

On April 8, 2010, a project named WebKit2 was announced to redesign WebKit. Its goal was to abstract the components that provide web rendering cleanly from their surrounding interface or application shell, creating a situation where, «web content (JavaScript, HTML, layout, etc) lives in a separate process from the application UI». This abstraction was intended to make reuse a more straightforward process for WebKit2 than for WebKit. WebKit2 had «an incompatible API change from the original WebKit», which motivated its name change.[35]

The WebKit2 targets were set to Linux, MacOS, Windows, GTK, and MeeGo-Harmattan.[36][37] Safari for OS X switched to the new API with version 5.1.[38] Safari for iOS switched to WebKit2 since iOS 8.[39]

The original WebKit API has been renamed WebKitLegacy API.[40] WebKit2 API has been renamed just plain WebKit API.[41]

Use[edit]

220px-Usage_share_of_web_browsers_%28Source_StatCounter%29.svg.png
Usage share of web browsers according to StatCounter

WebKit is used as the rendering engine within Safari and was formerly used by Google’s Chrome web browser on Windows, macOS, iOS, and Android before version 4.4 KitKat (Chrome used only WebCore, and included its own JavaScript engine named V8 and a multiprocess system).[42] Other applications on macOS make use of WebKit, such as Apple’s e-mail client Mail and the 2008 version of Microsoft’s Entouragepersonal information manager, both of which make use of WebKit to render e-mail messages with HTML content.

Installed base[edit]

New web browsers have been built around WebKit such as the S60 browser[43] on Symbian mobile phones, BlackBerry Browser (ver 6.0+), Midori, Chrome browser,[44][45] the Android Web browser before version 4.4 KitKat, and the browser used in PlayStation 3 system software from version 4.10.[46] KDE’s Rekonq web browser and Plasma Workspaces also use it as the native web rendering engine. WebKit has been adopted as the rendering engine in OmniWeb, iCab and Web (formerly named Epiphany) and Sleipnir, replacing their original rendering engines. GNOME’s Web supported both Gecko and WebKit for some time, but the team decided that Gecko’s release cycle and future development plans would make it too cumbersome to continue supporting it.[47]webOS uses WebKit as the basis of its application runtime.[48] The latest interface update for Valve’s Steam employs WebKit to render its interface and built-in browser.[49] WebKit is used to render HTML and run JavaScript in the Adobe Integrated Runtime application platform. In Adobe Creative Suite CS5, WebKit is used to render some parts of the user interface. As of the first half of 2010, an analyst estimated the cumulative number of mobile handsets shipped with a WebKit-based browser at 350 million.[50] By mid April 2015, WebKit browser market share was 50.3%.[51]

[edit]

The week after Hyatt announced WebKit’s open-sourcing, Nokia announced that it had ported WebKit to the Symbian operating system and was developing a browser based on WebKit for mobile phones running S60. Named Web Browser for S60, it was used on Nokia, Samsung, LG, and other Symbian S60 mobile phones. Apple has also ported WebKit to iOS to run on the iPhone, iPod Touch, and iPad, where it is used to render content in the device’s web browser and e-mail software.[52] The Android mobile phone platform used WebKit (and later versions its Blink fork) as the basis of its web browser[53][54][55] and the Palm Pre, announced January 2009, has an interface based on WebKit.[56] The Amazon Kindle 3 includes an experimental WebKit based browser.[57]

In June 2007, Apple announced that WebKit had been ported to Microsoft Windows as part of Safari.

220px-GNOME_Web_3.34_on_GNOME_Shell.png
GNOME Web is a major web browser on Linux that uses WebKit.

WebKit has also been ported to several toolkits that support multiple platforms, such as the GTK toolkit for Linux which is using by GNOME Web,[58][59]Adobe Integrated Runtime, Enlightenment Foundation Libraries (EFL), and the Clutter toolkit.[60]Qt Software included a WebKit port in the Qt 4.4 release as a module called QtWebKit[61] (since superseded by QtWebEngine, which uses Blink instead). The Iris Browser on Qt also used WebKit. The Enlightenment Foundation Libraries (EFL) port – EWebKit – was developed (by Samsung and ProFusion[62]) focusing the embedded and mobile systems, for use as stand alone browser, widgets-gadgets, rich text viewer and composer. The Clutter port is developed by Collabora and sponsored by Robert Bosch GmbH.

There was also a project synchronized with WebKit (sponsored by Pleyo)[63] called Origyn Web Browser, which provided a meta-port to an abstract platform with the aim of making porting to embedded or lightweight systems quicker and easier.[64] This port is used for embedded devices such as set-top boxes, PMP and it has been ported into AmigaOS,[65][66]AROS[67] and MorphOS. MorphOS version 1.7 is the first version of Origyn Web Browser (OWB) supporting HTML5 media tags.[68][69]

Forking by Google[edit]

On April 3, 2013, Google announced that it would produce a fork of WebKit’s WebCore component, to be named Blink. Chrome’s developers decided on the fork to allow greater freedom in implementing WebCore’s features in the browser without causing conflicts upstream, and to allow simplifying its codebase by removing code for WebCore components unused by Chrome. In relation to Opera Software’s announcement earlier in the year that it would switch to WebKit by means of the Chromium codebase, it was confirmed that the Opera web browser would also switch to Blink.[42] Following the announcement, WebKit developers began discussions on removing Chrome-specific code from the engine to streamline its codebase.[70] WebKit no longer has any Chrome specific code (e.g., buildsystem, V8 JavaScript engine hooks, platform code, etc.)

Components[edit]

WebCore[edit]

WebCore is a layout, rendering, and Document Object Model (DOM) library for HTML and Scalable Vector Graphics (SVG), developed by the WebKit project. Its full source code is licensed under the GNU Lesser General Public License (LGPL). The WebKit framework wraps WebCore and JavaScriptCore, providing an Objective-C application programming interface to the C++-based WebCore rendering engine and JavaScriptCore script engine, allowing it to be easily referenced by applications based on the Cocoa API; later versions also include a cross-platform C++ platform abstraction, and various ports provide more APIs.

WebKit passes the Acid2 and Acid3 tests, with pixel-perfect rendering and no timing or smoothness issues on reference hardware.[71]

JavaScriptCore[edit]

JavaScriptCore is a framework that provides a JavaScript engine for WebKit implementations, and provides this type of scripting in other contexts within macOS.[14][72] JavaScriptCore is originally derived from KDE’s JavaScript engine (KJS) library (which is part of the KDE project) and the PCREregular expression library. Since forking from KJS and PCRE, JavaScriptCore has been improved with many new features and greatly improved performance.[73]

On June 2, 2008, the WebKit project announced they rewrote JavaScriptCore as «SquirrelFish», a bytecodeinterpreter.[31][32] The project evolved into SquirrelFish Extreme (abbreviated SFX, marketed as Nitro), announced on September 18, 2008, which compiles JavaScript into native machine code, eliminating the need for a bytecode interpreter and thus speeding JavaScript execution.[33]

An optimizing just-in-time (JIT) compiler named FTL was announced on May 13, 2014.[74] It uses LLVM to generate optimized machine code. «FTL» stands for «Fourth-Tier-LLVM», and unofficially for faster-than-light, alluding to its speed.[75] As of February 15 2016, the backend of FTL JIT is replaced by «Bare Bones Backend» (or B3 for short).[76]

See also[edit]

Рейтинг автора
5
Подборку подготовил
Илья Коновалов
Программист и опытный пользователь интернета
Написано статей
179
Ссылка на основную публикацию
Похожие публикации