Сервисный работник от входа до выхода

предисловие

Нормальным открытием должно быть «Что такое Service Worker», но Service Worker часто упоминается вместе с PWA. Являетесь ли вы большим парнем с богатым опытом разработки PWA перед экраном или молодым парнем, который никогда не слышал об этом понятии, эта статья обязана прояснить отношения между Service Worker и PWA, Здесь предполагается, что все просто сервисный работник Заинтересованный фронтенд-инженер без большого соответствующего опыта.
Кроме того, в этой статье делается попытка понять ключевые моменты и прояснить идеи.Это не техническая статья.Если вы просто хотите узнать, как использовать некоторые API, или если вы столкнулись с какими-либо проблемами, которые необходимо решить, эта статья будет тратьте 5-20 минут на ваше время, пожалуйста, выключите его, как только вам это понравится~

Начните с ПВА

Полное имя PWAProgressive Web Apps, дословный перевод — «прогрессивное веб-приложение», и, увидев этот перевод, большинство людей не должны его принимать, потому что мы не можем буквально понять, что такое PWA. Вот определение PWA в Википедии:

Прогрессивное веб-приложение (на английском языке: Progressive Web Apps, именуемое PWA) — это обычная страница или инфраструктура сайта для веб-приложений, но оно может отображаться пользователю в виде традиционного приложения или родного мобильного приложения.

Это также правильное, но недостаточное определение, которое плохо описывает истинную природу PWA.

После некоторого периода доработки, вот мое понимание PWA в этой статье:
И Web, и App понимают, но что значит Progressive? Говоря о «Progressive», вы, должно быть, более или менее слышали о концепции дизайна «плавной деградации и прогрессивного улучшения» веб-приложений, потому что браузеры будут в разной степени отставать в следовании веб-стандартам (даже больше). только не следить, но и бездельничать), многие превосходные новые функции не поддерживаются старыми браузерами, поэтому разработчики иногда применяют прогрессивную стратегию, чтобы в полной мере использовать новые функции и предоставлять более совершенные браузеры, поддерживающие новые функции. опыт (Позволить некоторым людям сначала разбогатеть?). P в PWA как раз об этом значении.
Как мы все знаем, веб-приложения и нативные приложения изначально хорошо продуманы, и у обоих есть свои сценарии применения и преимущества. Однако с наступлением преувеличенной эры мобильного интернета жадные людишки хотят перенимать сильные стороны друг друга и учитывать преимущества того и другого, и с радостью изобретают кучу смешанных технологий разработки с нечистыми родословными.Не буду перечислять. они все здесь, все понимают. PWA — это еще одна попытка достичь той же цели, это отнюдь не революционная технология, это просто еще один сумасшедший тест от традиционных веб-приложений к нативным приложениям, и это просто небольшая эволюция. Но в отличие от гибридной технологии разработки, PWA является естественным продолжением чистокровной веб-технологии, поддерживаемой соответствующими веб-стандартами.

На этот раз по сравнению с традиционными веб-приложениями PWA стал сильнее в следующих аспектах:

• Внешний вид: на мобильных телефонах вы можете добавлять веб-приложения на рабочий стол и обеспечивать иммерсивный опыт, аналогичный нативным приложениям (в переводе на человеческий язык это лоб, который может скрывать браузер). Технология, лежащая в основе этой части, очевидна. Хотя она может принести новый опыт, она не находится в центре внимания этой статьи, поэтому не оставляйте ее.
• С точки зрения производительности: поскольку главный герой этой статьи, Service Worker, обладает суперспособностью перехватывать HTTP-запросы браузера сCacheStorage, PWA может улучшить взаимодействие с пользователем и производительность веб-приложений в плохих условиях сети или даже в автономном режиме.
• Другие аспекты: необязательные расширенные функции, такие как push-уведомления, фоновая синхронизация и т. д., которые также реализуются с помощью Service Workers.

