Worker-ы и shared worker-ы
Во всех популярных языках есть потоки (threads). В браузерном javascript для параллельной обработки используются worker-ы.
Под катом рассказ о том, как ими пользоваться, какие ограничения есть в воркерах и об особенностях взаимодействия с ними в разных браузерах.
Что такое worker
Создание worker-а
Worker создаётся из отдельного скрипта:
Shared worker идентифицируется по URL. Чтобы создать второй воркер из одного файла, можно добавить какой-нибудь параметр в URL (worker.js?num=2).
Worker можно создать и без отдельного файла. Например, так создать его из текста функции:
Создать worker из worker-а можно только в Firefox. В Chrome можно создать shared worker из странички и передать его порт другому worker-у (об этом ниже).
Ограничения worker-ов
В worker-е нельзя использовать DOM, вместо window глобальный объект называется self. Нельзя получить доступ к localStorage и рисовать на canvas. Такие же ограничения обычно есть во всех десктопных API: доступ к окнам только из UI-треда.
Доступ к объектам
Из worker-ов нельзя вернуть объект. В javascript нет lock-ов и других возможностей потокобезопасности, поэтому из worker-ов нельзя передавать объекты по ссылке, всё отправленное в worker или из него будет скопировано.
Пока что worker-ы не поддерживают CORS, создать worker можно только загрузив его со своего домена.
Размер стека
Для worker-ов выделяется меньший размер стека, иногда это имеет значение:
| Chrome/osx | Firefox/osx | Safari/osx | Chrome/win | Firefox/win | IE11/win | |
|---|---|---|---|---|---|---|
| web | 20 800 | 48 000 | 63 000 | 41 900 | 51 000 | 63 000 |
| worker | 5 300 | 43 300 | 6 100 | 21 300 | 37 000 | 30 100 |
console
До недавнего времени не было, но обычно сейчас уже есть. В некоторых браузерах консоли в worker-ах нет, поэтому перед обращением лучше проверить её доступность.
Взаимодействие с worker-ом
После создания worker-а ему можно отправить сообщение:
Подписаться на сообщение в worker-е так:
Аналогично и обратно, из worker-а можно вызвать или self.postMessage, или port.postMessage для shared worker-ов.
Transferables
Передавать по ссылке кое-что таки можно. Для этого существует второй параметр в postMessage, transferList:
В transferList можно передать список объектов, которые будут перемещены. Поддерживаются только ArrayBuffer и MessagePort. В вызывающем контексте объект будет очищен (neutered): у ArrayBuffer будет нулевая длина, и попытка его повторной отправки приведёт к ошибке:
Взаимодействие двух worker-ов
В Firefox можно создать worker из worker-а (стандарт определяет subworker-ы).
Сейчас в хроме нельзя создать worker из worker-а, а иногда worker-ам надо взаимодействовать между собой. Самый простой способ — сделать передачу сообщений от одного к другому через код страницы. Но это неудобно, потому что: 1. надо писать дополнительный код, 2. в 2 раза увеличивает количество взаимодействий и копирования данных, 3. требует выполнения кода в UI-контексте.
Worker можно научить общаться с shared worker-ом, передав ему порт shared worker-а, при этом передаваемый порт в UI-контексте мы теряем; если он нужен, надо будет переподключиться к shared worker-у, создав его заново. Передача порта выглядит так:
Правда для синхронизации всё равно движком V8 используется UI-контекст, в чём можно убедиться, завесив страничку на какое-то время: worker-ы продолжают работать, а postMessage между ними не ходят, ожидая особождения UI-контекста.
Производительность postMessage
Убийство worker-а
К сожалению, сейчас нет штатного способа отследить закрытие worker-а или страницы, его использующей.
Учёт ресурсов в shared worker-ах в Chrome
SharedWorker живёт процессе в страницы, создавшей его. На неё учитывается и показывается в task manager CPU и память, которые потребляет worker. Если страничку закроют, её процесс с worker-ом отдаст память, используемую страницей (не сразу, через некоторое время после закрытия) и останется жить, пока другие страницы используют этот worker. Интересно, что при этом такой процесс полностью исчезнет из статистики хрома: ни память, ни CPU пользоваель не сможет отследить в его внутреннем task manager-е. Это неприятно, т.к. пользователь скорее всего не догадается, почему браузер стал потреблять так много ресурсов.
Отладка worker-ов
В chrome shared worker-ы доступны на страничке chrome://inspect/#workers: 
Именно туда пишется вывод console из worker.
Dedicated worker в хроме и IE отлаживается в страничке, на которой он выполняется:
В других браузерах с отладкой worker-ов пока что плохо.
Can I Use.
Поддержка разных worker-ов на Can I Use. Коротко, применительно к сегодняшнему вебу: worker есть на современных браузерах, sharedworker — на продвинутых десктопных браузерах, serviceworker — пока что рано.
Всё написанное актуально на лето 2015 года, не забывайте, что веб быстро меняется.
Русские Блоги
У наших сотрудников в браузере есть многопоточные и автономные приложения power-play
«У рабочих есть власть»?
Рабочие потоки предлагаются в спецификации HTML5 ( Web Worker Концепция) позволяет разработчикам писать фоновые программы, которые могут быть отделены от основного потока и работать в течение длительного времени, не прерываясь пользователем, выполнять транзакции или логику и в то же время гарантировать, что страница своевременно отвечает пользователю.
Web Worker Разделен на Dedicated Worker с участием SharedWorker 。
Впоследствии ServiceWorker Также присоединяйтесь, чтобы лучше контролировать кэширование и обработку запросов, делая возможными автономные приложения.
I. Процессы и потоки
Давайте сначала рассмотрим основы:
На традиционных страницах (до HTML5)JavaScript работает в однопоточном режимеХотя есть много способов имитировать многопоточность (например, метод setinterval в JavaScript, метод setTimeout и т. Д.), По сути, работа программы по-прежнему выполняется механизмом JavaScript в однопоточном режиме планирования.
С тех пор, как W3C разработал первый черновик HTML5 в 2008 году, HTML5 содержит все больше и больше новых возможностей и функций. Это не только повышает производительность веб-системы или веб-страницы, но также добавляет поддержку функций веб-приложений, таких как локальные базы данных.
II. Режим «мастер-работник»
Пример: шаблон Master-Worker в Node.js
Встроенный модуль кластера Node может реализовать функцию кластера, управляя несколькими подпроцессами через основной процесс.
Бегать node server.js После вывода:
III. Web Worker
В HTML5 Web Worker Возможно появление многопоточного программирования на веб-страницах.
В спецификации HTML5 перечислены Web Worker Три основных характеристики:
(3.1) Преданный работник
Выделенный поток относится к стандартному рабочему, выделенный рабочий может использоваться только скриптом, который его генерирует.
Другими словами, у так называемого выделенного работника нет дисплея. DedicatedWorker Конструктор на самом деле относится к обычному Worker Конструктор.
🌰 Прежде чем объяснять концепцию, давайте посмотрим на простой каштан:
Пример очень простой, но передаваемая ключевая информация довольно обширна, поэтому взгляните на приведенный выше код в сочетании с некоторыми определениями в спецификации:
Во-первых, выделенный рабочий будет неявно использовать его во время работы. MessagePort Объект, его интерфейс определяется следующим образом:
Тогда взгляните на упрощенный Worker Определение:
Параметры в workerOptions могут поддерживать модуляризацию es6 и т. Д., Не обсуждаемые здесь
Пока вы можете понять различные определения и поведение при вызове на «главной странице» и «myWorker.js» self На что это похоже, продолжайте смотреть соответствующие определения:
Выделенный воркер реализует два вышеуказанных интерфейса, мы видим:
В дополнение к вышесказанному, некоторые другие ключевые моменты включают:
Выделенный работник относительно идеальная совместимость
В современных браузерах и мобильных терминалах можно сказать, что выделенные воркеры уже хорошо поддерживаются:
(3.2) Разделяемый работник
Общий поток относится к работнику, который может использоваться несколькими страницами через несколько подключений.
🌰 Давайте сначала посмотрим на каштан:
Эффект операции понять нетрудно: две страницы в одном домене, которые ссылаются на общий воркер, совместно используют массив arr. Другими словами, как только на выделенного рабочего ссылается страница, у страницы появляется независимый контекст дочернего потока; разница в том, что если на общий рабочий файл сценария ссылаются несколько страниц (требуется один и тот же источник), Тогда эти страницы будут иметь общий контекст работника, общие переменные влияния и т. Д.
Еще одно очень большое отличие состоит в том, что, как упоминалось ранее, он общается с выделенным исполнителем. MessagePort Реализация выполняется неявно (непосредственно на рабочем postMessage/onmessage ); а общий воркер должен передать порт ( MessagePort Тип worker.port ) При условии продолжения.
Еще несколько замечаний:
Мобильный терминал его пока не поддерживает, да и IE11 / Edge тоже бесполезен;Во время теста chrome / firefox на стороне Mac часто не удавалось. Наконец, это было возможно только в chrome @ win10 и opera @ mac.
IV. Service Worker
Service Worker основан на управляемом событиями Web Worker’е и предоставляет полную систему для управления установкой, версией и обновлением.
Преданные работники или общие работники сосредоточены на решении«Длительное выполнение JS влияет на отклик пользовательского интерфейса» Проблема: один запускает JS в фоновом режиме, не влияет на основной поток; другой использует postMessage()/onmessage Механизм сообщений достигает параллелизма.
Сервисный работник должен решить«Из-за зависимости и легкой потери сетевого подключения пользовательский интерфейс веб-приложения не так хорош, как нативное приложение» Он предоставляет ряд технологических коллекций для решения проблемы; он более независим, чем веб-воркер, и может работать, когда страница не открыта.
И по сравнению с устаревшей технологией кэширования Application Cache:
Сервис-воркер имеет более тонкий и полный контроль; в качестве промежуточного уровня между страницей и сервером сервис-воркер может захватывать запрос страницы, за которую он отвечает, и возвращать соответствующие ресурсы, что делает возможными автономные веб-приложения.
🌰 Как всегда, давайте посмотрим на интуитивно понятный каштанчик:
Объедините этот простой пример, чтобы отсортировать отраженную в нем информацию:
(4.1) Основные компоненты
Promise
В отличие от двух других типов работников, различные технологии в сервис-воркерах широко используют Promise.
Объект ответа
Конструктор Response позволяет создать настраиваемый объект ответа:
При использовании объекта Response в сервис-воркере обычно передают response.clone() Чтобы получить клон для использования; причина этого в том, что ответ является потоком, и его нужно использовать только один раз, и если мы хотим, чтобы браузер, кеш и т. Д. Манипулировали ответом несколько раз, нам нужно клонировать разные объекты; для запроса Использование объектов запроса аналогично
Fetch
Каждый сетевой запрос запускает соответствующего сервис-воркера fetch событие
Catch
Возможности собственного кэширования включены в спецификацию сервис-воркера, чтобы заменить устаревший стандарт Application Cache.
Cache API обеспечивает уровень постоянства для сетевых запросов и может использовать операцию сопоставления для запроса этих запросов.
Используя ресурсы в локальном кэше, можно исключить не только дорогостоящий доступ к сети, но и возможность поддерживать доступность приложений в автономных, автономных или плохих сетевых условиях.
Соответствующие определения следующие:
В то же время можно использовать сервис-воркер self.caches Чтобы получить кеш:
В примере отражено (часть версии будет упомянута позже):
(4.2) Жизненный цикл
Полный жизненный цикл
Жизненный цикл server worker устроен следующим образом, и его цель:
Соответствующее мероприятие
В зависимости от обратного вызова каждого события тип, соответствующий параметру события, выглядит следующим образом:
| Название события | интерфейс |
|---|---|
| install | ExtendableEvent |
| activate | ExtendableEvent |
| fetch | FetchEvent |
| message | ExtendableMessageEvent |
| messageerror | MessageEvent |
Два репрезентативных события определены следующим образом:
Поэтому в примере его можно назвать event.waitUntil() с участием event.respondWith() ：
зарегистрированный
В отличие от двух других типов воркеров, сервис-воркеры больше не используют new для создания экземпляров, а напрямую через navigator.serviceWorker Получить
navigator.serviceWorker Фактически достигнуто ServiceWorkerContainer интерфейс:
Например, что мы сделали на главной странице в примере:
Бегать register() Если метод успешен, он будет navigator.serviceWorker В тогда обратном вызове обещания ServiceWorkerRegistration Тип объекта
Как показано в примере, созданный объект ‘Registration’ можно использовать на главной странице для вызова onmessage Вверх
В то же время, если register() Успех, сервис воркер там ServiceWorkerGlobalScope Бег в окружающей среде;
Другими словами, myService.js Упоминается в self Это тип, можно позвонить self.skipWaiting() Другие методы;
Это особый тип операционной среды рабочего контекста, который не зависит от основного запущенного потока и не имеет возможности доступа к DOM.
Как и в случае с разделяемым воркером, вам нужно быть осторожным с глобальными переменными в скрипте сервисного воркера: у каждой страницы не будет своего уникального воркера.
установка
После регистрации сервис-воркера будет запущено событие установки.
В обратном вызове установки обычно выполняются следующие задачи:
Обновить
Распространенной задачей, которая появляется в обратном вызове активации, является управление кешем. Управление кешем выполняется на этом этапе, а не на предыдущем этапе установки. Причина в том, что если какой-либо старый кеш будет очищен на этапе установки, любой старый сервисный работник, который продолжает контролировать все текущие страницы, внезапно не сможет обслуживать файлы из кеша.
(4.3) Другое
HTTPS требуется
По соображениям безопасности сервис-воркер может использоваться только в среде HTTPS; в противном случае будет выдана ошибка.
DOMException: Only secure origins are allowed (see: https://goo.gl/Y0ZkNV).
При тестировании можно использовать http://localhost продолжающийся
Фоновая синхронизация
От себя
хром офлайн маленькая игра динозавров
В зависимости от сервис-воркера Chrome будет отображать автономную игру Little Dinosaur Adventure, когда сеть недоступна. Нажмите пробел, чтобы начать
(4.4) Совместимость с браузером Service Worker
Из-за недоступности некоторых связанных сервисов Google и ограниченной их поддержки в iOS и на экспериментальной стадии условия для крупномасштабных приложений пока недоступны;
Тем не менее, как наиболее важную часть прогрессивной технологии сетевых приложений PWA, многие отечественные производители уже пытаются продвигать соответствующую поддержку, и ее стоит ожидать в будущем:
V. Резюме
VI. Справочные материалы:
Нажмите и удерживайте QR-код или выполните поиск по запросу fewelife, чтобы подписаться на нас
Что такое сервис-воркеры и как они помогают повысить производительность
Сервис-воркеры позволяют разработчикам эффективнее управлять кэшированием ресурсов, чтобы пользователи могли продолжать использовать приложение даже при разрыве интернет-соединения. В этой статье разберем, как сервис-воркер может вывести производительность на новый уровень.
Что такое сервис-воркеры
Service worker — это особый тип JavaScript воркера, который представляет собой сценарий, выполняемый в фоновом режиме браузера пользователя. Он похож на прокси-сервер, размещенный между вашим приложением, браузером и сетью. Помимо прочего, сервис-воркеры позволяют приложениям продолжать работу в автономном режиме в случае потери подключения к интернету.
Эти сценарии предоставляют разработчикам больший контроль над обработкой запросов приложений и позволяют избежать негативного пользовательского опыта, если запрос зависнет.
Как сервис-воркеры улучшают производительность
У всех такое было: вы просматриваете веб-сайт, нажимаете на ссылку и встречаетесь с какой-либо вариацией сообщения «Не удается подключиться к интернету». Вы нажимаете кнопку назад и видите то же самое. Пока соединение не будет восстановлено, вы можете только играть в dino runner, если используете Chrome. Сервис-воркеры позволяют избежать этого нежелательного сценария.
Одно из самых больших преимуществ сервис-воркеров — способность поддерживать работу в оффлайн-режиме. В прошлом для обеспечения ограниченной автономной поддержки можно было использовать API AppCache, но теперь есть сервис-воркеры, и они гораздо лучше.
Загрузка данных из локального кэша всегда занимает меньше времени, чем запрос к серверу. Если вы кэшируете все ресурсы вашего приложения, то можете значительно улучшить время загрузки для посетителей, возвратившихся на сайт. Возрастает вероятность того, что они будут возвращаться снова и снова.
Как работают сервис-воркеры?
Сценарии сервис-воркеров независимы от вашего сайта или приложения. У них свой собственный жизненный цикл:
После того, как воркер будет зарегистрирован из JavaScript, браузер установит его. Если он правильно сконфигурирован, то начнет кэшировать статические ресурсы страницы немедленно, в ином случае вам придется повторить установку.
Если установка прошла успешно, сценарий активируется и получает контроль над всеми страницами в своей области видимости. Чтобы воркер заработал, установившая его страница должна перезагрузиться. После этого он может переключаться между двумя состояниями: обработка событий fetch и message или прекращение работы для экономии памяти.
Необходимые условия
Сервис-воркеры — замечательная технология по многим причинам, но они теоретически могут предоставить хакерам возможности для проникновения в ваше веб-приложение. Для защиты от атак типа «человек посередине» сценарии могут быть зарегистрированы только на страницах, обслуживаемых по протоколу HTTPS. Во время разработки можно использовать воркеры через localhost, но для работающего приложения необходимо настроить защищенный протокол.
Стоит также отметить, что большинство основных веб-браузеров (кроме IE) уже поддерживают сервис-воркеры.
Как зарегистрировать сервис-воркер
Сервис-воркеры основаны на JavaScript обещаниях (promises), поэтому прежде чем начать работу, будет полезно в них разобраться.
Как установить сервис-воркер
Прежде чем ваш воркер сможет что-то сделать, вы должны установить обработчик события install и указать, какие файлы следует кэшировать. Откройте файл sw.js и добавьте следующий код:
Как получать события
После успешной установки, воркер активируется. Следующий шаг — возврат кэшированных ответов. Для этого можно использовать следующий кусок кода:
Здесь определяется событие fetch и создается обещание caches.match. При запросе метод пытается найти любой закэшированный воркером ресурс. Если не получится, то будет сделан обычный запрос к серверу.
Поддержание актуальности
В этой статье разобрано только начало работы работы с сервис-воркерами. Для длительной автономной работы сервис-воркеров необходимо периодически обновлять. Узнать больше об этом можно здесь.
Советы по кэшированию
Способ реализации Service workers зависит от архитектуры веб-приложения. Вот несколько советов, которые помогут вам:
Потоковые ответы
Если большинство ваших страниц содержат статическую шапку и подвал, лучше всего обрабатывать навигационные запросы с помощью потокового ответа, состоящего из отдельно кэшированных подресурсов. Потоки позволяют приложению отвечать на запросы навигации кэшированными фрагментами HTML.
В некоторых ситуациях, например, когда HTML-код зависит от данных из CMS, связь с сетью неизбежна. Тем не менее, внедрение сервис-воркеров и потоковых ответов улучшает пользовательский опыт, так как часть страницы будет отображена сразу, пока остальной код еще не загрузился.
Кэширование статического HTML-кода
Если веб-приложение состоит из статических HTML-документов, можно вовсе обойтись без связи с сетью.
Вам просто нужно создать service worker, который возвращает кэшированный HTML. Конечно, необходима некоторая неблокирующая логика для поддержания HTML в актуальном состоянии при внесении изменений. Для этого используется политика stale-while-revalidate:
Как вариант, вы можете использовать Workbox для создания воркера, способного кэшировать ваши статические ресурсы, обслуживать их и поддерживать в актуальном состоянии.
Одностраничные приложения
Интеграция сервис-воркера в архитектуру App Shell позволяет одностраничным приложениям с одной страницей не обращаться к сети при обработке навигационных запросов. После установки и активации обработчиков добавьте этот код для кэширования и обновления app-shell.html:
Теперь все навигационные запросы должны возвращать кэшированную копию HTML-документа, содержащего основные элементы приложения. Приведенный выше код также включает логику маршрутизации на стороне клиента для отображения содержимого на основе URL-адреса.
Измерение увеличения производительности
Конечно, точная количественная оценка производительности должна основываться на реальных данных. Инженер Google опубликовал тематическое исследование о том, как создатели веб-приложения Google I/O измеряли влияние сервис-воркеров на производительность с помощью Google Analytics.
Разработчики начали с перечисления вопросов, на которые должны были ответить собранные данные. Во-первых, они хотели знать, является ли кэширование с помощью воркеров более эффективным, чем дефолтное HTTP-кэширование. При повторном посещении пользователи ожидают, что страницы будут загружаться быстрее, поэтому важно знать, действительно ли воркеры ускоряют работу приложения.
Затем нужно было решить, какие показатели лучше всего характеризуют скорость. «Время загрузки страницы» не отражает момент, после которого со страницей можно взаимодействовать. Гораздо полезнее такие метрики как первая значимая отрисовка и первое взаимодействие, они отражают восприятие пользователей. После определения правильных вопросов и нужных показателей можно оценить необходимость и возможность оптимизации.
Резюме
Сервис-воркеры не только повышают производительность сети. Например, они могут использоваться для реализации push-уведомлений, что особенно полезно в мобильных приложения. В будущем сервис-воркеры смогут делать еще много полезных вещей, например, осуществлять геозонирование. Другими словами, пора начинать экспериментировать с воркерами, потому что в ближайшее время они точно не исчезнут.
Как работает JS: веб-воркеры и пять сценариев их использования
Публикуем перевод седьмой части часть серии материалов об особенностях работы различных механизмов JavaScript. Наша сегодняшняя тема — веб-воркеры. В частности, речь пойдёт о различных типах веб-воркеров, о том, как организована совместная работа тех частей, из которых они состоят, а также об их возможностях и об ограничениях, с которыми можно столкнуться в разных сценариях их использования. Здесь же будет показано 5 вариантов практического применения веб-воркеров.
Ограничения асинхронного программирования
Прежде чем мы начнём говорить о веб-воркерах, стоит вспомнить о том, что JavaScript — это однопоточный язык, однако, он поддерживает и возможности асинхронного выполнения кода.
Асинхронному программированию и вариантам его применения в JS-проектах был посвящён один из предыдущих материалов этой серии.
Асинхронное выполнение кода позволяет пользовательскому интерфейсу веб-приложений нормально функционировать, реагировать на команды пользователя. Система «планирует» нагрузку на цикл событий таким образом, чтобы в первую очередь выполнялись операции, связанные с пользовательским интерфейсом.
Хороший пример использования асинхронных методов программирования демонстрирует техника выполнения AJAX-запросов. Так как ожидание ответа способно занять много времени, запросы можно делать асинхронно, при этом, пока клиент ожидает ответа, может выполняться код, не относящийся к запросу.
Такой подход, однако, демонстрирует следующую проблему: запросы обрабатываются WEB API браузера. Нас же интересует возможность асинхронного выполнения произвольного кода. Скажем, как быть, если код внутри функции обратного вызова интенсивно использует ресурсы процессора?
Если функция performCPUIntensiveCalculation — это не нечто вроде асинхронно выполняемого HTTP-запроса, а код, блокирующий главный поток (скажем, огромный и тяжёлый цикл for ), то при однопоточном подходе к JS-разработке у нас нет способа освободить цикл событий и разблокировать интерфейс браузера. Как результат, пользователь не сможет с ним нормально работать.
Это означает, что асинхронные функции смягчают лишь небольшую часть ограничений, связанных с однопоточностью JS.
Взглянем на простую функцию, которая вычисляет среднее значение для числового массива.
Этот код можно переписать так, чтобы он «эмулировал» асинхронное выполнение:
Веб-воркеры
HTML5 дал нам множество замечательных возможностей, среди которых можно отметить следующие:
Это поистине замечательная возможность. Система понятий JavaScript основана на идее однопоточного окружения, а теперь перед нами технология, которая (частично) снимает это ограничение.
Веб-воркеры позволяют разработчику размещать задачи, для выполнения которых требуются длительные и сложные вычисления, интенсивно задействующие процессор, в фоновых потоках, без блокировки пользовательского интерфейса, что позволяет приложениям оперативно реагировать на воздействия пользователя. Более того, нам больше не нужны обходные пути, вроде рассмотренного выше трюка с setTimeout для того, чтобы найти приемлемый способ взаимодействия с циклом событий.
Вот простой пример, который демонстрирует разницу между сортировкой массива с помощью веб-воркера и без него.
▍Обзор веб-воркеров
Веб-воркеры позволяют выполнять тяжёлые в вычислительном плане и длительные задачи без блокировки потока пользовательского интерфейса. На самом деле, при их использовании вычисления выполняются параллельно. Перед нами настоящая многопоточность.
Возможно, вы вспомните о том, что JavaScript — это однопоточный язык программирования. Пожалуй, тут вы должны осознать, что JS — это язык, который не определяет модель потоков. Веб-воркеры не являются частью JavaScript. Они представляют собой возможность браузера, к которой можно получить доступ посредством JavaScript. Большинство браузеров исторически были однопоточными (эта ситуация, конечно, изменилась), и большинство реализаций JavaScript создано для браузеров.
Веб-воркеры не реализованы в Node.js — там есть концепция «кластеров» или «дочерних процессов», а это уже немного другое.
Стоит отметить, что спецификация упоминает три типа веб-воркеров:
▍Выделенные воркеры
Экземпляры выделенных веб-воркеров создаются главным процессом. Обмениваться данными с ними может только он.
Поддержка выделенных воркеров в браузерах
▍Разделяемые воркеры
Поддержка разделяемых воркеров в браузерах
▍Сервис-воркеры
Сервис-воркеры — это воркеры, управляемые событиями, зарегистрированные с использованием источника их происхождения и пути. Они могут контролировать веб-страницу, с которой связаны, перехватывая и модифицируя команды навигации и запросы ресурсов, и выполняя кэширование данных, которым можно очень точно управлять. Всё это даёт нам отличные средства управления поведением приложения в определённой ситуации (например, когда сеть недоступна).
Поддержка сервис-воркеров в браузерах
Надо отметить, что в этом материале мы будем заниматься выделенными воркерами, именно их мы будем иметь в виду, говоря о «веб-воркерах» или о «воркерах».
Как работают веб-воркеры
Воркеры используют механизмы передачи сообщений, характерные для технологий, которые применяются для организации взаимодействия потоков, что позволяет организовать их параллельное выполнение. Они отлично подходят для того, чтобы выполнять тяжёлые вычислительные операции, не замедляя работу пользовательского интерфейса.
Веб-воркеры выполняются в изолированных потоках в браузере. Как результат, код, который они выполняют, должен быть включён в отдельный файл. Это важно запомнить.
Вот как создают веб-воркеры:
Если файл task.js существует и к нему есть доступ, браузер создаст новый поток, который асинхронно загрузит этот файл. После того, как загрузка будет завершена, начнётся выполнение кода воркера. Если при попытке загрузки файла браузер получит сообщение об ошибке 404, файл загружен не будет, при этом сообщения об ошибках не выводятся.
Для запуска только что созданного воркера нужно вызвать его метод postMessage :
Обмен данными с веб-воркером
▍Метод postMessage
Посмотрим на пример того, как страница, создавшая воркер, может обмениваться с ним данными, используя JSON-объект. При передаче строки выглядит всё практически точно так же.
Вот часть HTML-страницы:
Вот содержимое файла с кодом воркера:
Когда воркер получает сообщение и понимает, чего от него хотят, он будет выполнять вычисления самостоятельно, не блокируя цикл событий. То, чем занимается воркер, выглядит как стандартная JS-функция. Когда вычисления завершены, их результаты передаются главной странице.
▍Широковещательный канал передачи данных
Объект BroadcastChannel представляет собой более универсальное API для передачи данных. Он позволяет передавать сообщения, которые можно принять во всех контекстах, имеющих один и тот же источник. Все вкладки браузера, iframe или воркеры, относящиеся к одному источнику, могут передавать и принимать широковещательные сообщения:
Вот как выглядит схема взаимодействия различных сущностей с использованием широковещательного канала обмена сообщениями:
Обмен данными с использованием широковещательного канала передачи сообщений
Однако тут стоит отметить, что объект BroadcastChannel пока имеет довольно ограниченную поддержку в браузерах.
Поддержка BroadcastChannel в браузерах
Способы отправки сообщений веб-воркерам
Есть два способа отправки сообщений веб-воркерам. Первый заключается в копировании данных, второй — в передаче данных от источника к приёмнику без их копирования. Рассмотрим эти способы работы с сообщениями:
Возможности, доступные веб-воркерам
Веб-воркерам, из-за их многопоточной сущности, доступен лишь ограниченный набор возможностей JavaScript. Вот эти возможности:
Ограничения веб-воркеров
К сожалению, у веб-воркеров нет доступа к некоторым весьма важным возможностям JavaScript. Среди них следующие:
Обработка ошибок
Сценарии использования веб-воркеров
Мы рассказали о сильных и слабых сторонах веб-воркеров. Теперь рассмотрим несколько сценариев их использования.
Итоги
В этом материале мы рассказали о веб-воркерах — сравнительно новой возможности, доступной веб-разработчикам в большинстве современных браузеров. Веб-воркеры позволяют выносить в отдельные потоки выполнение ресурсоёмких операций, что позволяет не нагружать главный поток, который может спокойно обрабатывать всё, что связано с пользовательским интерфейсом.
Предыдущие части цикла статей:
Уважаемые читатели! Используете ли вы веб-воркеры в своих проектах?
