Как работает JavaScript: жизненный цикл Service Worker и сценарии использования

• Оригинальный адрес:How JavaScript works: Service Workers, their lifecycle and use cases
• Оригинальный автор:Alexander Zlatkov
• Перевод с:Программа перевода самородков
• Постоянная ссылка на эту статью:GitHub.com/rare earth/gold-no…
• Переводчик:talisk
• Корректор:allen,Чжао Лиян

Это восьмая статья из серии, посвященной изучению JavaScript и его строительных блоков. В процессе определения и описания основных элементов мы также поделились некоторымиSessionStackлучшие практики времени. SessionStack — это мощное и производительное приложение JavaScript, которое показывает вам в режиме реального времени, что делают пользователи, когда у них возникают технические проблемы или проблемы с пользовательским интерфейсом в вашем веб-приложении.

Если вы не читали предыдущую главу, вы можете прочитать ее здесь:

1. Как работает JavaScript: обзор движка, среды выполнения, стека вызовов
2. Как работает JavaScript: 5 советов по оптимизации кода в движке V8
3. Как работает JavaScript: управление памятью + обработка 4 распространенных утечек памяти
4. Как работает JavaScript: рост событийного цикла и асинхронное программирование + 5 советов по лучшему программированию с помощью async/await
5. Как работает JavaScript: глубокое погружение в WebSockets и HTTP/2 с SSE и как выбрать правильный
6. Как работает JavaScript: конкуренция с WebAssembly + Почему WebAssembly лучше, чем JavaScript в некоторых ситуациях
7. Как работает JavaScript: внутреннее устройство веб-работника и 5 сценариев, которые вы должны использовать

ты наверное уже знаешьПрогрессивные веб-приложенияОни будут становиться все более популярными, потому что они предназначены для того, чтобы пользователи могли работать с веб-приложениями более плавно, обеспечивая работу с собственными приложениями, а не внешний вид браузера.

Одно из основных требований к созданию прогрессивного веб-приложения — сделать его очень надежным с точки зрения работы в сети и загрузки — его можно использовать в условиях неопределенности или недоступности сети.

В этом посте мы подробно рассмотрим сервис-воркеров: как они работают и о чем должны заботиться разработчики. Наконец, мы также перечисляем некоторые уникальные преимущества сервис-воркеров, которыми должны воспользоваться разработчики, иSessionStackПоделитесь опытом нашей собственной команды.

Обзор

Если вы хотите узнать все о сервис-воркерах, вам следует начать с чтения нашего блога оWeb WorkersСтатья начинается.

По сути, Service Worker — это тип Web Worker, точнее, он похож наShared Worker:

• Service Worker работает в своем собственном глобальном контексте
• он не привязан к конкретной веб-странице
• у него нет доступа к DOM

Одна из основных причин, по которой Service Worker API является захватывающим, заключается в том, что он позволяет вашему веб-приложению поддерживать работу в автономном режиме, предоставляя разработчикам полный контроль над процессом.

Жизненный цикл сервис-воркеров

Жизненный цикл Service Worker полностью отделен от вашей веб-страницы и состоит из следующих этапов:

• скачать
• Установить
• активация

скачать

Это загрузка браузера, содержащая Service Worker.jsвремя файла.

Установить

Чтобы установить Service Worker для своего веб-приложения, вы должны сначала зарегистрировать его, что можно сделать в коде JavaScript. При регистрации сервис-воркера он предлагает браузеру запустить этапы установки сервис-воркера в фоновом режиме.

Зарегистрировав сервис-воркер, вы можете сообщить браузеру, где находится файл JavaScript вашего сервис-воркера. Давайте посмотрим на следующий код:

if ('serviceWorker' in navigator) {
  window.addEventListener('load', function() {
    navigator.serviceWorker.register('/sw.js').then(function(registration) {
      // Registration was successful
      console.log('ServiceWorker registration successful');
    }, function(err) {
      // Registration failed
      console.log('ServiceWorker registration failed: ', err);
    });
  });
}

Этот код проверяет, поддерживается ли API Service Worker в текущей среде. Если да, то/sw.jsСервисный работник зарегистрирован.

Может вызываться каждый раз при загрузке страницыregister()метод, браузер определит, был ли зарегистрирован Service Worker, и обработает его правильно.

register()Важной деталью метода является расположение файла сервис-воркера. В этом случае вы можете видеть, что файл Service Worker находится в корне домена. Это означает, что областью действия Service Worker будет весь веб-сайт. Другими словами, этот Service Worker получит все содержимое этого домена.fetchСобытия (о которых мы поговорим позже). если мы были/example/sw.jsЗарегистрируйте файл Service Worker, тогда Service Worker увидит только/example/начало страницыfetchсобытия (например,/example/page1/,/example/page2/).

На этапе установки лучше загрузить и кэшировать некоторые статические ресурсы. После успешного кэширования ресурсов установка Service Worker завершена. Если нет успеха (сбой загрузки) - Service Worker попытается снова. После установки статические ресурсы уже в кеше.