Краткое резюме: PWA — это естественная эволюция веб-приложений, а Service Worker — это ключ к PWA.

На данный момент эта статья кажется не по теме, так что давайте вернемся к Service Worker.

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

// 不起眼的一行if，除了防止报错之外，也无意间解释了PWA的P：
// 如果浏览器不支持Service Worker，那就当什么都没有发生过
if ('serviceWorker' in navigator) {
    window.addEventListener('load', function () {
        // 所以Service Worker只是一个挂在navigator对象上的HTML5 API而已
        navigator.serviceWorker.register('/service-worker.js').then(function (registration) {
            console.log('我注册成功了666');
        }, function (err) {
            console.log('我注册失败了');
        });
    });
}

Вышеприведенный код после срабатывания события загрузки загружает и регистрирует файл service-worker.js, логика работы сервис-воркера написана здесь:

// service-worker.js
// 虽然可以在里边为所欲为地写任何js代码，或者也可以什么都不写，
// 都不妨碍这是一个Service Worker，但还是举一个微小的例子：
self.addEventListener('fetch', function (event) {
    if (/\.png$/.test(event.request.url)) {
        event.respondWith(fetch('/images/支付宝收款码.png'));
    }
});

Вдохновленный QR-кодом Alipay, сканирующим код на рабочем столе брата TL за ним, приведенный выше код может перехватывать все запросы изображений PNG на веб-странице и возвращать изображение кода вашей коллекции Alipay.Пока есть достаточно пользователей, кто-то всегда позвонит Вы. Деньги.
Self в коде — первое странное место, кажется, что это неопределенная переменная, но немного подумав, мы можем понять, что это ключевое слово, похожее на window или global, представляющее сам Service Worker, так что подумайте, чтобы поиграть с Service Worker, вам нужно изучить его API.
Не будем пока подробно рассматривать API, которые нужно запоминать, просто вспомним, что делает этот код: он перехватывает и обрабатывает HTTP-запросы как middleware, а Service Worker на данный момент можно понимать как клиентский прокси. Поскольку код написан человеком, возможности безграничны. Кроме того, самое страшное, что жулики могут знать боевые искусства, поэтому Service Worker требует HTTPS, обратите внимание на "S", но для удобства разработки и отладки localhost исключен.

Краткое содержание:

• Нам нужно вручную написать файл service-worker.js.
• Нам нужно скачать и зарегистрировать файл service-worker.js на веб-странице.
• Сервисные работники обладают сверхспособностями для перехвата и обработки HTTP-запросов.

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

Согласно последовательному ритму статьи, на этом углубленном этапе читательский опыт часто резко ухудшается.Чтобы избежать этой ситуации, я должен упомянуть тему жизненного цикла Service Worker.Рекомендуется прочитать в другом месте. Таких статей уже много.Да,автор этой статьи считает,что здесь можно писать,но не нужно,и у меня нет уверенности писать лучше них.Наоборот,подозревается в плагиате,поэтому я опубликуйте здесь только изображение MDN и кратко изложите его (улыбается).

Краткое содержание:

• Жизненный цикл Service Worker: во время установки, после установки, во время активации, после активации я мертв. (Это похоже на жизненный цикл компонента, не так ли?)
• При первом переходе на веб-сайт он загрузит, проанализирует и выполнит файл Service Worker, инициирует событие установки и попытается установить Service Worker.Если операции в функции обратного вызова события установки выполняются успешно, это указывает что установка Service Worker прошла успешно, и он переходит в состояние ожидания. Примечание. В настоящее время Service Worker только готов и не вступает в силу. Когда пользователь входит на веб-сайт во второй раз, Service Worker будет В это время будет инициировано событие активации, отмечающее официальный запуск Service Worker и начавший реагировать на события fetch, post, sync и т. д.

Главные события сервисных работников

