Doze Mode: същност, фази и механизъм за пестене на енергия

Какво е Doze Mode

Doze Mode е вграден механизъм за пестене на енергия в Android, който се активира, когато устройството не е свързано към зарядно, екранът е изключен и потребителят не взаимодейства с устройството за определено време. Целта на Doze е да минимизира фоновата активност на приложенията, за да удължи максимално живота на батерията в режим на готовност. Системата отлага JobScheduler, синхронизация на акаунти, AlarmManager и мрежови заявки.

Режимът беше представен в Android 6.0 Marshmallow (API 23) и значително подобрен в следващите версии. В Android 7.0 Nougat се появи втората фаза (Light Doze), която се активира при движение на устройството. Android 8.0 въведе допълнителни ограничения на фонови услуги, работещи в тандем с Doze. В Android 12+ Doze беше интегриран с актуализирана система за управление на батерията, която анализира поведението на потребителя.

Важно е да се разбере: Doze Mode не изключва напълно приложенията. Той ги прехвърля в състояние с отложени задачи, но не убива процеси. Foreground Service с известие продължава да работи, push известия с висок приоритет (FCM high-priority) се доставят, а алармите се задействат по график. Doze засяга само фонови операции, които потребителят не вижда и не очаква в момента.

Условия за активиране

Doze Mode се активира при изпълнение на всички условия: екранът е изключен повече от 30 минути (първо активиране), устройството е неподвижно (използва се акселерометър), не е свързано към зарядно. Ако потребителят вземе телефона в ръце или свърже зарядното, Doze незабавно се деактивира. В Android 7+ Light Doze се активира още след 5 минути бездействие, дори при движение на устройството.

Как работи Doze Mode

Doze Mode управлява фоновата активност чрез системната услуга DeviceIdleController, която анализира състоянието на сензорите, екрана и зарядното. Когато всички условия за активиране са изпълнени, системата прехвърля приложенията в режим на изчакване, групирайки техните заявки в прозорци на услугата. Вътре в тези прозорци всички отложени задачи — мрежови повиквания, синхронизация, AlarmManager — се изпълняват на партиди.

Системният PowerManager контролира кои приложения могат да излязат от Doze. Push известия с висок приоритет (FCM high-priority) могат да събудят устройството за доставка на съобщение. Системата също игнорира Doze за приложения, добавени от потребителя в Whitelist за оптимизация на батерията. Всички останали приложения трябва да изчакат следващия прозорец на услугата.

Продължителността на прозорците на услугата в Deep Doze нараства експоненциално: първият прозорец след 1 час, вторият след 2 часа, третият след 4 часа и така нататък до максималния интервал от 12 часа. Това означава, че колкото по-дълго устройството остава в Doze, толкова по-рядко приложенията могат да изпълняват фонови задачи — батерията се пести максимално агресивно.

Влияние върху мрежовите заявки

В Doze Mode всички мрежови заявки се спират до настъпването на прозореца на услугата. Изключение правят само FCM high-priority съобщения (с маркер „high_priority” в payload) и сигнали от AlarmManager с флагове setAndAllowWhileIdle() или setExactAndAllowWhileIdle(). Обикновените мрежови повиквания чрез Retrofit, OkHttp или Volley няма да бъдат изпълнени, докато прозорецът не се отвори.

Фази на Doze Mode

Doze Mode се състои от две фази: Light Doze (лек сън) и Deep Doze (дълбок сън). Всяка фаза налага свои ограничения и има различни прагове на активиране. Разбирането на разликата между фазите е критично за разработчика, проектиращ фонови задачи, устойчиви на режима за пестене на енергия.

Light Doze (лек сън)

Light Doze се активира след 5–30 минути бездействие на устройството (екран изключен, без движение). В тази фаза мрежовите заявки и синхронизацията се спират, но AlarmManager и JobScheduler продължават да работят с малки закъснения. Приложенията могат да излязат от Light Doze при получаване на push известие или при свързване към зарядно. Light Doze не изисква пълна неподвижност — устройството може да се движи.

