Движок chromium что это
Что такое Chromium
Многие пользователи понятия не имеют о том, что такое Chromium, и ошибочно путают его с популярным веб-браузером Google Chrome. Названия похожи, но это не одно и то же. В данном материале мы расскажем о ключевых особенностях Хромиума.
Подробности
История Chromium началась в 2008 году. Именно тогда компания Google решила создать самый лучший в мире браузер. На тот момент было запланировано использовать высокоскоростной движок WebKit. И его начали использовать.
А вот с Java скрипами не все было хорошо. Решения, для их нормальной поддержки были проприетарными. И ребята из Google не придумали ничего лучше, чем с нуля написать собственный движок для своих нужд. Его назвали V8.
В результате появился браузер, который работал намного быстрее конкурентов и поддерживал все современные технологии. Это был звездный час Google. И все было неплохо. Пока они не перевели свое детище на движок Blink.
Что же такое Хромиум?
Chromium – это свободный браузер с открытым исходным кодом, который лишен сервисов Google и поддержки медиа контента. Если пользователю нужны какие-то специальные плагины, то он устанавливает их самостоятельно.
Ключевой особенностью проекта Хромиум является безопасность. Разработчики данного веб-обозревателя тратят уйму времени на то, чтобы залатать дыры и повысить безопасность своего продукта.
По сути, это конструктор, на основе которого любой пользователь может собрать браузер своей мечты. Компанией предоставляется исключительно основа. Все остальное юзер делает сам. С одной стороны, это хорошо, так как пользователь сам решает, что ему нужно.
С другой стороны, данный веб-обозреватель не подходит новичкам, так как его очень трудно настраивать. Так что тем, кому нужен просто стабильный браузер лучше обратить внимание на Google Chrome и подобные продукты.
Отличия от Гугл Хром
Начнем с того, что Хромиум – свободный браузер с открытым исходным кодом. Он распространяется под лицензией GNU/GPL. А Chrome использует проприетарную лицензию и его исходный код закрыт. Со всеми вытекающими.
Еще одно отличие: Chromium напрочь лишен телеметрии и механизмов сбора данных для Google. А вот в Хроме такая неприятная штука есть. Данный браузер беззастенчиво собирает информацию о пользователях и ничуть этого не стесняется.
Также в Хроме интегрирована поддержка таких форматов, как WebM, Theora, MP3, AAC и Vorbis. А Хромиум может поддерживать только свободные форматы. Вроде WebM и Vorbis. Все остальное доступно только при подключении соответствующих плагинов.
Chrome регулярно обновляется, а вот в Хромиуме механизм обновления выпилен. Данный браузер можно обновить только при помощи переустановки всего приложения. Такой способ не является удобным.
И, наконец, о стабильности. Гугл Хром априори стабильнее свободного Chromium по той простой причине, что разработкой браузера занимается целая команда. А над Хромиумом трудятся всего несколько разработчиков.
Вот чем Chromium отличается от Chrome. Естественно, большинство пользователей предпочтут стабильный и современный веб-обозреватель с поддержкой всех современных технологий. А проект Хромиум могут использовать только единицы.
Безопасность
У Хромиума весьма интересная система безопасности. Она основана на принципе песочницы. Разработчики перевели всю работу движка веб-обозревателя именно в песочницу – этакий «предбанник», ограничивающий площадь для атаки на компьютер пользователя.
Именно поэтому Chromium считается одним из самых безопасных браузеров. Вредоносные объекты просто не могут добраться до компьютера пользователя через веб-обозреватель потому, что постоянно находятся в этой самой песочнице.
Инструменты разработчика
Ключевая особенность браузера Chromium. Этот веб-обозреватель обладает богатым набором инструментов для тестирования стабильности продукта и разработки расширений для него. Именно поэтому многие профессионалы предпочитают сие приложение.
В составе веб-обозревателя присутствует продвинутая консоль, позволяющая оперативно вносить изменения в код. Это полезно для тех, кто занимается доработкой браузера в домашних условиях. И это еще одна причина, по которой данный продукт не подходит обычным пользователям.
Для каких систем существует браузер?
Chromium доступен для всех версий ОС Windows (начиная с XP), Mac OS X, Linux Mint, Ubuntu, Arch, Mandriva, Slackware, Kali Linux, CentOS, Manjaro, Red Hat Linux и других ОС. Есть даже порт для Free BSD. Хоть и неофициальный.
А вот для мобильных платформ такого браузера, увы, не существует. В отличие от того же Гугл Хром. Однако это не так страшно. Да и зачем такой конструктор на мобильной платформе? Владельцам смартфонов нужен нормальный веб-обозреватель, а не приложение «сделай сам».
Заключение
А теперь подведем итоги и попытаемся ответить на вопрос о том, что лучше: Хром или Хромиум. Все зависит от того, в какой плоскости рассматривать вопрос. Chromium лучше тем, что не следит за пользователем и обладает повышенной безопасностью.
Но в тоже время, Chrome более прост в использовании. И большинство юзеров выберут именно его, так как настраивать веб-обозреватель «под себя» очень долго и нудно. И все-таки, Хромиум действительно лучше, так как не является проприетарными продуктом.
Chromium — это не только браузер, но и хороший фреймворк
Большинство людей привыкли, что Chromium — это и браузер, и основа для других браузеров. До недавнего времени я тоже так думал, но, изучая эту тему уже пару месяцев, я начал открывать другой дивный мир. Chromium — это огромная экосистема, в которой есть всё: и система зависимостей, и система кроссплатформенной сборки, и компоненты почти на все случаи жизни. Так почему же не попробовать создавать свои приложения, используя всю эту мощь?
Под катом небольшое руководство, как начать это делать.
Подготовка окружения
В статье я буду использовать Ubuntu 18.04, порядок действий для других ОС можно посмотреть в документации:
Установка depot_tools
depot_tools — это набор инструментов для разработки Chromium. Для его установки необходимо выполнить:
И добавить путь в переменную окружения PATH:
Важно: если depot_tools были скачаны в домашнюю папку, то не используйте
Получение кода
Для начала надо создать папку для исходников. Например, в домашней директории (необходимо около 30 Гб свободного места):
После этого можно скачать исходники с помощью утилиты fetch из depot_tools :
Установка зависимостей
Теперь нужно поставить все зависимости с помощью скрипта:
На этом подготовка окружения завершена.
Система сборки
Чтобы понять, как пользоваться этими инструментами, предлагаю создать тестовую утилиту example. Для этого в папке src надо создать подпапку example :
BUILD.gn состоит из цели (исполняемого файла example ) и списка файлов, которые необходимы для сборки цели.
Исходный код можно найти на GitHub.
Теперь необходимо вернуться в папку src и сгенерировать проект с помощью команды:
GN также позволяет подготовить проект для одной из поддерживаемых IDE:
Например, для работы с проектом example в QtCreator надо выполнить команду:
После этого можно открыть проект в QtCreator:
Финальный шаг — сборка проекта с помощью Ninja:
На этом краткое ознакомление с системой сборки можно завершить.
Приложение можно запустить с помощью команды:
И увидеть Hello world. На самом деле, про систему сборки в Chromium можно написать отдельную статью. Возможно, и не одну.
Работа с командной строкой
В качестве первого примера использования кодовой базы Chromium как фреймворка предлагаю поиграться с командной строкой.
Задача: вывести на экран все аргументы, переданные приложению в стиле Chromium.
Для работы с командной строкой необходимо в example.cc подключить заголовочный файл:
Полную версию можно найти на GitHub.
Чтобы собрать и запустить приложение надо выполнить:
На экран будет выведено:
Работа с сетью
В качестве второго и последнего на сегодня примера предлагаю поработать с сетевой частью Chromium.
Задача: вывести на экран содержимое URL’а, переданного в качестве аргумента.
Сетевая подсистема Chromium
Полную версию можно посмотреть в документации.
Многопоточность
Сетевой стек Chromium расчитан на работу в многопоточной среде, поэтому пропустить эту тему нельзя. Базовыми объектами для работы с многопоточностью в Chromium являются:
Реализация
Некоторые компоненты Chromium требуют наличия base::AtExitManager — это класс, позволяющий зарегистрировать операции, которые надо выполнить при завершении приложения. Использовать его очень просто, необходимо в стеке создать объект:
Когда exit_manager выйдет из области видимости, все зарегистрированные callback’и будут выполнены.
Дальше нужно с помощью Context builder ‘а создать Context :
Теперь всё готово для отправки запроса:
Чтобы запрос начал обрабатываться, надо запустить Run loop :
Полную версию можно найти на GitHub.
Чтобы собрать и запустить приложение нужно выполнить:
Финал
Как работают над Chromium
В марте 2011 я написал черновик статьи про то, как команда, отвечающая за Google Chrome, разрабатывает и выпускает свой продукт — после чего я благополучно о нем забыл. Лишь несколько дней назад я случайно наткнулся на него. Пусть местами он уже устарел (Chrome форкнул WebKit в Blink в 2013 году, да и я сам больше не работаю в Google), я склонен считать, что изложенные в нем идеи все еще в силе.
Сегодня я собираюсь рассказать вам о том, как работает Chromium. Нет, речь пойдет не совсем о браузере Chrome, а скорее о Chromium — группе людей, занимающихся созданием браузера.
Над проектом Chromium работают сотни инженеров. Вместе мы коммитим в кодовую базу примерно 800 изменений каждую неделю. Мы также зависим от многих других больших и активно развивающихся проектов вроде V8, Skia и WebKit.
Мы отправляем новый стабильный релиз сотням миллионов пользователей каждые шесть недель, четко по расписанию. И мы поддерживаем несколько других каналов раннего доступа, которые обновляются еще быстрее — самый быстрый канал, canary, «тихо» авто-обновляется почти каждый будний день.
Каким образом все это продолжает работать? Почему «колеса» у этого «автобуса» еще не «отвалились»? Почему еще не все разработчики сошли с ума?
С технологической точки зрения, скорость работы команды Chromium стала достижима благодаря надежным, эффективным и «тихим» авто-обновлениям.
С точки зрения человеческих ресурсов, в этом есть заслуга преданных своему делу, трудолюбивых и умных команд QA и релиз-инженеров, без которых весь проект развалился бы на части в считанные недели. А еще — дизайнеров, продакт-менеджеров, писателей, PR, адвокатов, ИБ и всех остальных, кто слаженно работает над каждым стабильным релизом. Сегодня я не буду рассказывать обо всех, сконцентрировавшись только на инженерной тематике, дабы не скатиться в гигантский пост в духе Стива Йегге.
Я собираюсь рассказать о процессе разработки Chromium, который выстроен специально для того, чтобы сделать возможными быстрые релизы. Речь пойдет об интересных находках, которые могут пригодиться другим проектам вне зависимости от того, как выглядит их график релизов; упомяну я и о наших трудностях.
Без веток
Во многих проектах общепринятой практикой является создание ветки для работы над новыми «мажорными» фичами. Идея при таком выборе заключается в том, что дестабилизация из-за нового кода не будет влиять на других разработчиков и пользователей. Как только фича завершена, она мерджится обратно в trunk, после чего обычно следует период нестабильности на то время, пока устраняются интеграционные вопросы.
С Chrome этот подход не сработает, поскольку мы релизимся каждый день. Мы не можем допустить внезапного появления в нашем trunk больших кусков нового кода, поскольку в таком случае велика вероятность, что каналы обновления canary или dev надолго уйдут в отказ. Кроме того, trunk в Chrome движется вперед с такой скоростью, что для разработчиков непрактично оставаться изолированными на своей ветке на слишком долгий промежуток времени. К тому времени, когда они смержат свою ветку, trunk будет выглядеть настолько по-другому, что интеграция будет трудоемкой и легко подвержена ошибкам.
Мы создаем эксплуатационные ветки перед каждым нашим релизом беты, но они живут очень недолго — максимум всего шесть недель, до следующего релиза беты. И мы никогда не ведем разработку непосредственно в этих ветках — все запоздавшие фиксы, которые должны войти в релиз, сначала делаются в trunk, после чего будет сделан cherry-pick в ветку.
Приятный побочный эффект подобного процесса: в проекте нет специальной команды разработчиков «второго сорта», которые занимаются исключительно работой с эксплуатационной веткой. Все разработчики всегда работают с последней актуальной версией исходного кода.
Переключатели среды выполнения
Пусть мы и не создаем ветки, но по-прежнему нуждаемся в способе прятать незавершенные фичи от пользователей. Естественным способом делать это является использование проверок времени компиляции; его проблема заключается в том, что подобный подход несильно отличается от создания веток с кодом — по сути, вы по-прежнему имеете две независимые кодовые базы, которые однажды должны быть смержены. И, поскольку новый код по умолчанию не компилировался и не тестировался, разработчикам не составит трудности нечаянно этот код поломать.
Вместо этого, проект Chromium использует проверки исполняющей среды. Каждая фича, находящаяся в разработке, компилируется и тестируется на всех конфигурациях с самого начала. У нас есть флаги командной строки, которые мы тестируем в самом начале; в остальных местах кодовая база по большей части не имеет представления о том, какие функции доступны. Данная стратегия означает, что работа над новыми фичами интегрирована в код проекта с самого начала в максимально возможном объеме. По крайней мере, новый код комплируется, так что все изменения в основном коде, которые необходимо сделать для работы новой функции, протестированы, а пользователь считает, что все работает как обычно и не замечает разницы. Ну а мы можем легко писать автоматические тесты, которые проверяют работу недоступных пока фич, временно «переопределяя» командную строку.
Когда фича подбирается ближе к завершению, мы презентуем опцию в виде флага в chrome://flags, чтобы продвинутые пользователи могли начать ее тестировать и сообщить нам обратную связь. В итоге, когда мы думаем что фича готова к выпуску, мы всего лишь удаляем флаг командной строки и делаем ее доступной по умолчанию. К этому времени код уже обычно протестирован вдоль и поперек, а также обкатан многими пользователями, так что потенциальный ущерб от его активации сведен к минимуму.
Огромный объем автоматического тестирования
Для того, чтобы релизиться каждый день, мы должны быть уверены в том, что наша кодовая база всегда находится в надлежащем состоянии. Это требует автоматизированных тестов, причем очень большого их числа. На тот момент, когда пишутся эти строки, у Chrome есть 12k юнит тестов уровня классов, 2k автоматизированных интеграционных тестов и огромные ассортимент тестов производительности, bloat-тесты, тесты на thread safety и memory safety, а также, возможно, многие другие, о которых я сейчас не вспомню. И все это только для одного Chrome; WebKit, V8 и остальные наши зависимости тестируются самостоятельно; у одного WebKit насчитывается примерно 27k тестов, которые удостоверяются, что веб-страницы отображаются и функционируют корректно. Наше основное правило заключается в том, что каждое изменение должно идти вместе с тестами.
Мы используем публичный buildbot, который постоянно прогоняет новые изменения в нашем коде на тестовом наборе (test suite). Мы придерживаемся политики «зеленого дерева»: если изменение «ломает» тест, то оно тут же откатывается, а разработчик должен пофиксить изменения и перевыложить их. Мы не оставляем подобных «критические» изменений в дереве, поскольку:
Чтобы помочь разработчикам избежать неприятностей с деревом, у нас есть try-боты, которые являются способом «прогнать» изменение подо всеми тестами и конфигурациями перед тем, как выпустить его. Результаты отправляются на email разработчику. Еще у нас есть commit queue, которая служит для теста изменения и его автоматического применения, если все тесты пройдут успешно. Мне нравится пользоваться ею после долгой ночи, проведенной за хакингом — я нажимаю кнопку, ложусь спать, и спустя какое-то время просыпаюсь с надеждой на то, что мое изменение влито.
Благодаря всему производимому автоматическому тестированию, мы можем отделаться минимальным количеством ручного тестирования на нашем канале dev, а на «канарейках» не проводить его совсем.
Безжалостный рефакторинг
Поскольку у нас есть достаточно обширное покрытие тестами, мы можем позволить себе быть агрессивными в рефакторинге. В проекте Chrome все время идет работа над рефакторингом в нескольких основных направлениях — например, на период 2013 года таковыми являлись Carnitas и Aura.
При наших масштабах и темпе, критически важно держать кодовую базу чистой и доступной для понимания. Для нас эти качества более важны, чем предотвращение регрессий. Инженеры всего проекта Chrome имеют право делать улучшения в любом месте системы (однако, при этом мы можем запросить обязательное ревью владельца модуля). Если в результате рефакторинга что-нибудь в итоге ломается, причем это не удается обнаружить на этапе тестирования, то с нашей точки зрения это вина не того инженера, который делал рефакторинг — а того, чья фича была недостаточно покрыта тестами.
WebKit развивается не менее быстрыми темпами. И, аналогично тому, что мы не можем позволить себе иметь ветки для фич, которые когда-нибудь внезапно вольются в основную, мы не можем позволить себе пытаться смержить месячный набор изменений в WebKit весь и сразу, поскольку это дестабилизирует дерево на несколько дней.
Вместо этого мы пытаемся скомпилировать Chrome вместе с самой последней версией WebKit (почти всегда эта версия не старше половины дня), пока не достигнем успеха. В корне проекта Chrome лежит файл, который содержит версию WebKit, с которой он сейчас успешно компилируется. Когда вы делаете чекаут и создаете рабочую копию, или же обновляете исходный код Chrome, то инструмент gclient автоматически получает версию WebKit, указанную в файле.
Ежедневно несколько раз в день инженер обновляет номер версии, выясняет, возникли ли новые проблемы при интеграции, и присваивает баги подходящим инженерам. В результате, мы всегда получаем мелкие изменения в WebKit все сразу, и при подобном подходе оказываемый на наше дерево исходников эффект обычно минимален. Мы также добавили ботов к buildbot WebKit’a, благодаря чему когда инженеры WebKit делают изменение, которое поломает Chrome, они узнают об этом немедленно.
Большим преимуществом системы DEPS является то, что мы можем добавлять изменения к своей веб-платформе очень быстро. Появившаяся в WebKit фича станет доступной пользователям Chrome на канале canary в течение всего лишь нескольких дней. Это сподвигло нас к тому, чтобы делать улучшения сразу в апстриме WebKit, где они пригодятся всем, кто использует WebKit в своих приложениях, а не применять их локально у себя в Chrome. Честно говоря, нашим основным правилом является то, что мы вообще не делаем локальных изменений в WebKit (как и в остальных проектах, от которых зависит Chrome).
Проблемы
Тщательное тестирование остается неразрешенным вопросом. В частности, «нестабильные» интеграционные тесты (flaky integration tests) стали для нас постоянной проблемой. Chrome — большой, сложный, асинхронный, мультипроцессовый и многопоточный. Так что для интеграционных тестов проще простого проваливаться из-за едва различимых проблем синхронизации, что и происходит время от времени. На проекте наших размеров, тест, который фейлится 1% времени, в итоге гарантировано будет фейлиться по несколько раз в день.
Как только тест становится «нестабильным», команда быстро приобретает привычку его игнорировать, в следствие чего бывает просто упустить фейл другого, рабочего теста для той же части кода. Поэтому мы склонны отключать «нестабильные» тесты и теряем в проценте покрытия, делая проще выпуск основных регрессий для пользователя.
Другая проблема состоит в том, что на такой скорости становится тяжело «наводить красоту». Как по мне, команде проще добиться правильного выполнения всех деталей в редких «громких» релизах, чем пытаться сохранить и постоянно удерживать фокус внимания на каждой мелочи в течение неопределенного времени. Поскольку зачастую тестировать мелкие детали вроде расстояния между кнопками в панели инструментов бывает тяжко, в таких местах легко закрадываются ошибки.
Наконец, мне кажется, что вполне себе реальной проблемой является стресс. Учитывая весь этот код, который постоянно меняется, даже если человек пытается сфокусироваться только на своей зоне ответственности, это не значит, что его не заденет что-то происходящее в другой части проекта. Если вы постоянно пытаетесь сохранить вашу часть Chrome в работоспособном состоянии, то рано или поздно вам начнет казаться, что вы живете как на вулкане, и не можете себе позволить ни минуты спокойствия.
С последней проблемой мы боремся при помощи разбиения кодовой базы на основные модули. Инженеры, занимающиеся задачами Carnitas, пытаются установить более ясные и жесткие интерфейсы между некоторыми из наших главных компонентов. На данный момент, значительная часть кода стала чище и яснее, но пока еще слишком рано говорить о том, насколько это поможет уменьшению стресса на глобальном уровне.
В заключение
Итак, благодаря чему «колеса» у нас пока еще не «отвалились»? Вкратце: благодаря жизни без веток, переключателям среды выполнении, тоннам автоматических тестов, безжалостному рефакторингу, и удержанию позиций как можно ближе к HEAD наших зависимостей.
Эти техники будут наиболее полезны большим проектам, у которых есть быстро изменяющиеся апстрим-зависимости, но вполне возможно, что некоторые из них окажутся применимы и к проектам меньших размеров.
Движок, который смог: как Chromium удалось захватить 90% рынка браузеров
От браузерного движка, который изначально был малоизвестной альтернативой, применявшейся в непопулярном браузере, до чемпиона, захватившего весь рынок.
Вероятно, иногда вы встречаете в текстах понятие браузерное разнообразие. Под ним подразумевается равновесие на платформе веба, при котором в мире существует множество реализаций браузеров, достаточное для стимулирования инноваций и конкуренции между ними. Альтернативой этому является монокультура браузеров, при которой один браузер или реализация браузера контролирует весь рынок, а значит, и управляет развитием веба. Когда кто-то содействует браузерному разнообразию, он часто делает это ради процесса создания независимых веб-стандартов, поддерживаемых W3C, который работает только когда ни один из браузеров не может диктовать функции, включаемые в платформу веба.
У веб-сообщества есть достаточно причин опасаться отсутствия браузерного разнообразия. После того, как Internet Explorer захватил в начале 2000-х долю 90% от рынка браузеров, для выпуска нового браузера его разработчикам потребовалась добрая половина десятилетия. В тот период развитие веба остановилось, и начали возникать проблемы с безопасностью. Из-за этого веб стал хуже, поэтому мы часто стремимся к тому, чтобы браузеры конкурировали, а не монополизировали веб.
Но у этой проблемы есть и обратная сторона. Из-за существования нескольких создателей браузеров веб-разработчикам необходимо обеспечивать совместимость всех платформ. Между браузерами могут присутствовать хоть и незначительные, но несоответствия, что может усложнять разработку для веба.
Это беспокоило создателя веба Тима Бернерса-Ли. Даже в начале 90-х, когда веб был очень юным, по всему миру в процессе экспериментов разработчиков ПО начали появляться десятки браузеров. Бернерса-Ли волновало, что слишком большое количество браузеров усложнит тестирование сайтов и достижение консенсуса о способах парсинга и передачи HTML пользователям.
В 1992 году Тим Бернерс-Ли высказал своё беспокойство в списке рассылки, посвящённом гипертексту.
Никто не будет поддерживать 8 парсеров на 12 платформах, поэтому я немного обеспокоен развитием реализаций. (Да, разумеется, в то же время мне это приятно! Но я бы хотел видеть одну, может быть, две основные библиотеки (две, чтобы тестировать одну из них на наличие непротиворечивых багов), но не четыре. Мне кажется, это слишком много; будут возникать ситуации, когда небольшие тонкости работают в одной, но не в других библиотеках, потому что на поддержку каждой не хватило труда по поддержке.
Бернерс-Ли осознавал, что множественные реализации могут потребовать слишком много усилий со стороны веб-разработчика, поэтому разработчики могут испытывать искушение полностью избежать этой проблемы и проводить тестирование только в самом популярном браузере (он и не подозревал, что подобная проблема будет часто возникать в веб-разработке). То есть даже без монополии слишком большое количество браузеров может заполонить рынок и создать фактического победителя, относительно которого будут создаваться стандарты без учёта всех остальных. Обеспечение непротиворечивости всех реализаций браузеров стало причиной создания W3C и продвижения набора общих стандартов в веб-технологиях.
Озабоченность Бернерса-Ли имела основания. Иногда возникали ситуации, когда браузеры шли собственным путём, заставляя веб-дизайнеров изощряться, чтобы страницы выглядели везде одинаково. В последние годы устоявшийся процесс стандартизации во многом позволил решить проблему несоответствий между браузерами благодаря созданию чёткого процесса добавления новых возможностей веба, гарантирующего баланс в процессе принятия решений.
Фундаментальной основой для создания разнообразной группы браузеров является развитие совершенно разных браузерных движков. Браузерный движок — это программный код внутри браузера, который получает написанный вами код и рендерит его на странице. Если смотреть на более техническом уровне, то он парсит HTML, CSS и JavaScript для обработки структуры и рендеринга веб-страниц. Движок обычно включает в себя JavaScript-движок, обрабатывающий интерактивность. Чаще всего при обсуждении браузерного движка говорят и о связанном с ним JavaScript-движке, но так бывает не всегда.
До того, как разработчики браузеров начали использовать веб-стандарты, во время «войн браузеров», был длившийся десяток лет период доминирования браузера Internet Explorer компании Microsoft. В Internet Explorer использовался проприетарный браузерный движок Microsoft под названием Trident. Internet Explorer распространялся бесплатно и по умолчанию был установлен на всех компьютерах с Windows. Благодаря своей скорости распространения Trident на долгие годы стал наиболее широко используемым браузерным движком.
Однако вскоре начали набирать популярность несколько более мелких браузеров с открытым исходным кодом. Самым популярным из них был Mozilla Firefox (основанный на Netscape), в котором использовался движок под названием Gecko. Немного отставала от него Opera со своим браузерным движком Presto. А небольшому сообществу полюбился браузер Konqueror с движком KHTML, имевший крошечную долю рынка браузеров.
Исходный код всех этих браузерных движков, за исключением Presto, был открытым, то есть он был доступен любому и его можно было использовать в любом проекте. Это стимулировало совместный труд и здоровую конкуренцию между такими новыми браузерами, благоприятствовавшими процессу создания стандартов веба под управлением W3C. А благодаря открытости исходников на рынке появилось большое количество мелких, нишевых браузеров, построенных на основе тех же браузерных движков.
Примечательно отсутствие в этом списке Apple. В 2003 году казалось, что компания совершенно упустила из виду платформу веба. Она неудачно пыталась создать собственный браузер под названием Cyberdog. Без нативного для своей ОС браузера компьютеры Apple поставлялись с Internet Explorer, который привязывал их к одному из самых серьёзных конкурентов — к Microsoft.
Но затем начали циркулировать слухи, что Apple работает над новым браузером. В компанию пришло несколько ветеранов из Mozilla, от имени Apple внесших вклад в Mac-версию браузера Firefox с открытыми исходниками. А после первого провалившегося эксперимента инструменты и реализации стали намного лучше. Существовало уже много созревших решений на основе open source.
Изначально предполагалось, что Apple выберет в качестве браузерного движка Mozilla Gecko. У неё уже были нужные сотрудники и опыт работы с ним, к тому же этот движок использовался в подавляющем большинстве проектов браузеров, в том числе браузера для Mac под названием Camino, разработанного независимой командой, не относящейся к Apple. Некоторые считали, что Apple может выбрать Presto, заключив некий договор по лицензированию.
Стив Джобс завершил свою программную речь на Macworld 2003 долгожданным объявлением: Apple создаёт собственный браузер под названием Safari. И ко всеобщему удивлению, в нём будет использоваться движок из Konqueror. Не Gecko, не Presto. KHTML. Новость была громкой, и в следующие два десятилетия она изменила траекторию развития веба.
Браузер Konqueror, запущенный в среде рабочего стола KDE
Браузер Konqueror — это одно из множества приложений, являющихся частью среды рабочего стола KDE для компьютеров с Linux. Строго говоря, это не операционная система, а пакет программного обеспечения, выглядящий и ведущий себя как ОС. Аббревиатура изначально расшифровывалась как Kool Desktop Environment, но потом была сокращена просто до KDE. Konqueror — это одна из программ внутри KDE. А KHTML — это движок, на котором работает Konqueror. Как и сам Linux, вся KDE имеет открытый исходный код, в том числе и её браузер, а сообщество разработчиков с самого основания придерживалось принципов открытого программного обеспечения.
Именно поэтому важно, что в объявлении Apple присутствовал этот слайд:
В своём объявлении о выборе KHTML Apple заявила о приверженности идеям open source. Команда разработчиков Safari пообещала по возможности вносить сделанные ею изменения в проект KHTML. При адаптировании движка Apple разбила его на две части: WebCore, занимающийся рендерингом и структурой, и JavaScriptCore, занимающийся JavaScript. Обе этих части стали проектами с открытым исходным кодом, однако система отслеживания ошибок Safari и элементы браузерного движка остались закрытыми. И всё же такой уровень прозрачности был удивителен для компании, хорошо известной охраной своих секретов.
Первая публичная версия Safari была выпущена одновременно с объявлением, в январе 2003 года. Вскоре после этого Safari начал поставляться как стандартный браузер для всех Mac. В течение одного-двух лет Safari стабильно занимала два-три процента от рынка браузеров. Этого не было достаточно, чтобы доминировать, но придавало вес команде разработчиков из Apple.
Несмотря на обещание, данное сообществу open source, разработчикам Safari поначалу оказалось сложно портировать вносимые ими изменения обратно в проект KTHML. Часть кода была специфичной для операционной системы Mac. Другие части были просто несовместимыми с существующей кодовой базой. Это привело к небольшим разногласиям между командой Apple и соавторами KHTML, длившимся пару лет.
Со временем был найден устраивающий всех компромисс. В июне 2005 года Apple объединила JavaScriptCore, Webcore и остальные компоненты браузерного движка, выпустив их как единый проект open source с публичным баг-трекером и призывом участвовать в развитии. Таким образом компания показала сообществу KHTML, что готова к сотрудничеству, сохраняя при этом независимость кода.
Проект назвали Webkit.
Критически важным оказался выбранный момент. Веб как платформа ускоренно развивался и находился на этапе Web 2.0. В целом, Web 2.0 был просто красивым маркетинговым термином, попыткой дать название росту количества сложных приложений, существующих исключительно в вебе. В него вошли два самых первых веб-приложения Google — Google Maps и Gmail. В течение года Google добавила в этот список и YouTube.
В середине 2000-х годов инженеры Google пристально пригляделись к браузерам и обнаружили, что те неспособны удовлетворить потребность в создании сложных приложений. Особенно справедливо это было в отношении старых и необслуживаемых браузеров наподобие Internet Explorer (кстати, к стимулированию отказа пользователей от IE6 приложил руку и YouTube). Но основным приоритетом Google была скорость. Сооснователи компании однажды выразили желание создать «веб столь же быстрый, как перелистывание бумажного журнала». Такой стала цель компании, и Google чувствовала, что даже современные браузеры типа Firefox и Safari приближались к ней недостаточно быстро.
К 2006 году компания начала строить планы по созданию собственного браузера. Она хотела иметь самый быстрый на рынке браузер. Поэкспериментировав со множеством браузерных движков, разработчики Google обратили внимание на проект Webkit, который перешёл в open source. Его код был компактным и читаемым, а ресурсоёмкость оставалась относительно низкой по сравнению с движками с богатой историей наподобие Gecko или Trident (последний в любом случае не рассматривался из-за закрытости своих исходников). Но, что самое важное, он был быстрым. Как отправная точка он был быстрее всех остальных движков.
Если бы команда Safari не решила открыть исходники своего браузерного движка именно в этом время, история могла бы развиваться совершенно в ином направлении. Но разработчики поступили так, поэтому Google изучила эту возможность и решила использовать движок. В следующую пару лет она начала работать над новой, ещё более быстрой реализацией Webkit.
Её первым шагом стало избавление от JavaScriptCore и замена его на собственный JavaScript-движок под названием V8, названный в честь мощного поршневого двигателя. Как можно понять из названия, V8 был быстрым. На момент выпуска он оказался в десять раз более производительным, чем JavaScriptCore. Он добился этой скорости благодаря работе в виртуальной машине и немного иному способу исполнения кода, делавшему его модульным и независимым от остальной части браузерного движка. Кстати, спустя пару лет эта модульность обеспечила возможность создания языка программирования Node: его разработчики взяли движок V8, избавились от браузера и поместили его на сервер.
Второе, что сделала Google — добавила в свой браузер многопроцессную архитектуру. О многопроцессности можно сказать многое, но лучше всего её объяснить на примере вкладок браузера. Раньше с «вылетом» одной вкладки аварийно завершалась работа всего браузера. Однако Google удалось заставить выполняться процессы в каждой вкладке независимо, чтобы за раз «вылетала» только одна вкладка. После выпуска браузера это стало его основным привлекательным качеством. Кроме того, это оказалось важным решением, потому что стало серьёзным отходом от того, как Webkit работал ранее. Вскоре это решение ещё аукнется компании.
В сентябре 2008 года Google официально объявил о проекте своего браузера публике. Компания совместила объявление с нердовским веб-комиксом Скотта Макклауда, в котором подробно описывались все технические подробности проекта. Браузер мог обрабатывать веб-сайты быстрее всех на рынке, а благодаря своей многопроцессной архитектуре был способен сохранять активность страниц, даже когда зависал какой-нибудь другой сайт. Это было в те времена, когда браузеры до сих пор были перегружены панелями инструментов и аддонами, а также пакетами больших компаний, в которые была включена и почта. Имя, данное Google этому проекту, тоже соответствовало концепции. В мире браузеров под понятием «хром» (chrome) подразумевается всё дополнительное, что окружает веб-страницу — адресная строка, панели инструментов и файловые меню. Google избавилась от большинства этого хлама, поэтому и назвала браузер Google Chrome, надеясь, что ставка на простоту и производительность оправдает себя.
Фрагмент веб-комикса, с которого всё началось
Если не считать закрытого алгоритма поиска, Google многие годы делала вклад в проекты с открытым кодом и создавала новые. Поняв урок Apple, компания при разработке Chrome зашла ещё дальше. В тот же день, когда было объявлено о выпуске Google Chrome, компания сделала весь движок доступным как open-source-проект под названием Chromium. Это не просто несколько расширений для Webkit. Это не просто движок рендеринга. Открытым стало всё: Webkit, JavaScript-движок V8 и весь код самого браузера. Без особых усилий любой разработчик мог дополнить Chromium и выпустить собственный браузер. После его выпуска со многими браузерами так и случилось.
2008-й стал важным годом для веба. В том же месяце, когда был выпущен Chrome, Google показала прототип своей мобильной операционной платформы Android, собранной из нескольких проектов с открытыми исходниками. В него входила и мобильная версия Google Chrome. Это произошло чуть более года спустя официального выпуска iPhone, который поставлялся с модифицированной версией Safari. К тому времени, когда Стив Джобс приступил к безвозвратному «убийству» Flash и начал превращать в основной приоритет нативную платформу веба, эти устройства уже были повсюду.
То есть теперь в каждом мобильном смарт-устройстве работал Safari или Chrome. Сама Safari целиком благодаря покупкам iPhone всего за несколько лет удвоила свою долю на рынке. Популярность Chrome росла ещё быстрее. Используя Chromium, вы получали доступ к постоянно расширяющемуся списку независимых браузеров и браузерных проектов. Кроме того, Chromium стал основой языка программирования Node и фреймворка для десктопных приложений Electron.
И все эти проекты работали благодаря Webkit. За несколько лет он совершил путь от захвата небольшой доли рынка браузеров до доминирования на нём.
Такое состояние покоя было недолгим. В апреле 2013 года Google неожиданно объявила, что создаст ответвление (форк) проекта Webkit в новый движок под названием Blink. Google Chrome и проект Chromium будут переходить на этот новый движок.
У такого перехода было несколько причин, но важнейшая из них возвращает нас к вопросу многопроцессности. Несколько лет Google расширяла Webkit, чтобы добавить в свои браузеры многопроцессность, ставшую важнейшей особенностью и основанием роста производительности браузеров Chromium. В 2013 году проект Webkit должен был выпустить новую версию движка, которая улучшала в том числе и многопроцессность. Проблема заключалась в том, что её реализация стала бы совершенно другой и несовместимой с реализацией в Chrome. В нём уже использовался другой JavaScript-движок и это новое изменение слишком сильно бы отодвинуло Chromium от исходного проекта. Ядром Blink по-прежнему должен был оставаться и остаётся Webkit. Но он пойдёт по другому пути и создаст себе новый проект.
На этом этапе веб стал более сложным, чем кто-либо мог себе представить. Проблема, которую впервые изложил Бернерс-Ли — слишком большое количество независимых разработчиков, создающих собственные браузерные движки — больше не была проблемой. Для сборки и поддержки браузерного движка теперь требовались большие коллективы. С расширением платформы веба и укрепления его стандартов сложность рендеринга веб-сайта в страницу росла экспоненциально. Браузер должен был исполнять бесчисленное количество сайтов, закодированных бесчисленным количеством способов так, чтобы более-менее соответствовать всем остальным браузерам.
После этого момента браузерные движки начали исчезать.
За два месяца до выпуска Blink компания Opera объявила, что откажется от собственного движка Presto и перенесёт свой браузер на Chromium. Когда Google объявила о форке, Opera присоединилась к ней. В мае 2013 года она выпустила свой первый браузер на основе Blink.
Тем временем Microsoft многие годы придерживалась собственного движка с закрытым исходным кодом. Trident был преобразован в движок под названием EdgeHTML, созданный для браузера Microsoft Edge, впервые выпущенного в 2015 году. Но вкладывание ресурсов в разработку независимого движка оказалось слишком сложной задачей на уже заполненном рынке браузеров. В 2019 году компания объявила, что тоже переходит на Blink. С тех пор этот браузер тоже выпускается.
Потомков KHTML, то есть браузеры, имеющие движки из семейства Blink / Webkit, используют более 90% пользователей. От практического забвения до доли рынка в 90% за пятнадцать лет — потрясающее достижение. И оно имело последствия.
Blink и Webkit — это два разных движка, и в их исходном коде стало довольно много различий. Но они используют одинаковый подход к рендерингу веб-страниц, а бо́льшая часть кода внутри проекта остаётся такой же. Это означает, что на текущем этапе, по сути, осталось две группы браузерных движков — семейство Blink / Webkit и Gecko браузера Firefox. Даже если разделить Blink и Webkit, то всё равно остаётся только три.
И это возвращает нас к вопросу браузерного разнообразия. Инновации в браузерных технологиях не исчезли, и, к счастью, каждый серьёзный браузер привержен процессу стандартизации веба. Однако если сообщество Blink и Webkit решит, что оно хочет двигать веб в определённом направлении, то будет обладать всей необходимой для этого властью. Это справедливо даже сегодня, несмотря на то, что Gecko всё ещё держится.
Джеффри Зельдман хорошо резюмировал это в момент, когда Microsoft решила переходить на Blink:
Когда одна компания решает, какие идеи стоит поддерживать, а какие нет, какие проблемы с доступом важны, а какие нет, это подавляет инновации, уничтожает конкуренцию и открывает возможности исключения людей из работы с цифровой информацией.
С исторической перспективы траектория развития Webkit является настоящим чудом. И оно возникло благодаря открытости и поддержке сообщества. Но столь же важно поддерживать браузерное разнообразие и возможности инноваций.
В этом посте рассказано о пяти вехах истории развития веба.
Источники
На правах рекламы
Наша компания предлагает безопасные серверы с бесплатной защитой от DDoS-атак. Возможность использовать лицензионный Windows Server на тарифах с 2 ГБ ОЗУ или выше, создание резервных копий сервера автоматически либо в один клик.
Используем исключительно быстрые серверные накопители от Intel и не экономим на железе — только брендовое оборудование и одни из лучших дата-центров в России и ЕС. Поспешите проверить.