• install: Как следует из названия, он запускается при установке Service Worker, и в это время файлы обычно кэшируются.
• активировать: Как следует из названия, он срабатывает при активации Service Worker.Обычно в это время выполняются некоторые операции сброса, такие как обработка кеша старой версии Service Worker.
• fetch: Как следует из названия, он запускается, когда браузер инициирует HTTP-запрос.Обычно он соответствует кешу в функции обратного вызова этого события, которое является наиболее часто используемым событием.
• push: Как следует из названия, это связано с функцией push-уведомлений.Если у вас нет соответствующих требований, вы можете игнорировать это.
• синхронизация: Как следует из названия, и функция фоновой синхронизации связана, а не связана с потребностями, то вы не можете понять.

Применение сервисного работника

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

1. Кешируйте статические ресурсы

Основным применением Service Worker является использование CacheStorage API для кэширования статических файлов, таких как js, css, шрифты и изображения. Мы можем указать конкретные файлы, которые необходимо кэшировать на этапе установки Service Worker.В функции обратного вызова события выборки проверьте запрошенный URL-адрес.Если он соответствует кэшированному ресурсу, он больше не будет получен с сервера , чтобы улучшить производительность веб-страницы. Обычно используется для создания PWAApp ShellАрхитектура реализована таким образом.
Следует отметить, что улучшение производительности связано со случаем полного отсутствия кэширования, а сам браузер имеет относительно полный механизм кэширования HTTP. Следовательно, использование кеша Service Worker не дает нашей уже относительно завершенной архитектуре немедленного улучшения производительности.Реальное значение кеша Service Worker заключается в том, что его можно использовать для более точного управления кешем и в кодировании, как кэшировать, что кешировать. Как обновить кеш, полностью зависит от того, как написан код, так что это дает большую свободу, но также сопряжено с затратами на обслуживание. Это просто другой способ кэширования, а не прорыв с нуля.

2. Оффлайн опыт

В предыдущей части мы кэшировали только статические ресурсы, такие как js, css, шрифты, изображения и т. д., но что, если бы мы также кэшировали index.html домашней страницы? В результате наши веб-страницы могут даже поддерживать автономный просмотр.
Звучит здорово, не так ли? Пожалуйста, садитесь, здесь есть огромная проблема: предположим, что наша домашняя страница index.html, в ней зарегистрирован service-worker.js, а index.html кэшируется в service-worker.js для просмотра в автономном режиме, тогда проблема в том, что сейчас , в следующий раз, когда мы выйдем в интернет, жизнь и смерть не будут действовать, потому что пользователи всегда обращаются к кэшированному index.html, не стыдно? Нам нужно обновить service-worker.js, чтобы повторно кэшировать index.html. Хотя в Интернете есть несколько решений для решения этой проблемы, она кажется очень запутанной, поэтому мы не можем не задаться вопросом, имеет ли смысл просмотр в автономном режиме. .
Следующий подход выглядит лучше: теперь, когда у нас есть возможность кэшировать файлы в автономном режиме и перехватывать HTTP-запросы, мы можем кэшировать offline.html при установленном Service Worker, подобно странице 404. В автономном режиме наш запрос на доступ к файлу index.html завершится ошибкой. В это время мы возвращаем файл offline.html для отображения пользователю. Что отображать, зависит от конкретных потребностей, и он может даже если хром отключен, сделайте небольшую игру, чтобы приставать к пользователям без интернета.

3. Другое

