Увеличение времени работы от аккумулятора в Android M
По мнению многих разработчиков, в большинстве случаев к слишком быстрому разряду аккумуляторов смартфонов приводит плохая оптимизация приложений. В мае этого года в Google прошла очередная ежегодная конференция Google I/O, на которой было анонсировано много всего интересного для разработчиков. В частности, когда речь зашла об Android M, то одной из центральных тем были именно производительность мобильных устройств и продолжительность работы от аккумулятора. Давайте взглянем на новые функции и инструменты, которые помогут пользователям и разработчикам выжать ещё больше из аккумуляторов мобильных устройств.
Это один из главных инструментов в новой ОС для обуздания активности приложений, когда устройство находится в спящем режиме. На смартфонах под управлением Lollipop и более старых версий Android, любое приложение может вывести устройство из сна ради своего обновления, что позволяет поддерживать актуальность данных. Doze анализирует текущее состояние устройства и данные с акселерометра, определяет, когда смартфон не используется, и отправляет его в «глубокий сон». В этом режиме обновление приложений запрещается до тех пор, пока устройство не будет разбужено каким-то иным, более приоритетным событием. В режиме «глубокого сна» отключается сетевая активность, блокировки засыпания, предупреждения и задачи JobScheduler.
Как подсказывает опыт, часто обновляющиеся в фоновом режиме приложения являются одной из главных причин быстрого разряда аккумулятора. И Google придерживается того же мнения. На конференции была приведена информация, что планшеты Nexus 9 с запущенным Doze работали почти в два раза дольше в режиме ожидания.
Чтобы протестировать эту функцию, обновитесь до Android M, а затем с помощью команды ADB отключите зарядку устройства:
Doze может переводить устройство в один из нескольких режимов:
- ACTIVE: дисплей включен.
- INACTIVE: дисплей выключен, но устройство активно.
- IDLE_PENDING: переход в состояние «глубокого сна».
- IDLE: устройство спит.
- IDLE_MAINTENANCE: короткий промежуток времени, в течение которого разрешается выполнение всех запланированных уведомлений и обновлений.
Между этими состояниями можно переключаться вручную:
Сколько времени нужно на перевод устройства в этот режим?
Это позволяет получить много интересной информации о Doze. К примеру, на Nexus 6 (с включённым дисплеем) были получены следующие результаты:
В первой части перечисляются процессы, аккредитованные Doze. Их активность никак не ограничивается. Обратите внимание, что в этот список вручную добавлен Facebook (Настройки —> Аккумулятор —> Facebook —> активировать «Отключить оптимизацию»). Далее идёт раздел с информацией с акселерометра и состоянием дисплея. Эти данные будут использоваться для последующего вывода устройства из состояния «глубокого сна». В данном примере дисплей включен, а значит Doze находится в режиме ACTIVE.
Период неактивности устройства установлен в 30 минут. Если выключить дисплей, этот раздел меняется:
С выключенным дисплеем устройство переходит в режим INACTIVE и может переключиться в режим перехода в «глубокий сон». Таймаут также равен 30 минутам, и, согласно таймеру, из этого периода прошло около 1,5 минут. Вручную переводим устройство в IDLE_PENDING:
Спустя 30 минут пребывания в этом режиме, устройство перейдёт в IDLE. Таким образом, для перехода в «глубокий сон» требуется суммарно 60 минут. Переход:
Через 60 минут сработает триггер, устройство пробудится и отправит все накопившиеся сообщения, инициализирует события и триггеры. Параметр mNextIdleDelay говорит о том, что следующее пробуждение из «глубокого сна» произойдёт через 2 часа. Получается следующая цикличность смен режимов: 1, 2, 4 и 6 часов. То есть самый большой промежуток между пробуждениями составляет 6 часов, 4 раза в сутки.
Как ведут себя приложения, когда устройство выходит из режима «глубокого сна»?
Можете самостоятельно протестировать своё приложение, отправив устройство в «глубокий сон»:
С помощью той же команды его можно пробудить (введя значение false вместо true ), и посмотреть, как активируются разные процессы, рассылаются и выполняются запросы.
Как видите, Doze является замечательным инструментом для экономии аккумулятора, когда устройство выключено.
Режим ожидания для приложений
В текущих версиях Android любое приложение имеет доступ к радиомодулю, даже в фоновом режиме. Иными словами, какое-нибудь давно скачанное и забытое вами приложение может втихую по несколько раз в день передавать какие-либо данные без вашего ведома. С помощью Doze это можно заблокировать запуск приложений, но они всё-равно смогут запускать процессы и обновляться, когда пользователь включает дисплей устройства. С помощью новой функции режима ожидания для приложений (App standby) можно приложениям, которые не запускались в активном режиме в течение какого-то периода времени (в днях), принудительно назначать режим ожидания. В этом режиме приложениям ограничивается доступ в интернет или запуск каких-либо процессов, пока смартфон не будет подключён к зарядному устройству. Тем самым экономится аккумулятор устройства.
Как работает режим ожидания для приложений? Если выполнить:
то можно получить много информации об активности приложений за последний день/неделю/месяц и год.
Встроенный в ОС алгоритм определяет дату последнего запуска приложения, и при необходимости переводит его в неактивный режим. Список таких приложений можно просмотреть, если зайти в меню настроек в пункт “Inactive apps”.
Производительность приложений
Наверное, все из вас оказывались в ситуации, когда аккумулятор смартфона садится слишком быстро, но непонятно, из-за чего это происходит. Если зайти в Настройки —> Батарея, то можно получить подробную статистику потребления энергии по каждому приложению:
В данном случае основные потребители заряда аккумулятора: ЦПУ (в том числе и в фоновом режиме), сетевой протокол и радиомодуль. Представленная статистика собрана за 28 часов, с момента полной зарядки аккумулятора.
Также в Android M теперь доступно меню, с помощью которого можно «игнорировать оптимизацию». В этом случае отключаются Doze и режим ожидания для приложений. Это позволяет разработчикам тестировать производительность своих приложений как с включённой, так и с выключенной оптимизацией, выясняя, как это влияет на продолжительность работы от аккумулятора. А заодно как быстро устаревают данные в приложении.
GCM Network Manager
Замечательная новинка, для использования которой даже не требуется наличие Android M — её можно запускать на любых версиях ОС, вплоть до 2.3!
В вышедшем в конце прошлого года Lollipop появился JobScheduler API. На Android 5.0 и выше этот API отделяет от приложений все аппаратные предупреждения и блокировки засыпания, перенося их на уровень ОС. Это позволяет операционной системе агрегировать все эти события от разных приложений, тем самым уменьшая количество пробуждений и предупреждений, а значит и экономя заряд аккумулятора. Замечательно, вот только работает это на Lollipop и выше (на момент написания статьи, это примерно 12,4% Android-устройств).
Чтобы обеспечить тот же уровень производительности для сетевых соединений, в Google Play Services версии 7.5 добавят GCM Network Manager. Он использует фреймворк, аналогичный JobScheduler, но при этом будет работать на любых устройствах, где установлен Google Play Services (вплоть до Android 2.3, то есть на 99% всех Android-устройств). GCM Network Manager поддерживает такие же сценарии и режимы, что и JobScheduler, а также позволяет ограничивать количество сетевых подключений до тех пор, пока смартфон не будет подключён к зарядному устройству, а также использовать для больших обновлений исключительно Wi-Fi.
Все эти нововведения говорят о том, что Google озаботился производительностью приложений и старается дать разработчикам подходящие инструменты. Также мы теперь можем лучше контролировать поведение приложений ради снижения энергопотребления смартфонов.
Источник
Android 6.0: Doze Mode, App Standby, Runtime Permissions. Всё, что необходимо знать каждому разработчику
В этой статье мы рассмотрим три самых важных изменения в новом Android, которые не могут быть проигнорированы ни одним разработчиком, который поставил у себя в проекте targetSdk = 23 и выше.
Doze Mode — режим «отключки», в который переходят все устройства на Marshmallow после некоторого времени обездвижения без зарядки.
App Standby — автоматическое лишение приложений доступа к ресурсам устройства, всех которые давно не открывал пользователь.
Runtime Permissions — новая модель запроса разрешений. Теперь мы, как разработчики, каждый раз обращаясь, например, к микрофону устройства, должны проверять, есть ли у нашего приложения разрешение на доступ к нему.
В Google в новом релизе Android сделали очень важный шаг в сторону оптимизации работы батареи. Все мы знаем, как пользователи любят повонять в комментариях высказываниями: «Дурацкие Google Play Services» жрут 25% батареи моего ******* S III, гопники, верните мне мой драгоценный айфон, нет сил, терпеть издевательства от Гугл». Только вот эти пользователи не ставили себе никогда Battery Historian и не в курсе, что жрут батарею бесплатные игры от сомнительных авторов и такие же сделанные на коленке живые обои, например. Но пользователь этого не знает, и как бороться с кучей левых приложений, беспощадно съедающих батарею, он не в курсе.
Ну теперь пользователям об этом заботиться и не придется. С приходом двух новых режимов Doze Mode и App Standby операционная система перекрывает кислород всем чрезмерно жрущим заряд приложениям. Как? Читаем далее:
Doze Mode
Когда устройство на Android Marshmallow лежит без движения и без зарядки, спустя час оно переходит в Doze Mode. Режим отключки, когда почти все приложения перестают жрать батарею.
Это происходит не сразу, а по шагам:
ACTIVE — Устройство используется или на зарядке
INACTIVE — Устройство недавно вышло из активного режима (пользователь выключил экран, выдернул зарядку и т.п.)
. 30 минут
IDLE_PENDING — Устройство готовится перейти в режим ожидания
. 30 минут
IDLE — Устройство в режиме бездействия
IDLE_MAINTENANCE — Открыто короткое окно, чтобы приложения выполнили свою работу
Мы можем продебажить наши приложения, переключаясь последовательно между этими шагами с помощью:
В момент, когда устройство переходит в состояние IDLE:
- Доступ приложению к сети отключен, пока приложение не получит high-priority GCM-push.
- Система игнорирует Wake lock’и. Приложения могут сколько угодно пытаться запросить пробуждение процессора — они их не получат.
- Alarm’ы запланированные в AlarmManager не будут вызываться, кроме тех, которые будут обновлены с помощью setAndAllowWhileIdle().
- Система не производит поиска сетей Wi-Fi.
- NetworkPolicyManagerService: пропускает только приложения из белого списка.
- JobSchedulerService: все текущие задачи отменяются. Новые откладываются до пробуждения.
- SyncManager: все текущие отменяются, новые откладываются до пробуждения.
- PowerManagerService: только задачи приложений из белого списка вызовутся.
Соответственно, если наше приложение чат, то мы можем отправить с сервера push с полем priority = high.
А если у нас приложение будильник, то мы должны обязательно вызвать для Alarm setAndAllowWhileIdle() или setExactAndAllowWhileIdle().
Во многих других случаях мы вообще не должны об этом переживать, после того, как пользователь возьмет устройство в руки, все заснувшие alarm’ы и SyncAdapter’ы проснутся и сделают свою работу. (Да-да я знаю, что после выхода из doze mode все начинает синкаться и даже Nexus 9 минуты две тормозит)
App Standby
Но не только при попадании устройство в Doze Mode наши приложения будут лишены возможности разряжать батарею. Второй режим под название App Standby отправляет в такую же изоляцию приложения, которые не подходят под условия:
- Пользователь явно запустил приложение.
- Приложение имеет процесс, работающий в данный момент на переднем плане (Activity или foreground service, или используется другой activity или foreground service’ом).
- Приложение создало уведомление, которое висит в списке уведомлений.
- Пользователь принудительно добавил приложение в список исключений оптимизации в настройках системы
Исключения
Возможно сейчас разработчики коммерческих voip нервно начали продумывать, как запретить обновляться своим пользователям на пугающий своей жесткостью Android Marshmallow. Но не волнуйтесь, есть специальный Whitelist, в который пользователь руками может добавить исключения. Приложениям из Whitelist не страшны ни Doze Mode ни App Standby.
Чтобы проверить, попало ли наше приложение в Whitelist вызываем метод isIgnoringBatteryOptimizations().
Пользователь может сам руками добавить/удалить из списка в настройках Settings > Battery > Battery Optimization
Но мы можем его сами попросить с помощью интента ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS или запросив пермишен REQUEST_IGNORE_BATTERY_OPTIMIZATIONS, который покажет диалог на автоматическое добавление в вайтлист с разрешения пользователя.
Runtime Permissions
Мы подобрались к самому известному изменению в Android Marshmallow. Более того это изменение требует от нас наибольшего вовлечения в перелопачивание кода приложения. Кратко говоря: халява кончилась.
Да-да, каждый раз, когда наше приложение обращается, например, с запросом на местоположение пользователя, мы должны проверить, есть ли у приложения разрешение от пользователя на это действие. Если есть — обращаемся к нужным нам системным ресурсам, если нет — запрашиваем. Так же пользователь может навсегда приложению запретить доступ, тогда единственный наш шанс — это попросить его самого зайти в настройки и снять запрет, показав ему объясняющее сообщение, зачем нам нужен доступ.
Стоит отметить, что Permissions в Android делятся на два типа:
- Нормальные разрешения, вроде доступа к сети и bluetooth.
- Опасные разрешения. В этот список входят разрешения на: календарь, камеру, контакты, местоположение, микрофон, телефон, сенсоры, смс и внешнее хранилище
Вот как раз все опасные разрешения мы и должны постоянно проверять, ибо пользователь может в любой момент их запретить. Да и при первом старте доступа у приложения к ним нет.
Итак, последовательность наших шагов:
- Описать только PROTECTION_NORMAL запросы в manifest
- Пользователь их все подтвердит при установке
- Когда приложению нужен доступ к одному или нескольким разрешениям из группы опасных, проверить, нет ли разрешения
- Если разрешения нет — запросить
- Если разрешения не будет — объяснить, на что это повлияет
- Если разрешение получено — продолжить работу
Чтобы проверить доступность разрешения дергаем ContextCompat.checkSelfPermission (Context context, String permission).
Чтобы запросить разрешения, показав системный диалог, вызываем ActivityCompat.requestPermissions();
Результат этого запроса придет в асинхронный колбэк в активити onRequestPermissionsResult(), в нем мы узнаем решение пользователя по каждому из запрошенных разрешений.
Запрашивать лишь те разрешения, которые действительно нужны. До сих пор в Google Play находятся разработчики, которые запрашивают все подряд
Если есть возможность, вместо запроса воспользоваться внешним Intent. Например, для фото или видео часто нет смысла встраивать камеру в приложение, гораздо проще воспользоваться внешним приложением
Запрашивать разрешение, только перед тем, когда оно понадобится. Запрашивать при старте приложения все разрешения нелогично (из тех, которые нам нужны), их смысл как раз в том, что мы запрашиваем их в контексте их использования.Например, пользователю становится понятно зачем его банковскому клиенту доступ к контактам — чтобы выбрать одного при шаринге по ФИО
Пояснять пользователю, для чего запрашивается разрешение. Если пользователь все же запретил приложению доступ, а без него оно не может, оно должно максимально понятно объяснить, что без этого разрешения оно работать дальше не будет
Сегодня мы поговорили о самых заметных изменениях в Android Marshmallow. Так же обязательно прочтите полностью вторую статью про остальные изменения и нововведения в Marshmallow. Спасибо за внимание и скорейшую оптимизацию ваших приложений под новый Android!
Источник