Если регистрация должна произойти после события загрузки, это ответит на ваш вопрос «должна ли регистрация происходить после события загрузки». Это не обязательно, но определенно рекомендуется.

Почему это так? Давайте рассмотрим случай, когда пользователь впервые обращается к веб-приложению. В настоящее время Service Worker не существует, и браузер не может заранее узнать, будет ли Service Worker в конечном итоге установлен. Если Service Worker установлен, браузер должен использовать дополнительные ресурсы ЦП и памяти для этого дополнительного потока, иначе браузер будет использовать вычислительные ресурсы для отображения веб-страницы.

Кроме того, если вы устанавливаете Service Worker на страницу, вы рискуете ленивой загрузкой и рендерингом, вместо того, чтобы как можно скорее сделать страницу доступной для ваших пользователей.

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

активация

После установки сервис-воркера следующим шагом будет его активация. Этот шаг — хорошая возможность управлять ранее кэшированным содержимым.

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

• Он будет обрабатывать события выборки и сообщения, которые происходят, когда страница делает сетевой запрос или сообщение.
• он будет прекращен для сохранения памяти

Вот схематическая диаграмма жизненного цикла:

Обработка устройств внутри Service Worker

После того, как страница обработает процесс регистрации, давайте посмотрим, что происходит в сценарии Service Worker, который обрабатывается путем добавления прослушивателей событий в экземпляр Service Worker.installмероприятие.

это обработкаinstallДействия, которые необходимо предпринять в случае инцидента:

• включить кеш
• кешировать наши файлы
• Убедитесь, что все необходимые ресурсы кэшированы

Простой фикстур внутри Service Worker может выглядеть так:

var CACHE_NAME = 'my-web-app-cache';
var urlsToCache = [
  '/',
  '/styles/main.css',
  '/scripts/app.js',
  '/scripts/lib.js'
];

self.addEventListener('install', function(event) {
  // event.waitUntil takes a promise to know how
  // long the installation takes, and whether it 
  // succeeded or not.
  event.waitUntil(
    caches.open(CACHE_NAME)
      .then(function(cache) {
        console.log('Opened cache');
        return cache.addAll(urlsToCache);
      })
  );
});

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

иметь дело сinstallСобытие совершенно необязательно, вы можете его избежать, и в этом случае вам не нужно выполнять какие-либо шаги здесь.

Запросы кэширования во время выполнения

Эта часть является подлинным содержанием. Вы увидите, как перехватить запрос и вернуть расположение созданного кеша (и нового созданного кеша).

После того, как сервис-воркер установлен, пользователь переходит на новую страницу или обновляет текущую страницу, сервис-воркер получает событие fetch. Вот пример, который показывает, как вернуть кешированный ресурс или кешировать результат после отправки нового запроса:

self.addEventListener('fetch', function(event) {
  event.respondWith(
    // This method looks at the request and
    // finds any cached results from any of the
    // caches that the Service Worker has created.
    caches.match(event.request)
      .then(function(response) {
        // If a cache is hit, we can return thre response.
        if (response) {
          return response;
        }

        // Clone the request. A request is a stream and
        // can only be consumed once. Since we are consuming this
        // once by cache and once by the browser for fetch, we need
        // to clone the request.
        var fetchRequest = event.request.clone();
        
        // A cache hasn't been hit so we need to perform a fetch,
        // which makes a network request and returns the data if
        // anything can be retrieved from the network.
        return fetch(fetchRequest).then(
          function(response) {
            // Check if we received a valid response
            if(!response || response.status !== 200 || response.type !== 'basic') {
              return response;
            }

            // Cloning the response since it's a stream as well.
            // Because we want the browser to consume the response
            // as well as the cache consuming the response, we need
            // to clone it so we have two streams.
            var responseToCache = response.clone();

            caches.open(CACHE_NAME)
              .then(function(cache) {
                // Add the request to the cache for future queries.
                cache.put(event.request, responseToCache);
              });

            return response;
          }
        );
      })
    );
});

Вкратце, что здесь происходит:

• event.respondWith()будет определять, как мы ответимfetchмероприятие. мы переходим отcaches.match()Обещание, которое проверяет запрос и ищет уже созданный кэшированный результат.
• Если в кеше, содержимое ответа восстанавливается.
• В противном случае он будет выполнятьсяfetch.
• Проверьте, является ли код состояния200, проверяя при этом, что тип ответаbasic, что указывает на то, что ответ пришел на наш первоначальный запрос. При этом запросы к сторонним ресурсам не кэшируются.
• ответ кэшируется

Запросы и ответы должны быть реплицированы, поскольку онипоток. Тело потока можно использовать только один раз. И поскольку мы хотим их потреблять, а браузер должен их потреблять, нам нужно их клонировать.

Загрузить сервис-воркер