Service Worker предоставляет только некоторые мощные функции, но как их применять, полностью зависит от разработчика.Если мозг широко открыт, вполне возможно обеспечить освежающий опыт. Вот лишь небольшой пример:
Мы знаем, что изображения на веб-страницах потребляют много ресурсов полосы пропускания.Пользователи ждут, пока загрузится веб-сайт, и много раз они ждут изображений.Большинство изображений, размещенных на CDN, поддерживают функцию добавления суффиксных параметров для получения фотографий разные разрешения. Предположим, у нас есть способ узнать качество сетевых условий пользователя (как судить о сетевых условиях пользователя — это другой вопрос, который может быть выбран пользователем или решен техническими средствами), и пользователи классифицируются на два уровня для время : Быстрый и медленный интернет. Мы помещаем информацию об уровне скорости сети в заголовок HTTP-запроса (или другие подходящие места, которые вы хотите), когда мы инициируем запрос изображения, у нас есть возможность получить уровень сети пользователя, если это пользователь с быстрой скоростью сети. , мы Возвращаем изображение высокого разрешения на CDN через параметр suffix, и наоборот.
В результате пользователи с высокой скоростью Интернета могут видеть более четкие фотографии, а пользователи с низкой скоростью Интернета могут просматривать фотографии раньше, без необходимости долго ждать, даже если они видят фотографии с плохой четкостью.

Меры предосторожности

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

• Прежде всего, нам нужно купить лекарство от сожаления. Потому что в любом случае Service Worker проделывает какие-то опасные операции на чужих клиентах, если и есть проблема (проблема обязательно будет), то зачастую это не баг, а аварийный уровень. В таком случае нам, вероятно, понадобится другая компания, чтобы продолжить эксперименты с нашим прекрасным Service Worker. Я могу придумать, как предоставить интерфейс коммутатора в месте, похожем на центр конфигурации, или на стороне сервера, и вызвать интерфейс перед запросом страницы.Если что-то пойдет не так, выключите коммутатор и запустите код для уничтожить сервисного работника.
• Если проект был итерирован, то во время тестирования проекта среда браузера студентов QA отличается от среды реальных пользователей или, по крайней мере, неполное покрытие. Существование Service Worker фактически превращает клиента с отслеживанием состояния в клиента с более сложным состоянием. Поэтому некоторые ошибки могут быть не обнаружены на этапе тестирования, и эти ошибки крайне сложно воспроизвести, отладить, решить и протестировать визуально.

Сценарии применения

Далее поговорим о сценариях применения Service Worker, или в каких ситуациях нужно использовать Service Worker.Это легко понять, но это очень важно.Мы не можем взять молоток и смотреть на все как на гвоздь.

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

  

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

какое-то дерьмо

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

Кроме того, в процессе кодирования у меня есть несколько мыслей, которыми я могу поделиться с вами здесь:

• Service Worker и PWA существуют уже около 4 лет, но они, кажется, в состоянии аплодисментов, и нет взрывного тренда.Причины могут быть разные, но самая большая причина может быть в том, что нет огромного спроса на продвижение , технологии с реальным потенциалом должны быть такими, без обучения которым, по вашему мнению, не обойтись.
• Существенная разница между веб-приложением и нативным приложением заключается в том, размещается ли скомпилированный продукт на сервере или на клиенте. Статические ресурсы веб-приложений необходимо получать с сервера, что является основной причиной плохой работы веб-приложений. HTTP-кеширование браузера и кэширование Service Worker — оба компромиссные решения, по крайней мере, они не могут решить проблему медленной загрузки первого экрана.
• Видя, что наступает эра 5G, остается ли проблема производительности веб-приложений проблемой? Имеет ли значение улучшение производительности на сотни миллисекунд, которое может принести Service Worker? Когда сетевые условия большинства людей выйдут на новый уровень, веб-страница больше не будет зависать на несколько секунд, а приложение можно будет загрузить в одно мгновение, будем ли мы действительно выбрасывать кеш? Будут ли по-прежнему существовать веб-страницы и приложения?

На данный момент эта статья правильно отвлеклась.Что касается Service Worker, он действительно подходит для хвастовства.Если вы действительно хотите применить его в больших масштабах, вам может потребоваться рассмотреть его в сочетании с конкретной ситуацией. Но в любом случае он все же необходим как технический резерв. Не говоря уже о том, что еда на вынос холодная. Тогда почему ты все еще стоишь на месте? Спешите ставить лайки, комментировать и добавлять в избранное!

насчет нас