identyfikować blokady aktywacji utworzone przez inne interfejsy API;

Wiele bibliotek i interfejsów API systemu może uzyskiwać blokady uśpienia, które można przypisać do Twojej aplikacji. Może to utrudniać identyfikację tej blokady uśpienia w aplikacji, która może być źródłem problemu. Jeśli nieprawidłowo używasz interfejsu API, może to spowodować, że aplikacja będzie zbyt długo utrzymywać blokadę uśpienia, nawet jeśli nie wywołujesz bezpośrednio interfejsów API blokady uśpienia.

Jeśli blokada uśpienia jest uzyskiwana przez inne interfejsy API, unikaj ręcznego uzyskiwania blokady uśpienia.

W tym dokumencie znajdziesz listę typowych nazw blokad uśpienia, które możesz zobaczyć podczas korzystania z narzędzi do debugowania blokad uśpienia. Możesz też zobaczyć te nazwy w raporcie z Vitals. Zdarza się, że blokada uśpienia została utworzona przez bibliotekę lub interfejs API systemu. W innych przypadkach narzędzie z jakiegoś powodu zaciemnia nazwę blokady uśpienia używaną w aplikacji. Za pomocą narzędzi do debugowania możesz zidentyfikować nieprawidłowo działające blokady uśpienia, a następnie wyszukać nazwę blokady uśpienia w tym dokumencie, aby dowiedzieć się, który interfejs API może powodować problem i jak go rozwiązać.

W tym dokumencie opisujemy scenariusze, w których mogą być tworzone blokady uśpienia. W każdym przypadku blokada uśpienia może zostać utworzona przez inną bibliotekę lub interfejs API, ale jest przypisywana do aplikacji, która wywołała ten interfejs API. Na tej stronie opisujemy też niektóre interfejsy API, które nie tworzą blokad uśpienia w sytuacjach, w których można by się tego spodziewać.

AlarmManager

AlarmManager uzyskuje blokady uśpienia i przypisuje je do aplikacji wywołującej. AlarmManager uzyskuje blokadę uśpienia, gdy włączy się alarm, i zwalnia ją, gdy metoda onReceive() transmisji alarmu zakończy działanie.

Nazwy blokad uśpienia

AlarmManager tworzy blokady uśpienia o nazwie *alarm*. (Gwiazdki są częścią nazwy blokady uśpienia, nie są symbolami wieloznacznymi).

Rekomendacja

Aby zoptymalizować działanie alarmu, zalecamy stosowanie tych sprawdzonych metod:

  • Użyj AlarmManager, aby zoptymalizować częstotliwość planowania alarmów.
  • Używaj alarmów typu RTC_WAKEUP (które wybudzają urządzenie) tylko wtedy, gdy jest to konieczne.
  • Ogranicz używanie alarmów i unikaj długotrwałej pracy w metodzie onReceive().

Dźwięk i multimedia

Interfejsy API multimediów mogą uzyskiwać blokady uśpienia podczas nagrywania lub odtwarzania dźwięku. Blokady uśpienia są przypisywane do aplikacji wywołującej.

Nazwy blokad uśpienia

Interfejsy API multimediów uzyskują blokady uśpienia o różnych nazwach, które zaczynają się od Audio:

  • AudioBitPerfect: służy do odtwarzania dźwięku przez USB bez utraty jakości.
  • AudioDirectOut: służy do odtwarzania dźwięku bez utraty jakości na telewizorze lub specjalnym urządzeniu.
  • AudioDup: służy do odtwarzania powiadomień podczas połączenia przez Bluetooth lub USB.
  • AudioIn: służy do nagrywania dźwięku w trybie kamery, gdy mikrofon jest aktywny.
  • AudioMix: służy do odtwarzania dźwięku na wspólnym urządzeniu.
  • AudioOffload: służy do długotrwałego odtwarzania tylko muzyki w aplikacjach, które obsługują ten tryb.
  • AudioSpatial: służy do odtwarzania wielokanałowego dźwięku z filmów lub muzyki na urządzeniach obsługujących dźwięk przestrzenny.
  • AudioUnknown: używany, gdy inne sytuacje nie mają zastosowania.
  • MmapCapture: służy do rejestrowania dźwięku z niskimi opóźnieniami.
  • MmapPlayback: służy do odtwarzania z niskim opóźnieniem, np. w przypadku gier lub profesjonalnych aplikacji audio.

Rekomendacja

Zalecamy stosowanie tych sprawdzonych metod:

  • Nie używaj nazw blokad uśpienia, które zaczynają się od Audio.
  • Jeśli korzystasz z interfejsów API multimediów, nie musisz bezpośrednio uzyskiwać blokad uśpienia. Możesz polegać na interfejsach API, które uzyskają niezbędne blokady.
  • Gdy korzystasz z interfejsów Media API, kończ sesje multimedialne, jeśli nie są już potrzebne.

Bluetooth