Когда пользователь посещает ваше веб-приложение, браузер попытается повторно загрузить сервис-воркер..jsдокумент. Это будет выполняться в фоновом режиме.

Если в только что загруженном файле Service Worker есть разница хотя бы в один байт по сравнению с текущим файлом Service Worker, браузер рассмотрит изменение и должен запустить новый Service Worker.

Будет запущен новый сервис-воркер, а событие установки будет удалено. Однако на данный момент старый Service Worker все еще контролирует страницы вашего веб-приложения, а это означает, что новый Service Worker войдет вwaitingусловие.

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

Зачем они нужны? Чтобы избежать одновременного запуска двух версий веб-приложения на разных вкладках — на самом деле это очень распространено в Интернете и может привести к очень серьезным ошибкам (например, при локальном сохранении данных в браузере будет другая схема).

удалить данные из кеша

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

Вот пример того, как удалить из кеша некоторые файлы, которых нет в белом списке (в данном случае естьpage-1,page-2две сущности):

self.addEventListener('activate', function(event) {

  var cacheWhitelist = ['page-1', 'page-2'];

  event.waitUntil(
    // Retrieving all the keys from the cache.
    caches.keys().then(function(cacheNames) {
      return Promise.all(
        // Looping through all the cached files.
        cacheNames.map(function(cacheName) {
          // If the file in the cache is not in the whitelist
          // it should be deleted.
          if (cacheWhitelist.indexOf(cacheName) === -1) {
            return caches.delete(cacheName);
          }
        })
      );
    })
  );
});

Требования HTTPS

При создании веб-приложений разработчики могут использовать Service Worker на локальном хосте, но после его развертывания в производственной среде вам необходимо быть готовым к HTTPS (это последняя причина использования HTTPS).

С помощью Service Worker можно угонять и подделывать. Если вы не используете HTTPS, ваше веб-приложение становится простыматака «человек посередине».

Для большей безопасности вам необходимо зарегистрировать Service Worker на странице, обслуживаемой по HTTPS, чтобы браузер получал Service Worker без изменений при передаче по сети.

Поддержка браузера

Браузерная поддержка сервис-воркеров улучшается:

Вы можете отслеживать ход адаптации всех браузеров на этом сайте -Джейк Арчибальд.GitHub.IO/is service i….

Сервисные работники открывают дверь к красивым функциям

Некоторые уникальные функции, предоставляемые Service Workers:

• Отправить уведомление——  Позволяет пользователям получать своевременные уведомления из веб-приложения.
• Фоновая синхронизация——  Когда сеть пользователя нестабильна, разработчик может отложить операцию до тех пор, пока у пользователя не будет стабильного соединения. Это гарантирует, что любые данные, которые пользователь хочет отправить, могут быть отправлены.
• временная синхронизация(Будущая поддержка) —   Предоставляет API для управления периодической фоновой синхронизацией.
• Геозона(Поддержка в будущем) —   Разработчики могут настраивать параметры для создания областей интереса.Геозона. Веб-приложения получают уведомление, когда устройство пересекает геозону, что позволяет разработчикам предоставлять эффективные услуги в зависимости от географического положения пользователя.

Они будут подробно обсуждаться в следующих статьях этой серии.

Мы работали над тем, чтобы сделать работу пользователей с SessionStack максимально удобной, оптимизировав загрузку страниц и время отклика.

когда выSessionStackПри воспроизведении пользовательских сеансов (или просмотре в реальном времени) внешний интерфейс SessionStack будет постоянно извлекать данные с наших серверов для беспрепятственного создания буферов, как вы только что убедились в этой статье. Для обеспечения некоторого контекста: как только вы интегрируете библиотеку SessionStack в веб-приложение, она будет постоянно собирать данные, такие как изменения DOM, взаимодействия с пользователем, сетевые запросы, необработанные исключения и сообщения отладки.

Пока сеанс воспроизводится или транслируется в прямом эфире, SessionStack предоставляет все данные, позволяя разработчикам визуально и технически видеть все, что пользователь видит в своем браузере. Все это нужно реализовать быстро, потому что мы не хотим заставлять пользователя ждать.

Поскольку данные принимаются нашим интерфейсом, это хорошее место для использования Service Worker для перезагрузки нашего плеера, повторной передачи данных и т. д. Также очень важно иметь дело с более медленными сетевыми соединениями.

Если вы хотите попробовать SessionStack,Вот бесплатный план.

использованная литература

• Developers.Google.com/Web/Женщины большие…
• GitHub.com/my3from/service…

---

Программа перевода самородковэто сообщество, которое переводит высококачественные технические статьи из Интернета сНаггетсДелитесь статьями на английском языке на . Охват контентаAndroid,iOS,внешний интерфейс,задняя часть,блокчейн,товар,дизайн,искусственный интеллектЕсли вы хотите видеть более качественные переводы, пожалуйста, продолжайте обращать вниманиеПрограмма перевода самородков,официальный Вейбо,Знай колонку.