Ближайшие изменения в браузере 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.
Поделиться с друзьями
-->

Комментарии (78)


  1. Color
    25.01.2017 12:34
    +2

    Закрепленные вкладки тоже считаются фоновыми? Насколько я понимаю — нет. Если я прав, то это хорошее решение для подобных сервисов, если учесть, что люди, их использующие, и так все время держат их открытыми.
    Костыль, но минимальный

    Алсо, исключения бы все решили


  1. APLe
    25.01.2017 12:38
    +9

    1). Ура, у хрома появляется функциональность Оперы конца прошлого десятилетия! С поправкой на современные технологии, конечно.
    Я, помнится, очень удивился, когда уходя с Оперы, выяснил, что другие браузеры не отключают проигрывание flash и гифок в фоновых вкладках.
    2). А что мешает дать возможность пользователю отключать подавление на некоторых сайтах? Страниц, которым действительно нужно постоянно делать что-то в фоне, не так много.


    1. Murmurianez
      25.01.2017 20:30
      +2

      Юзабилити. Как вы обычному человеку будете объяснять почему нотификации из VK не вовремя приходят? Туториал при заходе на сайт выводить? Делать больше нефиг. Оптимизации браузера не должны беспокоить пользователя.


      1. vilky
        26.01.2017 08:36

        Получать нотификации через браузер — это так же логично, как встроенный в браузер почтовый клиент. То есть нифига не логично. А уж если удобство получения нотификаций вступает в конфликт с удобством веб-сёрфинга (активного поиска новой информации)…


        1. devpreview
          26.01.2017 16:47

          Получать нотификации через браузер — это так же логично, как встроенный в браузер почтовый клиент.

          Для пользователей интернета 2000-х — не логично. Для «только что подключившихся» — вполне логично.


      1. APLe
        26.01.2017 13:36
        +2

        По аналогии с заблокированными по умолчанию всплывающими окнами, можно показывать уведомление «Эта страница потребляла много ресурсов в фоновом режиме, поэтому мы её усыпили. Разрешить фоновую работу для этой страницы?»


  1. amarao
    25.01.2017 13:04
    +6

    Берём и пускаем рекламу с неслышным звуком (т.е. volume =0, сплошные нули в wav'е). Получаем приоритет для выполнения чего попало. Пользователя раздражает только лишняя иконка в табе, но в целом — никаких неудобств.


    1. maniacscientist
      25.01.2017 13:12
      +8

      >выполнения чего попало

      Ага, скрытый канвас с вебгл и шейдером, добывающим криптовалюту


    1. spmbt
      25.01.2017 18:46

      Минимального циклического аудиоплеера с данными в Base64 даже достаточно.
      В следующих рекомендациях по оптимизации сайтов это будет одним из пунктов: ).


      1. aamonster
        25.01.2017 21:45
        +1

        Ну, кто как, а я обращу внимание на иконку звука в таб баре — и сайт отправится в чёрный список за компанию с прочими, кто без спроса включает звук.


    1. artskep
      25.01.2017 18:51

      Мне все это напоминает давний квест с фоновыми задачами на iOS.
      Там тоже использовали звук тишины, мелкие загрузки, что-то еще (уже не помню).
      В конце концов это все равно резалось рано или поздно.

      Я уже не первый год вижу, что Гугл идет по пути Эппла в отношении песочниц. Т.е. ужесточение требований.
      Так что я не удивлюсь, если скоро запретят вообще фоновые задачи, и скажут, что «хотите асинхронности — делайте push message с сервера». И да, 'push' только через авторизованный сервер и API с подпиской (чтобы бороться со спамерами и прочим).


  1. ganzmavag
    25.01.2017 13:18
    -1

    Vivaldi с их возможностью выгрузить фоновые вкладки вспомнился сразу. Хотя мне этот функционал безразличен: годы, проведенные на компе с малым объемом оперативки, приучили вкладки закрывать сразу же. Когда их много, начинаю путаться.


    1. Ktulkhu_Triediniy
      25.01.2017 15:01
      +1

      Сам Хром уже достаточно давно этим занимается на ПК с малым количеством ОЗУ.


    1. spmbt
      25.01.2017 18:48
      +3

      The Great Suspender в Хроме этим занимается.


  1. evilrussian
    25.01.2017 13:19
    -1

    Когда-нибудь разработчики хромиум-браузеров наконец-то сделают настройки прокси/проксей с white/black листами? Для чего надо было выпиливать данную настройку?


    1. Barafu
      25.01.2017 13:52
      +1

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


    1. medkit
      26.01.2017 22:33

      Многие браузеры (в том числе и хром) поддерживают Proxy Auto Config файлы.
      Нужно лишь написать код на javascript для выбора прокси с учётом белого/чёрного списка.


  1. k12th
    25.01.2017 13:30

    Я думал, что этот механизм уже работает, потому что заметил, например, что YouTube не переключается на следующий ролик в плейлисте, если вкладка в фоне. Хуже того, этим страдает и Spotify, правда, не постоянно.


    Надеюсь, эту "оптимизацию" можно будет отключать.


    1. voidMan
      25.01.2017 13:55

      Я думаю, в случае Youtube, это фича самого сервиса, а не браузера.


      1. gimntut
        25.01.2017 16:21
        +7

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


        1. Ryav
          25.01.2017 20:06

          Серьёзно? А я помню, как приходилось жмякать на паузу после каждого открытия новой вкладки. Как только перешёл на Youtube Center, сразу поотключал автоматическое проигрывание.


          1. sumanai
            25.01.2017 21:18

            Это не так давно освоили. Хотя как сказать не так давно- думаю год уже прошёл.


  1. yefrem
    25.01.2017 13:33
    +1

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


  1. nikitastaf1996
    25.01.2017 13:37
    +1

    Очевидным кажется приём с постоянным проигрыванием звуком на нулевой громкости

    Ужас.И поломать значок звука.Супер.


  1. mukizu
    25.01.2017 13:42

    В качестве дополнения\пояснения от разработчиков:

    https://news.ycombinator.com/item?id=13473644


  1. Caelwyn
    25.01.2017 13:44

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


    1. ffs
      25.01.2017 13:55
      +1

      Не знаю, не знаю, и дискорд, и почта и такое другое работает отлично.


      1. DarkByte
        26.01.2017 18:18
        +1

        Наверное потому что они подгружают новую информацию с использованием long poll запросов. setInterval для загрузки новых сообщений — это почти как meta refresh и iframe, работает конечно, но как то не современно.


  1. olafnew
    25.01.2017 14:34

    Ура! Может хоть это сподвигнет развивать нормально Standalone приложения, а не браузерные приложения.

    Вообще — идея полной работы только в браузере — в многих случаях откровенно неудобна. Хороший пример — Facebook@Work, и его чат, который работает только в браузере. Из-за этого невозможно полностью перейти только на него, т.к. браузерные приложения откровенно неудобны в некоторых сценариях работы за ПК.


    1. orcy
      25.01.2017 15:41
      +4

      > Ура! Может хоть это сподвигнет развивать нормально Standalone приложения, а не браузерные приложения.

      Это будет веб-приложение завернутое в электрон и предоставленное вам как standalone. Как можно легко угадать, это только ухудшит производительность системы.


      1. Vasia529
        25.01.2017 17:31
        +1

        Более того, и у слака, и у дискорда приложения именно такие :)


        1. inoyakaigor
          26.01.2017 12:27

          Не знаю как у Дискорда, но у Слака есть jabber транспорт и поэтому я пользуюсь старым добрым QIP для слака и знаете, это, как минимум, решает проблему сохранения истории сообщений (естественно на бесплатном аккаунте)


  1. ilyamodder
    25.01.2017 14:37
    +3

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

    Может, это стоит сделать на сервере и присылать клиенту минимум информации для непосредственно уведомления?


    1. Iv38
      25.01.2017 15:45

      Я тоже об этом подумал. А обновить интерфейс можно и после активации вкладки.


  1. Pinsky
    25.01.2017 14:38

    Ждем, когда флэш начнет блочится активнее. 55я версия уже начала, но хочется дальнейшего прогресса.


    1. sumanai
      25.01.2017 16:01
      +1

      А может просто удалить? Я у себя давно флеш удалил, не жалею. Правда у меня FF, не знаю, как с этим в хроме.


      1. dom1n1k
        25.01.2017 17:09

        Именно удалил или отключил? Я вот отключил и некоторые видеохостинги (rutube кажется и еще какие-то новостные сайты) перестали работать — видеоплейер определяет, что флеш как будто бы есть и грузит флешевую версию, которая естественно не работает. У youtube таких проблем нет.


        1. sumanai
          25.01.2017 17:29
          +1

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


    1. somniator
      25.01.2017 16:12
      +2

      флеш можно заблочить по адресу chrome://plugins/


      1. isden
        26.01.2017 11:04

        У меня он сам включается обратно через какое-то время почему-то. Подозреваю, что после каждого обновления.


  1. darthmaul
    25.01.2017 15:19

    Надеюсь это можно будет отключить. Неужели так много людей с железом пятнадцатилетней давности пользуются Хромом? На 8-ми летней раочей станции ещё ни разу не сталкивался с падением производительности в браузере.


    1. k12th
      25.01.2017 15:41

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


      1. darthmaul
        25.01.2017 15:42

        Так и я об этом. Для мобильных девайсов это актуально, для настольных — нет.


        1. k12th
          25.01.2017 15:44

          Вы предлагаете делать отдельные версии хрома для ноутов и десктопов?


          1. darthmaul
            25.01.2017 15:44

            Зачем? Галочку «оптимизировать энергопотребление» в настройках и всё.


            1. k12th
              25.01.2017 15:48

              Ваши слова были:


              падением производительности

              Я вижу что все-таки донес до вас, что речь не о производительности, а об энергии. Еще вопросы?:)


    1. schetilin
      26.01.2017 00:42
      +2

      Вы даже представить себе не можете, но процентов 75 обычных пользователей имеют именно такое железо.


      1. darthmaul
        26.01.2017 00:43
        -2

        Они же на IE, Edge или Safari сидят. Железо сейчас не дорогое, если у человека старый ПК — то ему просто новый не нужен, как и сторонний браузер.


    1. Aingis
      26.01.2017 17:05

      У меня пятилетнее железо, причём с топовым процессором. Так вот я заметил, что тормозит видео из-за такой казалось бы безобидной фоновой вкладки, жрущей 35% процессора. Кажется, это был Циан с баннером.

      P.S. ТМ тоже «молодцы», страницы Хабра и ГТ периодически вылетают на iOS с сообщением «сбой на странице, она была перезагружена». Видимо, пора резать рекламу…


  1. Delics
    25.01.2017 15:22
    -1

    Почему атака идет просто на все таймеры без разбора?

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

    А сейчас — какое-то «ленивое решение» получилось.


    1. k12th
      25.01.2017 15:43
      +1

      Решение достойное 2017 года, домохозяйка-френдли. Неквалифицированный пользователь пугается любого выбора.


    1. Iv38
      25.01.2017 15:50
      +1

      Так примерно оно и сделано. У таймеров есть бюджет. Если приложение выполняет тяжелый код, оно израсходует бюджет быстрее и будет приторможено. Более легкие скрипты могут не успеть израсходовать бюджет (он ведь пополняется) и будут получать меньше задержек или не будут получать их вообще.


    1. simple-simple
      25.01.2017 17:04

      К сожалению, это наверное достаточно сложно — оптимально распределить приорететы выполняемых процессов. Посмотрим что из этого выйдет. Может в будущем придумают более изящное решение. Наука и техника не стоят на месте )


  1. Jogger
    25.01.2017 15:52
    +3

    Хорошее нововведение. Ещё бы что-то с потреблением памяти сделали… А то когда хром отожрал 100% памяти уже всё равно, понизил он приоритет вкладкам или нет — всё равно тормозить об своп-файл будет.


    1. vdasus
      25.01.2017 21:54
      -2

      Хреновое нововведение… Любое решение, которое доставляет неудобство людям в угоду железу (батарейкам) это в корне плохо. Пусть развивают алгоритмы, железо, а не «а теперь ты подождешь потому, что мы не умеем расходовать твою батарейку»…


      1. Jogger
        25.01.2017 22:09

        Не знаю, кому как, а мне это решение доставит удобство (конечно, при условии что я начну активно пользоваться хромом).


      1. Free_ze
        26.01.2017 14:11
        +1

        Вы считаете, что плохо серфить лучше, чем вообще не серфить? Подобное вынудит разработчиков оптимизировать свои алгоритмы, это ж идеально!


  1. DexterHD
    25.01.2017 18:10
    +8

    Ну вот, за исправление ошибок фронтендщиков взялись разработчики браузеров, рано или поздно это должно было случится. Нельзя же вечно говнокодить на JS и думать только о новых фреймворках, и о том как прикрутить вот эту модную фичу из stage-0 («ехал babel через babel видит babel babel babel...»)


    1. Deosis
      26.01.2017 08:34

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


  1. perfect_genius
    25.01.2017 22:00
    +6

    Вкладки превращаются… превращаются… в закладки!


  1. quwy
    26.01.2017 03:41
    +2

    Давно пора было что-то такое сделать. Уже не один раз замечал, что процесcор на компьютере рядового интернет-юзера перманентно загружен на ~100%. Скрипткодеры совсем связь с реальностью потеряли, пора их осадить. И чем жестче, тем лучше.


  1. handicraftsman
    26.01.2017 08:54

    А если это, скажем, какой-нибудь Cookie Clicker, у которого нет музыки, или что-то с отключенным/отсутствующим звуком? Нет, это определённо надо сделать отключаемым, причём для каждой вкладки, а не для всех сразу.


  1. lamo4ok
    26.01.2017 10:42

    Честно говоря, не совсем удачные примеры, на которые еще и упор делается, это я про Discord и Slack — и тот и другой имеют нативные клиенты, и как-то лично мне проще пользоваться именно ими, так что проблемы в конкретно их случае вообще не видно. А вот различные социальные сети — это да, держать их в закрепленных вкладках не вариант, приложений нативных они не выпускают. По крайней мере — пока что :)


    1. isden
      26.01.2017 11:10

      «Нативный» клиент того же Слака — это, грубо говоря, браузер (в котором работает все та же веб-версия), завернутый в отдельное приложение.


      1. lamo4ok
        26.01.2017 11:29
        +1

        Не вопрос, что это меняет в моем комментарии?


        1. isden
          26.01.2017 11:32

          Это не «нативные» клиенты же. Точно так же можно отцепить вкладку от браузера (или поставить другой браузер) и там запустить.


          1. lamo4ok
            26.01.2017 13:20

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


            1. Free_ze
              26.01.2017 14:15

              Это отдельно взятое приложение, со всеми типичными признаками отдельного приложения

              ..., что не делает его нативным.


              1. lamo4ok
                26.01.2017 14:46

                Попробуйте тогда привести свое определение нативности приложения.


                1. Free_ze
                  26.01.2017 15:14

                  API-вызовы системы клиентским кодом, без прослоек в виде браузеров и других исполняющих сред, очевидно же. (фреймворки и библиотеки, с которыми клиентский код линкуется не считаются).

                  Java-софт для Windows не нативен.
                  Java-софт для Android — нативен.
                  Phonegap-софт для Android — не нативен.
                  JavaScript-софт для ChromeOS — нативен.


                  1. lamo4ok
                    26.01.2017 15:21

                    Вы понимаете, что в общем-то ведете речь с точки зрения разработчика, тогда как в посте речь изначально о пользователях?


                    1. Free_ze
                      26.01.2017 15:28
                      +1

                      Да, согласен, я погорячился. Но нативность здесь не играет роли, речь должна идти о standalone'овости. С точки зрения пользователя нативность — это внешний вид и поведение.


                      1. lamo4ok
                        27.01.2017 03:40

                        Я главным образом вообще о том писал, что конкретно приведенные примеры в посте могут быть заменены отдельными приложениями, которые поставляют сами разработчики, и я не вижу причин этого не делать, если честно, зачем в браузере держать то, что можно использовать отдельно — это удобнее в 95% случаев.


                  1. vikarti
                    26.01.2017 17:35

                    Java-софт для Sailfish? Java-софт для BBOS 10? (в обоих случаях там имитируется Android'ная JVM поверх ну совсем другого ядра)
                    Unity-софт под iOS и Android (если нативен то собственно почему? только из-за того есть компилятор IL в C++ и за собой таскается половина от Mono)? Да и GUI обычно канонам платформы… не следует.
                    Java-софт на Chrome OS? А если учесть https://sites.google.com/a/chromium.org/dev/chromium-os/chrome-os-systems-supporting-android-apps?
                    Linux-софт на Windows 10 с Subsystem for Linux?
                    Win32 софт на Windows 7(и Windows 10)?
                    А в чем отличие двух предыдущих пунктов кроме того что соответствующая подсистема включена по умолчанию и куча софта в составе самой ОС ее используют? (при этом API ядра все равно используется не напрямую (если не брать в расчет оптимизации) и есть и Native API
                    приложения под Win3.1 под OS/2 со встроенным модулем совместимости (который работал лучще и стабильнее чем сам Win3.1)


      1. handicraftsman
        29.01.2017 16:56

        С дискордом то-же самое.


  1. Kastrulya0001
    26.01.2017 11:19

    Жаль только, что они слишком запрятали кнопку отключения этих «фичей». Я использую примерно 10-15 вкладок одновременно и предпочитаю, чтобы они всегда висели фоном и не уходили в сон, для этого я даже память компа увеличил.


  1. Kehit
    26.01.2017 12:38

    А как-нибудь можно отключить функционал «отключения» вкладок, который реализован сейчас у хрома? Крайне не приятная штука.


  1. 1514m
    27.01.2017 02:35

    Эта функция не слишком отличается от того же doze/greenify на android. Для оповещений вроде есть отдельное api типа gms, их можно кинуть в исключения. Все прочее усыпить.