Deep Doze (дълбок сън)

Deep Doze настъпва след 60–90 минути бездействие с неподвижно устройство (акселерометърът не регистрира движение). В Deep Doze системата отлага задачите значително по-агресивно: прозорците на услугата се отварят по-рядко (с експоненциално нарастващ интервал), AlarmManager се задейства само с флагове setAndAllowWhileIdle(), а WakeLock не работи в нормален режим. Приложенията, които не са в Whitelist, почти напълно губят фонова активност.

Ограничения в Doze Mode

Doze Mode налага няколко категории ограничения, които разработчикът трябва да вземе предвид при проектирането на приложението. Игнорирането на тези ограничения води до неизпълнение на фонови задачи и потребителят вижда неправилна работа на приложението — липса на актуализации, неизпратени съобщения, неизвършена синхронизация.

Мрежови ограничения

Всички мрежови заявки се блокират до настъпването на прозореца на услугата. Това включва HTTP повиквания, WebSocket връзки, изтегляне на файлове. Изключение — FCM high-priority съобщения, които преминават през отделен канал на Google Play Services, независим от Doze. За синхронизация на критични данни се препоръчва използването на WorkManager с политика NetworkType.CONNECTED.

Ограничения на AlarmManager

AlarmManager в Deep Doze отлага всички аларми, с изключение на създадените чрез методите setAndAllowWhileIdle() и setExactAndAllowWhileIdle(). Въпреки това, дори тези методи имат ограничение — не повече от 1 задействане на 9 минути на приложение. Точните аларми setExact() в Deep Doze не гарантират задействане в зададеното време.

Ограничения на WakeLock

WakeLock в Doze Mode работи нестандартно: системата не поддържа блокировка на съня за приложения извън Whitelist. Дори ако приложението правилно е придобило PARTIAL_WAKE_LOCK, при настъпване на Deep Doze системата може принудително да го освободи. Единственият начин да се гарантира изпълнение на задача в Doze е използването на Foreground Service с известие.

• Мрежа — всички заявки отложени до прозореца на услугата, освен FCM high-priority
• AlarmManager — точните аларми се отлагат; setAndAllowWhileIdle — не повече от 1/9 мин
• WakeLock — принудително се освобождава за приложения извън Whitelist
• JobScheduler — задачите се групират в прозорци на услугата с експоненциален интервал
• Синхронизация — Account SyncManager се спира до излизане от Doze

Whitelist и изключения

Whitelist (бял списък) Doze е наборът от приложения, на които системата разрешава фонова активност в режим за пестене на енергия с минимални ограничения. Потребителят може ръчно да добавя приложения в списъка чрез Настройки → Батерия → Оптимизация на батерията. Системните приложения, стартерите и услугите на Google Play Services са в Whitelist по подразбиране.

Разработчикът може да поиска добавяне в Whitelist чрез системен диалог с Intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. За това в манифеста се изисква разрешение REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. Въпреки това, Google не препоръчва да искате изключение без основателна причина — приложенията, които злоупотребяват с тази възможност, рискуват да бъдат отхвърлени при публикуване в Google Play.

Без Whitelist приложението може да използва FCM high-priority за събуждане на устройството от Doze. Всяко такова съобщение дава на приложението кратък прозорец (10–30 секунди) за изпълнение на задача. За по-дълги операции приложението трябва да стартира Foreground Service, който ще продължи работа в прозорците на услугата на Doze. Google също така предоставя механизъм за освобождаване за някои типове приложения: навигационни, медицински, месинджъри.

Как да проверите статуса на Whitelist

