Ближайшие изменения в браузере Chrome вряд ли порадуют разработчиков Slack, Discord и других программ, которые работают во вкладках браузера. В бета-версии Chrome 56 реализован новый механизм оптимизации таймеров для фоновых вкладок.
На первый взгляд, инициатива разработчиков выглядит хорошим делом. В сентябрьском плане внедрения (Intent to Implement) объясняются причины, которые сподвигли разработчиков на такое решение.
Главная причина — некоторые плохо спроектированные приложения (например, скрипты аналитики и javascript-реклама) потребляют много ресурсов CPU, хотя находятся в фоновом режиме. Это негативно отражается на производительности браузера и потребляет энергию аккумулятора на мобильных устройствах. Такая обработка активности в фоновых вкладках совершенно ни к чему. Идея состоит в том, чтобы установить максимальный лимит вычислительных ресурсов, которые можно дать фоновому приложению.
Реализация плана выглядит следующим образом:
- У каждого компонента WebView будет бюджет (в секундах) для работы таймеров в фоновом режиме.
- Таймер не может запуститься, если бюджет отрицательный.
- После выполнения таймера его время работы вычитается из бюджета.
- Бюджет автоматически пополняется со временем (на 0,01 с бюджета с каждой секундой реального времени).
Разработчики решили, что торможение фоновых вкладок никак не помешает пользователю. Вкладки с активным звуком в Chrome не считаются фоновыми, так что на них нововведение никак не скажется.
Наибольшее опасение вызывали фоновые страницы трёх типов:
- которые используют таймер для изменения фавикона, как это делает Gmail;
- которые используют таймеры для воспроизведения звука, например, для звука входящего сообщения в мессенджере (касается практически всех мессенджеров и групповых чатов);
- только что открытая страница, которая начала загружаться, а пользователь в это время открывает новую вкладку с расчётом, что эта страница загрузится до конца в фоновом режиме.
Предварительные тесты показали, что реализация торможения фоновых вкладок не поломала функциональность Gmail, хотя затормозила некоторые нотификации в тех мессенджерах и программах, которые активно используют ресурсы CPU. В целом, реализация работала хорошо и действительно снизила энергопотребление и быстродействие браузера в активных вкладках.
Проблему с загрузкой страниц решили так, что бюджет таймера вообще не распространяется на загрузку страниц, то есть они фактически не считаются фоновыми.
Казалось бы, разработчики всё продумали и всё отлично. Небольшое замедление с приходом нотификаций в мессенджере — не такая уж большая проблема.
Но в реальности оказалось, что нотификации в фоновых приложениях могут приходить с опозданием на несколько минут. Это уже конкретно ломает функциональность таких приложений. Создателям придётся искать способы, как обойти этот встроенный «режим энергосбережения» Chrome. Очевидным кажется приём с постоянным проигрыванием звуком на нулевой громкости. Возможно, они придумают что-нибудь ещё.
Казалось бы, фоновым приложениям нужно всего лишь уменьшить потребление CPU, чтобы уложиться в вычислительный бюджет, который выделяет для них браузер. Но это не выход. В реальности многим приложениям действительно нужно выполнять большой объём работы в фоновом режиме. Например, популярные программы вроде Slack и Discord постоянно синхронизируют каналы, парсят новые сообщения от сотен пользователей в десятках каналов, чтобы определить, когда нужно побеспокоить пользователя нотификацией, а когда не нужно этого делать.
Slack и Discord — не единственные такие программ, есть очень много других веб-приложений, которые активно работают в фоновом режиме. Например, биржи для биткоин-трейдинга в реальном времени. Чтобы проверить новый режим Chrome разработчик одного из таких ресурсоёмких приложений запустил в фоновой вкладке Chrome 56 процесс setInterval с выполнением каждую секунду и фиксацией реального времени выполнения. Вот какое реальное время он зафиксировал в логе:
1002
1003
1000
1012
1001
1965
1962
1089
2078
1832
1071
6917
34402
136717
76192
38682
6030
Как видим, через пять секунд фоновая вкладка начала выбиваться из бюджета, который ей выделил браузер. А через 22 реальных секунды бюджет полностью закончился (задержка ивента на 136 секунд).
То есть теперь на таймеры в веб-разработке вообще нельзя полагаться. Негативные последствия ожидают сайты, которые держат открытые соединения WebSocket.
Разработчики Chrome рекомендуют перенести соответствующие процессы в Service Workers. придётся потрудиться, конечно, переписывая код и решая проблемы совместимости. Но там всё должно работать нормально. Разумеется, до того момента, пока разработчики Chrome не примут решение затормозить и фоновые Service Workers тоже.
Разработчикам таких приложений, которые работают в фоновом режиме, рекомендуется применить использовать Page Visibility API, чтобы приложение не делало в фоновом режиме работу, которая всё равно будет невидима пользователем.
var doVisualUpdates = true;
document.addEventListener('visibilitychange', function(){
doVisualUpdates = !document.hidden;
});Такой приём позволяет снизить загрузку CPU на 75%
Другие нововведения в Chrome 56
Официальный релиз стабильной версии Chrome 56 (движок Blink версии 537.36) запланирован на январь 2017 года (ориентировочно 31 января).
В ближайшей официальной версии Chrome 56 разработчики не планируют включать подавление активности в фоновых вкладках. Этот эксперимент продолжится на бета-канале, а после сбора отзывов пользователей его планируют выкатить в Chrome 57 (14 марта 2017 года). Сейчас разработчики обсуждают, какие изменения внести в механизм подавления фоновых вкладок. На странице обсуждения рассматриваются разные варианты исключение: метатеги, закреплённые вкладки, явное разрешение пользователя на показ уведомлений.
Нововведением в Chrome 56 станет то, что он будет по умолчанию считать небезопасными HTTP-страницы, содержащие поле для ввода пароля. Такие страницы будут помечаться заметным красным индикатором.
Со временем подобный индикатор получат все сайты, которые не перешли на HTTPS.
Автор: alizar