Interfejsy API Bluetooth platformy nie mają żadnych blokad uśpienia przypisanych do aplikacji podczas wykonywania działań Bluetooth. Aby sprawdzić, czy przesyłanie danych przez Bluetooth odbywa się w tle, zaplanuj zadanie za pomocą biblioteki WorkManager.

Rekomendacja

  • Użyj parowania urządzenia towarzyszącego, aby sparować urządzenia Bluetooth i uniknąć ręcznego blokowania uśpienia podczas parowania Bluetooth.
  • Zapoznaj się ze wskazówkami dotyczącymi komunikacji w tle, aby dowiedzieć się, jak prowadzić komunikację Bluetooth w tle.
  • Jeśli ręczne blokowanie uśpienia jest konieczne, utrzymuj blokadę uśpienia tylko na czas działania Bluetootha.

Czujniki urządzenia

Dane z czujników urządzenia, takie jak liczba kroków, dane z akcelerometru lub żyroskopu, można śledzić na kilka sposobów.

W Wear OS używaj funkcji dotyczących zdrowia w systemie Wear OS, aby pobierać z urządzenia dane takie, jak wysokość nad poziomem morza, tętno i przebyta odległość.

Jeśli dane są zbierane przez inne aplikacje, możesz używać Health Connect w połączeniu z biblioteką WorkManager, aby okresowo pobierać dane.

W scenariuszach takich jak śledzenie różnicy w liczbie kroków lub przebytej odległości możesz używać interfejsu Recording API na urządzeniach mobilnych w połączeniu z biblioteką WorkManager, aby okresowo pobierać dane. Aby uzyskać dostęp do historycznych danych o krokach (np. dziennej liczby kroków lub liczby kroków w ciągu ostatnich 6 godzin), Health Connect obsługuje też śledzenie liczby kroków na urządzeniu w przypadku urządzeń z Androidem 14 lub nowszym.

W niektórych sytuacjach może być potrzebne śledzenie danych z czujników urządzenia za pomocą funkcji SensorManager. SensorManager nie uzyskuje blokad uśpienia w imieniu aplikacji, chyba że czujnik jest czujnikiem wybudzania, który można zidentyfikować za pomocą interfejsu isWakeUpSensor API.

Rekomendacja

Korzystanie z czujników do rejestrowania danych z wysoką częstotliwością próbkowania może znacznie wyczerpywać baterię. Oto rekomendacje, które pomogą zmniejszyć zużycie baterii i wykorzystanie blokady uśpienia:

  • Jeśli śledzisz liczbę kroków lub przebytą odległość, użyj interfejsu Recording API, aby rejestrować dane w sposób oszczędzający baterię. W przypadku urządzeń z Androidem 14 lub nowszym rozważ użycie Health Connect, aby uzyskać dostęp do danych historycznych urządzenia i zagregowanej liczby kroków.
  • W przypadku pasywnego śledzenia danych z czujników Wear OS używaj funkcji dotyczących zdrowia w Wear OS, aby zoptymalizować zużycie baterii.
  • Zmniejsz częstotliwość czujnika do poniżej 200 Hz.
  • Podczas rejestrowania czujnika za pomocą SensorManager zdefiniuj parametr maxReportLatencyUs na wartość większą niż 30 sekund, aby używać logiki grupowania danych z czujników i zmniejszyć liczbę przerwań, które otrzymuje aplikacja.
  • Unikaj utrzymywania długotrwałej blokady uśpienia przez cały czas śledzenia danych z czujnika. Zamiast tego planuj alarmy za pomocą usługi AlarmManager, aby co 30 lub więcej sekund sprawdzać dane z czujnika.

Komunikacja w chmurze Firebase (FCM)

Blokada uśpienia jest uzyskiwana podczas dostarczania do aplikacji komunikatu z Komunikacji w chmurze Firebase (FCM). Blokada uśpienia jest zwalniana po zakończeniu wykonywania metody onMessageReceived() komunikatu FCM.

Nazwy blokad uśpienia

Blokada uśpienia jest uzyskiwana pod nazwą GOOGLE_C2DM.

Rekomendacja

Aby zoptymalizować działanie FCM, zalecamy stosowanie tych praktyk:

JobScheduler

Zadania JobScheduler uzyskują blokady uśpienia podczas wykonywania zadań w tle. Blokady uśpienia są przypisywane do aplikacji, która utworzyła klasy worker.

Nazwy blokad uśpienia

Nazwy blokad uśpienia uzyskanych przez JobScheduler zależą od wersji systemu Android, na której są uruchamiane, oraz od celu zadania.

Elementy w nawiasach trójkątnych to zmienne. Na przykład „<package_name>” to nazwa pakietu aplikacji, a nie tekst <package name>. Jednak *job* to ciąg znaków *job* z gwiazdkami, które nie są używane jako symbole wieloznaczne.

Android 15 i starsze

Zadania zainicjowane przez użytkownika tworzą blokady uśpienia o nazwach zgodnych z tym wzorcem:

