Google chrome library что это
Краткое описание:
Браузер Chrome для мобильных устройств на базе Android.
Google Chrome – это удобный, быстрый и безопасный браузер. Он создан специально для Android. В Chrome вам доступны персонализированные новости, быстрый переход на любимые сайты, скачивание контента, а также встроенные Google Поиск и Google Переводчик.
Расходуйте меньше времени и трафика благодаря специальному режиму в Chrome.
Браузер сжимает текст, изображения, видео и сайты без потери качества, что позволяет экономить до 60% трафика.
Получайте доступ к контенту в одно касание.
В Chrome можно не только пользоваться быстрым Google Поиском, но и открывать любимые сайты (например, новостные ресурсы или социальные сети) на новой вкладке одним нажатием. Кроме того, в Chrome есть встроенная функция поиска. Просто нажмите на слово или словосочетание, чтобы найти его в Google, не покидая исходную веб-страницу.
Скачивайте контент и открывайте его в офлайн-режиме.
Специальная кнопка в Chrome позволяет скачивать видео, изображения и целые веб-страницы в одно касание. Все скачанные файлы сохраняются на одноименной вкладке Chrome и становятся доступны в офлайн-режиме.
Защитите телефон, используя Безопасный просмотр.
Встроенную функцию Chrome. Если она включена, при попытке открыть опасный сайт или скачать подозрительный файл в Chrome появится соответствующее предупреждение.
Используйте голосовое управление.
Просто скажите Chrome, что нужно сделать. Находите нужную информацию в Google с помощью голосового поиска, быстро открывайте и просматривайте веб-страницы где угодно и когда угодно.
Переводите текст на экране.
Благодаря встроенному Google Переводчику вы можете переводить целые веб-страницы в Chrome одним нажатием.
Получайте персональные рекомендации.
Chrome запоминает и учитывает ваши интересы. Открыв новую вкладку в Chrome, вы увидите статьи, выбранные на основе вашей истории просмотров. Чтобы сделать поиск в Google ещё быстрее, Chrome может предлагать вам варианты запросов и веб-адресов – они будут появляться по мере ввода.
Сохраняйте конфиденциальность.
Веб-страницы, открытые в режиме инкогнито, не сохраняются в истории просмотров.
Синхронизируйте данные.
При входе в Chrome закладки, пароли и настройки автоматически синхронизируются и становятся доступны на всех ваших устройствах.
Требуется Android: 6.0+
Русский интерфейс: Да
Разработка приложений для Chrome: обзор
На Хабре публиковалось немало статей о создании расширений для Chrome, но тема разработки Chrome приложений (они же Chrome apps) затрагивалась заметно реже. В последнее время она стала актуальнее из-за распространения устройств на ChromeOS. К тому же инфраструктура для создания приложений для Chrome стала более стабильной и удобной для использования. В этой статье я постараюсь ответить на основные вопросы: зачем вообще писать приложения для Chrome, чем они отличаются от расширений, веб-сервисов, десктопных приложений и т.п., а также как они разрабатываются, и какие на них накладываются ограничения. Если эта тема вызовет интерес, у статьи будут продолжения, затрагивающие более специальные вопросы.
Зачем
Одну и ту же функциональность можно реализовать с помощью совершенно разных технологий: можно написать программу для Windows, сделать web-сервис, мобильное приложение для Android и/или iOS и т.д. Что может подтолкнуть автора сделать выбор в пользу приложения для Chrome?
Packaged apps и hosted apps
Все видели в списке установленных по умолчанию в Chrome приложений иконки Поиска, Gmail, Google Диска. Если нажать на одну из них, ничего похожего на приложение не открывается. Вместо этого, пользователь просто переводится на страничку соответствующего сервиса.
Дело в том, что существует два принципиально разных типа приложений: hosted app и packaged app. К сожалению, устоявшихся русских терминов для них нет. Поиск, Gmail и т. д. — относятся к hosted. Такое приложение состоит из файла manifest.json с URL и настройками безопасности, и иконки. Фактически, hosted app — это специальная закладка на онлайн-сервис.
В отличие от hosted, в случае packaged app, все файлы, необходимые для работы приложения хранятся на компьютере пользователя. Такие приложения, как правило, могут лучше работать offline, могут управлять своими окнами, и вообще имеют доступ к большему количеству программных интерфейсов Chrome.
В дальнейшем речь пойдёт о packaged apps.
Приложения и расширения
С точки зрения пользователя, расширения и приложения выполняют абсолютно разные функции: расширение изменяет то, как он пользуется браузером, а приложение выполняет какую-то отдельную от браузера задачу. Расширение меняет содержание страниц и, возможно, добавляет пару кнопок, а приложение как правило работает в своём собственном окне.
В то же время, есть и значительные отличия. Приложения могут пользоваться функциями, недоступными для расширений:
Особенности разработки
Я уже упоминал, что с точки зрения пользователя приложения Chrome мало отличаются от обычных программ. В то же время с точки зрения программиста они устроены совсем по-разному. Какие-то операции оказываются проще, какие-то — сложнее.
Многие интерфейсы, использующиеся приложениями, являются общепринятыми стандартами и хорошо известны всем веб-разработчикам. Для UI используются HTML и CSS, для работы с HTTP — XMLHTTPRequest и т.д.
В Chrome приложении практически без дополнительных усилий реализуется синхронизация между экземплярами приложения на разных компьютерах. Работа с файлами, как и все прочие интерфейсы, зависящие от внешних ресурсов, устроена асинхронно. С одной стороны, это несколько усложняет код для соответствующих операций, с другой — гарантирует отзывчивость интерфейса и предотвращает блокировки.
Ещё одна особенность Chrome — управление безопасностью. В Chrome оно устроено иначе, чем в классических операционных системах и больше напоминает систему безопасности в Android. К добавлению програмных интерфейсов разработчики Chrome всегда подходили консервативно. При разработке системы легче со временем ослабить ограничения безопасности, чем сделать их более строгими. В результате, например, у приложений отсутствует неограниченный доступ к файловой системе. Главным образом, они работают с файлами, либо принадлежащими приложению, либо явно открытыми пользователем.
Чем можно пользоваться кроме HTML + JavaScript
Основным языком программирования для Chrome является, естественно, JavaScript. Но это не значит, что весь ваш код необходимо переписывать на нём. Есть несколько решений, позволяющих использовать в Chrome приложении код на других языках программирования. Среди них:
Пример
В заключении приведу пример приложения, над которым я сам работал (и
работаю). Это текстовый редактор Text. Код редактора доступен на гитхабе. Для собственно редактирования используется библиотека CodeMirror. Приложение реализует работу с файлами, окнами, сохранений настроек и прочие необходимые функции.
Расширения Chrome для программистов и сочувствующих
На Хабре уже есть посты в духе «10 браузерных расширений, которые нужны КАЖДОМУ УВАЖАЮЩЕМУ СЕБЯ РАЗРАБОТЧИКУ». Но меня смущает, что там вперемешку совсем разные вещи для разных людей. От React Developer Tools до съёмки скринкастов — и всё это просто списком через запятую. Очевидно, что с React работает не каждый.
Поэтому захотелось сделать более структурированный пост с разделением на тематические категории. По которому можно и получить представление «что вообще бывает», и найти что-то конкретно для себя.
Конечно, приветствуются дополнения в комментариях, мне известно далеко не всё. И необязательно ограничиваться Chrome, можно рекомендовать и расширения к другим браузерам.
Неайтишное
Для разминки — универсальные расширения, которые могут помочь не только IT-специалистам, но и другим людям.
Браузер — сам по себе рабочий инструмент, которым тоже нужно уметь пользоваться: если открыт миллион вкладок и в итоге нужную не найти, это печально. Некоторым на этом пути становится недостаточно дефолтной системы работы с вкладками и нужно что-то мощнее. Для таких есть целая россыпь разных расширений, по-разному модифицирующих вкладки: Tree Style Tab, OneTab, Toby и другие.
Раз вы на Хабре, явно читаете длинные тексты — Pocket создан, чтобы сохранять их «на попозже» и с комфортом читать даже в офлайне (например, в самолёте). Тут расширение — это лишь часть сервиса: собственно чтение происходит на отдельном сайте или в приложении, но благодаря расширению любой открытый текст можно добавить в Pocket одним кликом.
Если ощущаете, что слишком отвлекаетесь на Хабр или другие сайты — в StayFocusd можно выставить временные ограничения, после которых Chrome просто перестаёт их открывать. А DF Tube убирает с YouTube всё отвлекающее вроде рекомендаций: не получится так, что зашёл посмотреть что-то нужное, а в итоге залип на котиках.
Понятно, что в категории продуктивности вообще есть много всего: и «помидорные» тайм-трекеры (вроде Marinara), и todo-листы (скажем, Todoist), и сюда же можно отнести проверку грамотности (Grammarly для тех, у кого рабочая переписка на английском, а LanguageTool и в русский умеет).
Общеайтишное
Теперь о том, что как-либо связано с IT, но без строгой привязки к специализации пользователя.
Моя любимая ниша: «чтобы браузер напоминал редактор vim» (как можно догадаться, такое подойдёт не всем, зато любителей очень порадует). Расширения Vimium, cVim и Surfingkeys придуманы для управления браузером с клавиатуры и используют некоторые идеи vim (но без мучений «как отсюда выйти»). Нажимаешь хоткей — и рядом с каждым кликабельным элементом появляется буквенное сочетание для перехода по нему. Проще всего показать это в действии:
То ли смеяться, то ли плакать, но существует целый ряд расширений вроде Stack Copy Button, которые добавляют на Stack Overflow в каждый сниппет кода кнопку «скопировать в буфер обмена». Если что, я вам об этом не рассказывал!
Любопытный факт: популярный сервис Postman, помогающий в работе над API, когда-то начинался именно как расширение для Chrome. С тех пор он разросся в большой отдельный продукт, зато в расширениях появились новые игроки: Talend API Tester позволяет отправлять запросы с помощью удобного UI.
Есть расширения со следующей идеей: из всех страниц в мире чаще всего мы видим страницу «new tab», и можно превратить её в агрегатор полезной информации для айтишников, чтобы при открытии новых вкладок заодно держать руку на пульсе. Самый известный такой проект — daily.dev, показывающий подборку англоязычных материалов о разработке.
Есть ещё похожий проект Devo, позволяющий видеть новости сразу из нескольких разных источников (вроде Hacker News и Product Hunt). А ещё два проекта, GitHunt и HackerTab, предлагают видеть на новой вкладке репозитории, попавшие в trending на Гитхабе.
GitHub
Вот о Гитхабе дальше и поговорим. Есть целая россыпь расширений, призванных улучшить работу с ним. И прямо на самом GitHub даже есть их подборка. Можете посмотреть её целиком, а здесь упомяну те варианты, у которых особенно много звёздочек.
Octotree (21k звёзд). Называет себя «GitHub на стероидах», то есть смысл в том, чтобы дать сервису дополнительные возможности. Самая заметная из них — слева появляется дерево файлов и каталогов:
Но вообще тут целый ряд фич, поэтому есть даже несколько версий: базовая бесплатная, а дополнительные штуки можно получить в платных Octotree Pro и Octotree Team. Ещё вы могли слышать про OctoLinker, но не путайте эти расширения: второе про то, чтобы в коде на GitHub после слов вроде import и include всё становилось активными ссылками, по которым можно перейти.
Refined-Github (16k звёзд). Тоже «допиливание гитхаба», но если дерево Octotree сразу бросается в глаза, то тут работа с нюансами, на уровне «сколько пробелов в табе». Вот пример такого нюанса — в issues показывает не только количество лайков, но и аватарки поставивших:
GitHub-Dark (9k звёзд). Это тоже есть в подборке расширений на GitHub, хотя технически это не само расширение, а стиль для расширения Stylus. Ну, если знаете про Greasemonkey, то идею понимаете: есть механизм применения пользовательских стилей к разным сайтам, а есть сами эти стили. И тут тёмный стиль набрал тысячи звёзд. Чем он всем так понравился, если у GitHub и так есть тёмная тема? Например, по сравнению с ней он помягче, с менее жёстким контрастом. Слева без расширения, справа с ним:
Ещё есть куча мелких расширений, предназначенных для выполнения какой-то конкретной маленькой цели. Зачастую эта цель понятна уже из названия: про GitHub Repository Size и Github npm stats сразу ясно, какую статистику они позволяют видеть при просмотре репозитория.
Понятно, какая часть IT-работы лучше всего сочетается с браузерными расширениями: та, где результат самой работы видно в браузере.
В то время как Web Developer предназначен «для всех сразу», ряд других расширений рассчитан на разработчиков, использующих конкретный фреймворк: они дополняют Chrome DevTools тем, что характерно именно для этого фреймворка. Самый популярный такой пример — React Developer Tools (больше трёх миллионов установок!). И такое найдется и по Vue.js, и по Angular, и по Ember.
Есть разнообразный аудит сайтов: этот сегмент заметно обмельчал, когда гугловский Lighthouse переехал в DevTools, но остались проекты вроде проверялки битых ссылок Check My Links.
Расширения вроде PerfectPixel и Pixel Parallel предназначены для того, чтобы при работе над вёрсткой накладывать на неё макет и сравнивать попиксельно.
Ну и мелочи для конкретных задач, которые не переворачивают мир, но кому-то экономят усилия и нервы. Например, Window Resizer: конечно, можно и вручную размеры окна браузера менять, но если это необходимо делать часто, проще с расширением. Или Lorem Ipsum Generator: если постоянно приходится использовать тексты-заглушки, их тоже можно создавать парой кликов в браузере. Мне нравится вариация Corporate Ipsum, которая генерирует настолько «энтерпрайзные» тексты, что даже не сразу замечаешь их бессмысленность:
«А какой тут использован. »
Тут снова про веб, но под определённым углом: есть целый ряд расширений, позволяющих понять «а что использовали на этом сайте» (зачастую это можно узнать и без расширения, но менее удобно). Понятно, такие пригодятся прежде всего тем, кто хочет понять, что использовать в своём веб-проекте (не только разработчикам, но и дизайнерам).
«А какой тут фреймворк»: Wappalyzer и Library Sniffer призваны показывать, какие технологии используются сайтом (от языков до систем аналитики). Вроде бы первый сообщает заметно больше.
«А какой тут шрифт»: WhatFont и Fonts Ninja позволяют узнавать это, просто наводя курсором на текст.
«А какой тут цвет»: понятно, что идея color picker из графических редакторов отлично работает и в браузере, и таких есть целый ряд. Но если какие-то из них совсем простенькие, то другие вроде ColorZilla идут дальше: тут есть и история «какие цвета уже определял», и автокопирование hex-кода в буфер обмена, и выковыривание цветов из CSS страницы.
«А какой тут CSS»: всякие CSS Viewer, CSS Peeper и Code Cola предлагают с комфортом смотреть (а то и менять) CSS открытой страницы.
«А какая тут мета»: META Seo Inspector — это не про переименовавшуюся компанию Facebook, Inc., а про метаданные страницы. Как видно из названия, ориентировано на сеошников, но думаю, может пригодиться не только им.
И даже «А какой тут редирект», как у RedirectPath. Поможет разобраться, когда вроде кликал на что-то сексуальное, а попал к сборкам OpenJDK от Алексея Шипилёва!
Что дальше
Надеюсь, кто-то узнал что-то подходящее ему из поста, а завершу его минуткой рекламы.
Если расширения вашей мечты в списке не оказалось — смело пишите о нём в комментариях.
А вот если расширение вашей мечты вообще ещё не создано — как раз для вас есть объявление. Мы на следующей неделе мы проведём конференцию HolyJS, и там будет двухчасовой воркшоп о том, как их делать с нуля. Так что сможете создать его сами.
И ещё для тех, кто заинтересовался расширениями, но переживает про безопасность («GitHub-расширение для работы с приватными репозиториями хочет доступ, что-то мне дискомфортно»). Вообще говоря, переживание правильное: расширения могут быть и вредоносными. И на той же HolyJS будет доклад как раз об их безопасности: что плохого они могут сделать и как от них защититься?
Разгугленный Chromium
Даже если у вас нет аккаунта в Google, свободный браузер Chromium всё равно в фоновом режиме обменивается данными с серверами Google. Это довольно странно, ведь люди устанавливают Chromium вместо Chrome именно для того, чтобы получить чистую программу без коммерческой привязки. Тем не менее, при сборке Chromium в нормальном режиме всё равно скачиваются и устаналиваются бинарные блобы от Google.
Проект ungoogled-chromium — это набор конфигурационных флагов, патчей и специальных скриптов, чтобы удалить интеграцию с Google, улучшить настройки безопасности и управления.
Анонимный пользователь Github позаимствовал настройки из нескольких существующих проектов, которые тоже старались максимально очистить Chromium от лишней функциональности с целью сделать чистую минималистическую конфигурацию: это Chromium из дистрибутива Debian, набор патчей Inox, а также браузер Iridium, сделанный с упором на защиту приватности.
Разработчики трёх упомянутых проектов приложили немалые усилия, чтобы избавиться от присутствия Google в свободном браузере. Но «разгугленный Chromium» ещё более параноидален в этом стремлении.
Например, автор заменил в исходном коде Chromium многие упомянутые веб-домены на несуществующие альтернативы — чтобы точно гарантировать, что браузер не сможет никуда послать никакую информацию без ведома пользователя.
Пример очистки страницы в DOM Distiller
В «разгугленном» браузере полностью отключена функциональность, специфическая для доменов Google, например, Google Host Detector, Google URL Tracker, Google Cloud Messaging, Google Hotwording и др.
Автор добавил ещё несколько настроек чисто на свой вкус. Наверное, такое не всем понравится.
В общем, «разгуглить» Chromium можно разными способами. Кроме Iridium и Inbox теперь появился ещё один вариант.
Судя по всему, у многих людей есть желание получить простой минималистичный браузер, без всяких «наворотов» и интеллектуальных функций, быстрый и надёжный. Создать такой браузер с нуля практически невозможно, а вот очистить Chromium от шлака — вполне здравая идея.
Проблема только в том, что браузеры очень быстро развиваются. Новые версии выходят по несколько раз в год. В том же Chromium сейчас стабильная версия имеет номер 53.0.2785.116, а ведь Chrome 1 и Сhromium 1 вышли совсем недавно — 2 сентября 2008 года.
Это не просто любовь разработчиков к цифрам. В каждой новой версии на самом деле внедряют новые веб-стандарты, новые фичи HTML5 и поддержку новых технологий. Процесс идёт стремительно. Из-за такой «текучки» очень сложно уследить за новым кодом.
Автор «разгугленного» Chromium честно предупреждает, что из-за бурного развития проекта Chromium новые фичи, нарушающие приватность, могут постоянно проникать в код, как и новые баги.
Почему-то автор стремится выпускать версии параллельно с основной веткой Chromium. А ведь какой интересной идеей было бы создать ультра-минималистичный браузер, для которого вообще не нужны обновления. Отключить Canvas, WebGL, WebRTC и прочие современные штуки, отключить хистори, куки, доступ браузера к оборудованию и прочее. Сделать эдакий вариант Tor для безопасного просмотра страниц, с минимальной функциональностью, оставить только блокировщик рекламы и очиститель страниц вроде вышеупомянутого DOM Distiller. По крайней мере, для мобильных устройств такой минималистический браузер пришёлся бы весьма кстати.
Последние версии очищенного «Хромиума» для Windows, MacOS, Debian и Ubuntu публикуются на этой странице. Сборка билда под Windows запускается только в Windows 7 x64 или более новой версии. Для сборки потребуется Visual Studio 2013 Update 4 или Visual Studio 2015 Update 1, другие версии не поддерживаются.
В браузер можно устанавливать расширения из Chrome Webstore, но не через веб-интерфейс. Их нужно скачать и установить вручную. Чтобы скачать расширение из Chrome Webstore, можно воспользоваться прямой ссылкой:
Здесь только [EXTENSION_ID] заменяем на идентификатор расширения из каталога. Например, cjpalhdlnbpafiamejdnhcphjbkeiagm — идентификатор расширения uBlock Origin.
После этого файл crx устанавливается как расширение в браузер одним из нескольких способов, на выбор, хотя бы просто перетаскиванием мышью на вкладку с расширениями.
Как работает Headless Chrome
Уже из названия понятно, что headless-браузер — это нечто без головы. В контексте фронтенда — это незаменимый инструмент разработчика, с помощью которого можно тестировать код, проверять качество и соответствие верстке. Виталий Слободин на Frontend Conf решил, что необходимо познакомиться с устройством этого инструмента поближе.
Под катом компоненты и особенности работы Headless Chrome, интересные сценарии использования Headless Chrome. Вторая часть про Puppeteer — удобную Node.js-библиотеку для управления Headless-режимом в Google Chrome и Chromium.
О спикере: Виталий Слободин — бывший разработчик PhantomJS — тот, кто закрыл его и похоронил. Иногда помогает Константину Токареву ( annulen) в «воскрешенной» версии QtWebKit — том самом QtWebKit, где есть поддержка ES6, Flexbox и многие других современных стандартов.
Виталий любит исследовать браузеры, в свободное время копаться в WebKit, Chrome и прочее, прочее. Про браузеры сегодня и поговорим, а именно про безголовые браузеры и всю их семейку призраков.
Что такое безголовый браузер?
Уже из названия понятно, что это нечто без головы. В контексте браузера это значит следующее.
Нас интересует только верхний компонент Browser UI. Это тот самый интерфейс пользователя — окошки, меню, всплывающие уведомления и все остальное.
Так выглядит безголовый браузер. Заметили разницу? Мы полностью убираем интерфейс пользователя. Его больше нет. Остается только браузер.
Сегодня мы будем говорить именно про Headless Chrome (). В чем между ними разница? На самом деле, Chrome — это брендированная версия Chromium, у которой есть проприетарные кодеки, тот же самый H.264, интеграции с сервисами Google и все остальное. Chromium — это просто открытая реализация.
Дата рождения Headless Chrome: 2016 год. Если вы сталкивались с ним, то можете задать мне каверзный вопрос: «Как так, я помню новость 2017 года?» Дело в том, что команда инженеров из Google связывалась с разработчиками PhantomJS еще в 2016 году, когда они только-только начинали реализовывать Headless-режим в Chrome. Мы писали целые гуглдоки, как мы будем реализовывать интерфейс и прочее. Тогда Google хотели сделать интерфейс, полностью совместимый с PhantomJS. Это уже потом команда инженеров пришла к решению не делать таковую совместимость.
Об интерфейсе для управления (API), в качестве которого выступает Chrome DevTools protocol, поговорим позже и посмотрим, что с его помощью можно делать.
Эта статья будет строится по принципу пирамиды Puppeteer (с англ. кукловод). Хорошее название выбрано — кукловод — тот, кто управляет всеми остальными!
В основании пирамиды лежит Headless Chrome — безголовый Chrome — что это такое?
Headless Chrome
В центре — Headless browser — тот самый Chromium или Chrome (обычно Chromium). У него есть так называемые отрисовщики (RENDERER) — процессы, которые отрисовывают содержимое страницы (ваше окно). Причем, каждой вкладке нужен свой отрисовщик, поэтому, если открыть много вкладок, то Chrome запустит столько же процессов для отрисовки.
Поверх всего этого — ваше приложение. Если мы берем Chromium или Headless Chrome, то поверх него будет Chrome, либо какое-то приложение, в которое вы можете встроить его. Ближайшим аналогом можно назвать Steam. Все знают, что по сути Steam — это просто браузер к сайту Steam. Он, конечно, не headless, но похож на эту схему.
Есть 2 способа встраивать безголовый Chrome в ваше приложение (или его использовать):
Но помимо всего этого у вас еще появляются дополнительные вещи, в том числе:
Компоненты Chromium
Опять слышу каверзный вопрос: «Зачем мне эта страшная схема? Я пишу под (вставьте название любимого фреймворка)».
Я считаю, что разработчик должен знать, как устроен его инструмент. Если вы пишите под React, вы должны знать, как работает React. Если вы пишите под Angular, вы должны знать, что у Angular под капотом.
Потому что в случае чего, допустим, фатальной ошибки или очень серьезного бага на продакшене, вам придется разбираться с «кишками», и вы просто можете потеряться там — где, что и как. Если вы, например, будете писать тесты или использовать Headless Chrome, вы тоже можете столкнуться с некоторыми его странностями поведения и багами. Поэтому я вам вкратце расскажу, какие у Chromium есть компоненты. Когда вы увидите большой stack trace, вы уже будете знать, в какую сторону копать и как вообще это можно поправить.
Самый низкий уровень Platform layer. Его компоненты:
Chrome DevTools protocol
Мы все сталкивались с Chrome DevTools protocol, поскольку пользуемся панелью разработчиков в Chrome или удаленным отладчиком — теми же самыми средствами разработки. Если вы запускаете средства разработчика в удаленном режиме, общение с браузером происходит при помощи именно DevTools protocol. Когда вы ставите debugger, смотрите code coverage, используете геолокацию или еще что-нибудь — все это управляется при помощи DevTools.
На самом деле сам DevTools protocol имеет огромное количество методов. Ваше средство разработчика не имеет доступа, наверное, к 80% из них. Реально там можно делать все!
Давайте разберем, что из себя представляет этот протокол. На самом деле он очень простой. В нем есть 2 компонента:
Они общаются при помощи простого JSON:
Puppeteer
Установить Puppeteer можно при помощи любимого пакетного менеджера — будь то yarn, npm или любой другой.
Использовать его тоже легко — просто запрашиваете его в своем Node.js-скрипте, и уже, по сути, можете использовать.
По ссылке https://try-puppeteer.appspot.com вы можете прямо на сайте написать скрипт, выполнить его и получить результат прямо в браузере. Все это будет реализовано при помощи Headless Chrome.
Рассмотрим простейший скрипт под Node.js:
Здесь мы просто открываем страничку и печатаем ее в PDF. Посмотрим работу этого скрипта в режиме реального времени:
Все будет классно, но непонятно — что там внутри. Конечно, у нас же headless-браузер, мы же ничего не видим. Поэтому у Puppeteer есть специальный флаг, который называется headless: false:
Он нужен для запуска headless-браузера в режиме headful, когда вы сможете увидеть какое-то окно и посмотреть, что же происходит с вашей страницей в режиме реального времени, то есть как ваш скрипт взаимодействует с вашей страницей.
Так будет выглядеть тот же самый скрипт, когда мы добавим этот флаг. Слева появляется окно браузера — уже нагляднее.
Плюсы Puppeteer:
+ Это Node.js-библиотека для безголового Chrome.
+ Поддержка legacy-версий Node.js >= 6.
+ Легкая установка.
+ Высокоуровневый API для управления всей этой гигантской машиной.
Безголовый Chrome устанавливается легко и без вмешательства в систему. При первой установке Puppeteer скачивает версию Chromium и устанавливает ее прямо в папку node_modules именно под вашу архитектуру и ОС. Вам не нужно ничего скачивать дополнительно, он это делает автоматически. Вы также можете использовать и вашу любимую версию Chrome, которая установлена у вас в системе. Это тоже можно сделать — Puppeteer предоставляет вам такой API.
К сожалению, есть и минусы, если брать именно базовую инсталляцию.
Минусы Puppeteer:
− Нет top-level функций: синхронизации закладок и паролей; поддержки профилей; аппаратного ускорения и т.д.
− Программный рендеринг — наиболее весомый минус. Все вычисления и отрисовки происходят на вашем CPU. Но и тут инженеры Google нас скоро удивят — работы по реализации аппаратного ускорения уже ведутся. Уже сейчас можно попытаться его использовать, если вы смелы и отважны.
− До недавнего времени не было поддержки расширений — теперь ЕСТЬ! Если вы хитрый разработчик, можете взять ваш любимый AdBlock, указать, как Puppeteer’у его использовать, и вся реклама будет заблокирована.
− Нет поддержки аудио/видео. Потому что, ну зачем headless-браузеру аудио и видео.
Что может Puppeteer:
Изоляция сессий
Что это такое, с чем ее едят, и не подавимся ли мы? — Не подавимся!
Изоляция сессий — это отдельные «хранилища» для каждой вкладки. Когда вы запускаете Puppeteer, вы можете создать новую страницу, и у каждой новой страницы у вас может быть отдельное хранилище, в том числе:
Изоляция сессий позволяет сэкономить ресурсы и время при запуске параллельных сессий. Допустим, вы тестируете сайт, который собирается в development-режиме, то есть bundle не минимизированы, и весят 20 МБ. Если вы хотите просто его закэшировать, то можете указать Puppeteer использовать кэш общий для всех страниц, которые создаются, и этот bundle будет закэширован.
Можно сериализовать сессии для последующего использования. Вы пишите тест, который проверяет некое действие у вас на сайте. Но у вас есть проблема — сайт требует авторизацию. Вы же не будете в каждом тесте постоянно добавлять before для авторизации на сайте. Puppeteer позволяет залогиниться на сайте один раз, и потом переиспользовать эту сессию в дальнейшем.
Виртуальные таймеры
Возможно, вы уже используете виртуальные таймеры. Если вы двигали ползунок в средстве разработчика, который ускоряет или замедляет анимацию (и мыли после этого руки конечно же!), то в этот момент вы использовали виртуальные таймеры в браузере.
Браузер может использовать виртуальные таймеры вместо реальных, чтобы «прокрутить» время вперед для ускорения загрузки страницы или завершения анимации. Допустим, у вас тот же самый тест, вы заходите на главную страницу, а там анимация на 30 секунд. Никому не выгодно, чтобы тест ждал все это время. Поэтому вы можете просто ускорить анимацию, чтобы она была завершена мгновенно при загрузке страницы, и ваш тест продолжил работу.
Можно остановить время, пока выполняется сетевой запрос. Например, вы тестируете реакцию вашего приложения на то, когда запрос, ушедший на бэкенд, очень долго выполняется, либо возвращается с ошибкой. Вы можете остановить время — Puppeteer это позволяет.
На слайде ниже есть еще один вариант: остановить и продолжить работу отрисовщика (renderer). В экспериментальном режиме была возможность сказать браузеру не заниматься отрисовкой, а позже, если понадобится, запросить скриншот. Тогда бы безголовый Chrome все бы быстро отрисовал, выдал скриншот, и снова перестал бы отрисовывать что-либо. К сожалению, разработчики уже успели поменять принцип работы этого API и такой функции больше нет.
Схематичный вид виртуальных таймеров ниже.
В верхней строке два обычных таймера: первый стартует в первую единицу времени и выполняется за одну единицу времени, второй стартует в третью единицу времени и выполняется за три единицы времени.
Ускорение таймеров — они запускаются друг за другом. Когда мы их приостанавливаем, у нас появляется промежуток времени, после которого все таймеры стартанут.
Рассмотрим это на примере. Ниже обрезанный кусок кода, который по сути просто загружает страницу с анимацией с codepen.io и ждет:
Это демонстрация выполнения в ходе доклада — просто анимация.
Теперь при помощи Chrome DevTools protocol отправим метод, который называется Animation.setPlaybackRate, передадим в качестве параметров ему playbackRate с значением 12:
Загружаем ту же самую ссылку, и анимашка стала работать гораздо быстрее. Это происходит за счет того, что мы использовали виртуальный таймер и ускорили проигрывание анимации в 12 раз.
Давайте теперь проведем эксперимент — передадим playbackRate: 0 — и посмотрим, что же будет. А будет вот что: анимации вообще нет, она не проигрывается. Нулевое и отрицательные значения просто приостанавливают полностью всю анимацию.
Работа с сетевыми запросами
Вы можете перехватывать сетевые запросы путем установки следующего флага:
В таком режиме появляется дополнительное событие, которое срабатывает, когда отправляется или приходит какой-то сетевой запрос.
Вы можете менять запрос на лету. Это значит, что вы можете полностью менять все его содержимое (body) и его заголовки, инспектировать, даже отменять запрос.
Это нужно для того, чтобы обрабатывать авторизацию или аутентификацию, в том числе базовую аутентификацию по HTTP.
Еще вы можете сделать покрытие кода (JS/CSS). При помощи Puppeteer можно все это автоматизировать. Все мы знаем утилиты, которые могут загрузить страничку, показать, какие классы в ней используются и т.д. Но довольны ли мы ими? Думаю, нет.
Браузер знает лучше, какие селекторы и классы используются — он же браузер! Он всегда знает, какой JavaScript выполнился, какой нет, какой CSS используется, какой нет.
Опять на помощь приходит Chrome DevTools protocol:
В первых двух строчках запускаем сравнительно новую фичу, которая позволяет узнать покрытие кода. Запускаем JS и CSS, переходим на какую-то страничку, потом говорим — стоп — и можем посмотреть результаты. Причем это не какие-то мнимые результаты, а те, которые видит браузер именно за счет движка.
Помимо всего прочего, уже есть плагин, который для Puppeteer это все экспортирует в istanbul.
На вершине пирамиды Puppeteer находится скрипт, который вы написали на Node.js — он как крестный отец всем нижним пунктам.
Но… «не всё спокойно в датском королевстве. » — как писал Уильям Шекспир.
Что не так с безголовыми браузерами?
У безголовых браузеров есть проблемы несмотря на то, что все их крутые фичи могут так много.
Отличие в рендеринге страницы на разных платформах
Я очень люблю этот пункт и постоянно про это рассказываю. Давайте посмотрим на эту картинку.
Здесь обычная страничка с обычным текстом: справа — отрисовка в Chrome на Linux, слева — под Windows. Те, кто тестирует скриншотами, знают, что всегда устанавливается значение, называемое «порогом погрешности», которое определяет, когда скриншот считается идентичным, а когда нет.
На самом деле проблема в том, что как бы вы не старались установить этот порог, погрешность всегда будет выходить за эту грань, и вы все равно будете получать ложно позитивные результаты. Это связано с тем, что все страницы, и даже веб-шрифты рендерятся по-разному на всех трех платформах — на Windows по одному алгоритму, на MacOS по-другому, в Linux вообще зоопарк. Вы не можете просто взять и тестировать скриншотами.
Вы скажете: «Мне просто нужна эталонная машина, где я буду запускать все эти тесты и сравнивать скриншоты». Но на самом деле это дико неудобно, потому что вам придется ждать CI, а вы хотите здесь и сейчас локально на машине у себя проверить, не сломали ли вы что-нибудь. Если у вас эталонные скриншоты делаются на Linux-машине, а у вас Mac, то будут ложные результаты.
Поэтому я и говорю, что не тестируйте скриншотами вообще — забудьте это.
Кстати, если вы все-таки хотите тестировать скриншотами, есть замечательная статья Романа Дворнова «Unit-тестирование скриншотами: преодолеваем звуковой барьер». Это прямо детективное чтиво.
Блокировки
Многие крупные контент-провайдеры не любят, когда вы делаете scraping или получаете их контент нелегальным способом. Представим, что я крупный контент-провайдер, и хочу сыграть с вами в одну игру. Есть два GET-запроса в двух разных браузерах. 
Сможете ли вы угадать, где здесь Chrome? Вариант «оба» не принимается — Chrome тут только один. Скорее всего, вы не сможете ответить на этот вопрос, а я, как крупный контент-провайдер, могу: справа — PhantomJS, а слева — Chrome. 
Я могу дойти до такой степени, что буду обнаруживать ваши браузеры (что это именно — Chrome или FireFox) путем сопоставления порядка HTTP заголовков в ваших запросах. Если хост идет первым — я четко знаю — это Chrome. Дальше могу не сравнивать. Да, конечно, есть более сложные алгоритмы — мы проверяем не только порядок, но еще и значения, и т.д. и т.п. Но важен факт, что я могу слепками сравнивать ваши заголовки, проверять, кто вы есть, а потом просто блокировать вас или не блокировать.
Невозможно реализовать некоторые функции (Flash)
Вы когда-нибудь изучали углубленно, прямо хардкорно, Flash в браузерах? Как-то я заглянул — потом полгода не спал.
Все мы помним, как мы раньше смотрели YouTube, когда еще был Flash: ролик крутится, все хорошо. Но в тот момент, когда создается встраиваемый объект на странице типа Flash, он всегда запрашивает реальное окно у вашей ОС. То есть помимо окна вашего браузера, внутри YouTube-окошка Flash было еще одно окно вашей ОС. Flash не может работать, если вы не дадите ему реальное окно — причем не просто реальное окно, а окно, которое видно у вас на экране. Поэтому некоторые функции в безголовых браузерах реализовать невозможно, в том числе, Flash.
Полная автоматизация и боты
Как я уже сказал ранее, крупные контент-провайдеры очень боятся, когда вы пишите пауков или граббинги, которые просто крадут информацию, которая предоставляется платно.
В ход идут разные ухищрения. Есть статьи о том, как все-таки обнаруживать headless-браузеры. Могу сказать, что вы никак не сможете обнаружить headless-браузеры. Все методы, которые там описаны, обходятся. Например, там были способы обнаружения при помощи Canvas. Помню, даже был один скрипт, который смотрел, как движется мышка по экрану, и заполнял Canvas. Мы же люди и двигаем мышку довольно медленно, а Headless Chrome гораздо шустрее. Скрипт понимал, что слишком быстро заполняется Canvas — значит, это, скорее всего, безголовый Chrome. Мы это тоже обошли, просто замедлив браузер — не проблема.
Нет стандартного (единого) API
Если вы смотрели headless-реализации в других браузерах — будь это Safari или FireFox — там это все реализовано при помощи webdriver API. В Chrome есть Chrome DevTools protocol. В Edge вообще ничего не понятно — что там есть, чего нет.
WebGL?
Люди тоже просят WebGL в headless-режиме. По этой ссылке вы можете попасть на багтрекер Google Chrome. Там разработчики активно голосуют за реализацию headless-режима для WebGL, и уже он может что-то рисовать. Их сейчас просто сдерживает аппаратный рендеринг. Как только закончат реализацию аппаратного рендеринга, то и WebGL автоматически будет доступен, то есть что-то можно будет делать в фоне.
Но не все так плохо!
У нас появляется второй игрок на рынке — 11 мая 2018 была новость, что Microsoft в своем браузере Edge решил реализовать почти тот же самый протокол, который используется в Google Chrome. Они специально создали консорциум, где обсуждают протокол, который хотят довести до промышленного стандарта, чтобы вы могли взять свой скрипт и запустить его и под Edge, и под Chrome, и под FireFox.
Но есть одно «но» — у Microsoft Edge нет headless-режима, к сожалению. У них есть голосовалка, где люди пишут: «Дайте нам headless-режим!» — но они молчат. Наверное, что-то пилят втайне.
TODO (заключение)
Я рассказал это все для того, чтобы вы могли прийти к вашему менеджеру, или, если вы менеджер, к разработчику, и сказать: «Все! Мы не хотим больше Selenium — давайте нам Puppeteer! Будем в нем тестировать». Если это случится, я буду рад.
Но если вы сможете изучать, как и я, браузеры, используя Puppeteer, активно постить баги, или отправлять pull request, то я буду рад еще больше. Этот инструмент в OpenSource лежит на GitHub, написан на Node.js — вы можете просто в него брать и контрибьютить.
Случай с Puppeteer уникален тем, что в Google работает две команды: одна занимается именно Puppeteer, вторая — именно headless-режимом. Если пользователь находит баг, пишет о нем наа GitHub, то, если этот баг не в Puppeteer, а в Headless Chrome, баг переходит в команду Headless Chrome. Если они его там фиксят, то Puppeteer очень быстро обновляется. За счет этого получается единая экосистема, когда сообщество помогает улучшать браузер.
Поэтому я призываю вас помогать улучшать инструмент, который используете не только вы, но и другие разработчики и тестировщики.
Frontend Conf Moscow — специализированная конференция фронтенд-разработчиков состоится 4 и 5 октября в Москве, в Инфопространстве. Список принятых докладов уже опубликован на сайте конференции.
В нашей рассылке мы регулярно делаем тематические обзоры выступлений, рассказываем о вышедших расшифровках и будущих мероприятиях — подписывайтесь, чтобы получать новости первым.
А это ссылка на наш Youtube-канал по фронтенду, там собраны все выступления, относящиеся к разработке клиентской части проектов.