За да проверите дали приложението е в Whitelist за оптимизация на батерията, се използва методът powerManager.isIgnoringBatteryOptimizations(). Ако методът връща false, приложението се подчинява на всички ограничения на Doze. Ако true — приложението може да използва Wakelock, AlarmManager и мрежа без ограничения дори в Deep Doze. Въпреки това, злоупотребата с тази привилегия ще доведе до лоши оценки от потребителите.

Тестване на Doze Mode

Тестването на поведението на приложението в Doze Mode е задължителен етап от разработката, тъй като Doze може да наруши фоновите функции. Android предоставя инструменти на командния ред чрез ADB за принудително превключване на устройството в Light Doze и Deep Doze. Тестването трябва да се извършва на физическо устройство или емулатор с Android 6.0+.

За влизане в Light Doze се използва командата adb shell dumpsys deviceidle step light. За Deep Doze — adb shell dumpsys deviceidle step deep. Командата adb shell dumpsys deviceidle force-idle deep незабавно превключва устройството в Deep Doze без изчакване на стандартния timeout. След тестване Doze се изключва с командата adb shell dumpsys deviceidle unforce.

# Принудително влизане в Light Doze
$ adb shell dumpsys deviceidle step light

# Принудително влизане в Deep Doze
$ adb shell dumpsys deviceidle step deep

# Незабавно преминаване в Deep Doze
$ adb shell dumpsys deviceidle force-idle deep

# Излизане от Doze
$ adb shell dumpsys deviceidle unforce

# Преглед на статуса на Doze
$ adb shell dumpsys deviceidle

Проверка на работата на приложението

След превключване в Doze Mode трябва да се провери: дали мрежовите заявки работят (трябва да бъдат отложени), дали AlarmManager се задейства, дали FCM съобщенията се доставят, дали задачите на WorkManager се изпълняват коректно. WorkManager в Doze продължава да работи: неговите задачи се изпълняват в прозорците на услугата. Въпреки това, ако задачата изисква незабавно изпълнение, трябва да се посочи setExpedited() или да се използва Foreground Service.

Най-добри практики за Doze Mode

Разработката на приложение, устойчиво на Doze Mode, изисква преосмисляне на подхода към фоновите задачи. Google препоръчва проектиране на приложението така, че да работи коректно при всякакви ограничения на Doze, без да разчита на незабавно изпълнение на фонови операции. Основният принцип — използване на WorkManager за всички фонови задачи, които могат да бъдат отложени.

Използвайте WorkManager

WorkManager е препоръчваният от Google API за фонови задачи, тъй като автоматично се адаптира към Doze. WorkManager използва JobScheduler (API 23+) или AlarmManager + BroadcastReceiver на по-стари версии. Задачите на WorkManager се изпълняват в най-близкия прозорец на услугата на Doze, а при необходимост — незабавно чрез Expedited Work (Foreground Service под капака).

Foreground Service за критични задачи

Ако задачата не може да бъде отложена (възпроизвеждане на медия, навигация, VoIP), използвайте Foreground Service със задължително известие. Foreground Service получава изключение от Doze: може да задържа WakeLock и да изпълнява мрежови заявки. Въпреки това, дори Foreground Service се подчинява на политиката за прозорци на услугата на Deep Doze за някои типове задачи — например dataSync.

FCM high-priority за известия

За доставка на съобщения, изискващи незабавно внимание (входящо повикване, спешно известие), използвайте FCM high-priority съобщения. Такива съобщения събуждат устройството от Doze и дават на приложението кратък прозорец за обработка. Не използвайте high-priority за обикновени известия — това ще доведе до бързо разреждане на батерията и може да бъде разгледано от Google Play като нарушение на политиката.

• WorkManager — предпочитан API за всички отложими фонови задачи
• Foreground Service — за критични задачи с видимо известие
• FCM high-priority — за доставка на спешни съобщения с пробуждане на устройството
• Не искайте Whitelist без крайна необходимост — влошава потребителското изживяване
• Тествайте приложението в Light и Deep Doze чрез ADB преди пускане