Каковы варианты использования для веб-работников? [закрыто]


174

Я ищу реальный сценарий использования API Web Workers .


Поддерживаются ли они мобильными / webkit платформами?
dmp

Не знаю точно, но думаю, что они есть.
Сергей Ильинский

6
@danp Поддержка браузера: caniuse.com/webworkers
Dheeraj Vepakomma

1
Я записал случай, когда мы сначала использовали веб-работника, а затем решили, что без него нам будет лучше - windward.net/blogs/web-workers-abandon/#.Vl3QdXarQ-U
Дэвид Тилен,

Ответы:


143
  • У Джона Резига (известной из jQuery) есть несколько интересных примеров использования здесь веб-работников - игры, графика, криптография.

  • Другое использование - веб-ввод-вывод - другими словами, опрос URL в фоновом режиме. Таким образом, вы не блокируете интерфейс в ожидании результатов опроса.

  • Другое практическое применение: в Bespin они используют Web Workers для подсветки синтаксиса, который не нужно блокировать редактированием кода во время использования приложения.

  • Из Mozilla : один из способов, с помощью которого работники могут использовать ваш код, - выполнять вычисления с интенсивным использованием процессора, не блокируя поток пользовательского интерфейса.

    В качестве практического примера рассмотрим приложение с большой таблицей # (это реальный мир, кстати, взятый из приложения, которое я запрограммировал ~ 2 года назад). Вы можете изменить один # в таблице через поле ввода, и множество других чисел в разных столбцах будет пересчитано в довольно интенсивном процессе.

    Старый рабочий процесс был: Изменить #. Идите, принесите кофе, в то время как JavaScript хрустит изменениями других номеров, и веб-страница не отвечает в течение 3 минут - после того, как я оптимизировал его до чертиков и обратно. Вернись с кофе. Изменить второй #. Повторите много раз. Нажмите кнопку Сохранить.

    Новый рабочий процесс с рабочими может быть: Изменить #. Получите сообщение о статусе, что что-то пересчитывается, но вы можете изменить другие #. Изменить больше #s. Закончив изменение, подождите, пока статус не изменится на «все расчеты завершены, теперь вы можете просмотреть последние # и сохранить».


5
Великолепные ссылки! Я никогда не слышал о рабочих ... ммм, рабочих. (Пора принять долгий горячий душ ...)
Питер Роуэлл

51
Я знаю, что это двухлетний ответ, но я просто хотел упомянуть, что вам не нужны веб-работники для элемента № 2 (опросы URL). XHR происходит асинхронно и не блокируется; нет необходимости запускать запросы XHR в отдельном потоке. (Конечно, в современном приложении вы бы хотели использовать WebSockets вместо опроса.)
josh3736

6
@ josh3736 - Вы правы, но мне сейчас любопытно, может ли выполнение многих параллельных запросов XHR aync каким-то образом сделать браузер несчастным? Кроме того, вам нужны локальные ресурсы для обработки ответов XHR, где рабочие могут быть полезны.
ДВК,

Если все параллельные запросы поступают на один и тот же сервер, вы достигнете предела для каждого хоста где-то между 2 и 9 одновременными соединениями. (Я бы предположил, что ограничение применяется ко всем соединениям, независимо от того, инициированы ли они из основного потока или рабочего.) Конечно, если у вас одновременно выполняется 10 одновременных запросов, вам, вероятно, нужно переосмыслить дизайн вашего приложения.
josh3736

2
Извините мой простой вопрос, но что вы называете "#" в вашем примере выше?
shrewdbeans

35

Я использовал их для отправки больших объемов данных из браузера на сервер. Очевидно, что вы можете сделать это с обычными вызовами AJAX, но если это требует одного из ценных соединений на имя хоста. Кроме того, если пользователь выполняет переход страницы во время этого процесса (например, щелкает ссылку), ваши объекты JavaScript с предыдущей страницы исчезают, и вы не можете обрабатывать обратные вызовы. Когда используется веб-работник, это действие происходит вне диапазона, поэтому у вас есть лучшая гарантия того, что оно будет выполнено.


2
Но вы должны обменяться сообщением с веб-работником. Когда стоимость этой операции заслуживает выгоды?
Danielo515

6

Другой вариант использования:

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


39
Это не должно происходить в JavaScript. Изображения уже сжаты (PNG, JPEG) с использованием алгоритмов, разработанных для эффективного сжатия данных изображения. Создание еще одного слоя сжатия на самом деле может увеличить размер данных. Для других типов данных (например, большого файла JSON) сжатие должно выполняться браузером с использованием стандартного HTTP-сжатия. Если вы делаете сжатие в JavaScript, вы, вероятно, делаете это неправильно .
josh3736

11
Я вижу, что некоторые пользователи дисквалифицируют вариант использования, но вот что я хотел сказать. рассмотрим приложение типа MS Word, например мощный редактор документов, с помощью которого вы можете вставлять изображения, музыкальные файлы, данные, таблицы Excel и т. д. в один файл. и учтите, что у вас есть веб-клиент, клиент для ПК и клиент IOS / Android. В этом случае вы можете сохранить все содержимое файла в zip-файле, а затем разархивировать его на каждом клиенте.
SBR

3
Букмарклет Instapaper сжимает сохраняемую страницу перед отправкой на сервер. Это экономит время и пропускную способность.
stevendaniels

12
@ josh3736 Единственное, что может сделать браузер - это распаковать файл с веб-сервера (или из кеша браузера). Он не может распаковать данные из локального хранилища или веб-сокета, и он не может сжать вообще. Веб-приложения отправляют все больший объем данных в восходящем направлении, и сжатие для этого чрезвычайно полезно. В равной степени действительный год назад, когда это было опубликовано: если вы не можете придумать ни одного действительного варианта использования для сжатия JavaScript, вам, вероятно, не хватает воображения.
Адрия

1
@Adria: стандарт websocket находится в процессе добавления поддержки сжатия . Если вы имеете дело с изображениями, сгенерированными в браузере ( <canvas>), вы можете получить данные изображения в сжатом формате (например, png). Моя точка зрения заключалась не в том, что в JS никогда не подходит сжатие; моя точка зрения заключалась в том, что в большинстве случаев это не так , а в большинстве случаев - особенно при работе с изображениями, о чем говорит этот ответ - есть лучшая альтернатива использованию собственного сжатия.
josh3736
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.