*job*u/@<name_space>@/<package_name>/<classname>

Inne zadania korzystające z tego wzorca:

*job*/@<name_space>@/<package_name>/<classname>
Android 16 lub nowszy

Zadania zainicjowane przez użytkownika tworzą blokady uśpienia o nazwach zgodnych z tym wzorcem:

*job*u/@<name_space>@/#<trace_tag>#/<package_name>/<classname>

Zadania priorytetowe korzystają z tego wzorca:

*job*e/@<name_space>@/#<trace_tag>#/<package_name>/<classname>

Zwykłe zadania korzystają z tego wzorca:

*job*r/@<name_space>@/#<trace_tag>#/<package_name>/<classname>
Przykład

Załóżmy, że istnieje zadanie priorytetowe z przestrzenią nazw backup i tagiem śledzenia started. Nazwa pakietu to com.example.app, a klasa, która utworzyła zadanie, to com.backup.BackupFileService.

Na urządzeniach z Androidem 15 lub starszym blokada uśpienia będzie się nazywać:

*job*/@backup@/com.example.app/com.backup.BackupFileService

Na urządzeniach z Androidem 16 lub nowszym blokada uśpienia będzie się nazywać:

*job*e/@backup@/#started#/com.example.app/com.backup.BackupFileService

Rekomendacja

Sprawdź, jak używasz zadań JobScheduler. W szczególności postępuj zgodnie z naszymi wskazówkami dotyczącymi optymalizacji zużycia baterii w przypadku interfejsów API do planowania zadań.

Lokalizacja

LocationManager i FusedLocationProviderClient używają blokad uśpienia, aby uzyskiwać i przekazywać lokalizację urządzenia. Blokady uśpienia są przypisywane do aplikacji, która wywołała te interfejsy API.

Nazwy blokad uśpienia

Usługi lokalizacyjne mają te nazwy:

  • CollectionLib-SigCollector
  • NetworkLocationLocator
  • NetworkLocationScanner
  • NlpCollectorWakeLock
  • NlpWakeLock
  • *location*

Rekomendacja

  • Optymalizacja wykorzystania lokalizacji Możesz na przykład ustawić limity czasu, grupować żądania lokalizacji lub korzystać z pasywnych aktualizacji lokalizacji.
  • Jeśli używasz interfejsów API lokalizacji, nie musisz bezpośrednio uzyskiwać blokad uśpienia. Możesz polegać na interfejsach API, które uzyskają niezbędne blokady.

WorkManager

Klasy worker biblioteki WorkManager uzyskują blokady uśpienia podczas wykonywania zadań w tle. Blokady uśpienia są przypisywane do aplikacji, która utworzyła klasy worker.

Nazwy blokad uśpienia

Nazwy blokad uśpienia uzyskanych przez bibliotekę WorkManager zależą od wersji systemu Android, na której działają.

Android 15 i starsze

Zadania WorkManagera tworzą blokady uśpienia o nazwach zgodnych z tym wzorcem:

*job*/<package_name>/androidx.work.impl.background.systemjob.SystemJobService
Android 16 lub nowszy

Zadania priorytetowe tworzą blokady uśpienia o nazwach zgodnych z tym wzorcem:

*job*e/#<trace_tag>#/<package_name>/androidx.work.impl.background.systemjob.SystemJobService

Zwykłe zadania są zgodne z tym wzorcem:

*job*r/#<trace_tag>#/<package_name>/androidx.work.impl.background.systemjob.SystemJobService

Domyślnie nazwa workera to <trace_tag>.

Przykład

Załóżmy, że istnieje priorytetowy worker o nazwie BackupFileWorker. Nazwa pakietu to com.example.app.

Na urządzeniach z Androidem 15 lub starszym blokada uśpienia będzie się nazywać:

*job*/com.example.app/androidx.work.impl.background.systemjob.SystemJobService

Na urządzeniach z Androidem 16 lub nowszym, które korzystają z WorkManager 2.10.0+, blokada uśpienia będzie się nazywać:

*job*e/#BackupFileWorker#/com.example.app/androidx.work.impl.background.systemjob.SystemJobService

Rekomendacja

_UNKNOWN

Jeśli narzędzia do debugowania uznają, że nazwa blokady uśpienia zawiera informacje umożliwiające identyfikację, nie wyświetlają jej. Zamiast tego oznaczają blokadę uśpienia jako _UNKNOWN. Narzędzia mogą to robić na przykład, jeśli nazwa blokady uśpienia zawiera adres e-mail.

Rekomendacja

Stosuj sprawdzone metody nazewnictwa blokad uśpienia i unikaj używania w nazwach blokad informacji umożliwiających identyfikację. Jeśli znajdziesz blokadę uśpienia o nazwie _UNKNOWN przypisaną do Twojej aplikacji, spróbuj ustalić, która to blokada, i nadaj jej inną nazwę.