Określanie i optymalizowanie przypadków użycia blokady wybudzania

Ten dokument pomoże Ci zidentyfikować i zoptymalizować przypadki użycia blokad uśpienia w aplikacji oraz sprawdzić, czy inne biblioteki lub interfejsy API systemu powiązane z tym przypadkiem użycia uzyskują blokady uśpienia. Ponieważ te blokady uśpienia można przypisać do Twojej aplikacji, ustalenie źródła problematycznej blokady uśpienia może być trudne. Nieprawidłowe użycie interfejsu API może spowodować oznaczenie aplikacji jako nadmiernie korzystającej z blokad uśpienia, nawet jeśli nie uzyskujesz ich bezpośrednio.

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 lub w raportach z danych o kondycji. Te nazwy mogą pochodzić z biblioteki lub interfejsu API systemu albo mogą być zaciemnione. 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 znaleźć rekomendacje dotyczące optymalizacji jego użycia.

W tym dokumencie opisujemy typowe przypadki użycia blokad uśpienia, podając nazwy blokad uśpienia używane przez różne interfejsy API i biblioteki, oraz rekomendacje i sprawdzone metody optymalizacji i zmniejszenia wykorzystania blokad uśpienia.

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:

  • Zapoznaj się z artykułem Wybieranie typu alarmu, aby zdecydować, czy użyć alarmu niedokładnego czy alarmu precyzyjnego. Jeśli alarm nie musi być dokładny, użyj alarmów niedokładnych, aby dać systemowi większą elastyczność w planowaniu, co może wydłużyć czas pracy baterii.
  • Pamiętaj o limitach alarmów narzuconych przez system i zaprojektuj swoją aplikację tak, aby ich przestrzegała.
  • Unikaj wykonywania długotrwałych zadań w metodzie onReceive() i planuj klasy worker, jeśli po alarmie wymagane jest dodatkowe przetwarzanie.

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 bezstratnego odtwarzania dźwięku przez USB.
  • AudioDirectOut: służy do bezstratnego odtwarzania dźwięku 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 zwykłym 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 filmów lub muzyki na urządzeniach, które obsługują dźwięk przestrzenny.
  • AudioUnknown: używana, gdy inne sytuacje nie mają zastosowania.
  • MmapCapture: służy do nagrywania dźwięku z niskim opóźnieniem.
  • 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 deklaruj 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 i powiązane usługi na pierwszym planie, jeśli nie są już potrzebne.

Bluetooth

Interfejsy API Bluetooth platformy głównie utrzymują blokady uśpienia jądra podczas wykonywania działań Bluetooth, które nie są przypisywane do aplikacji.

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 opóźniona komunikacja nie ma wpływu na użytkownika, często wystarczy użyć WorkManager. Jeśli ręczne blokowanie uśpienia jest konieczne, utrzymuj blokadę uśpienia tylko na czas działania Bluetootha lub przetwarzania danych o aktywności.

Czujniki urządzenia

Istnieje kilka metod śledzenia danych z czujników urządzenia, takich jak liczba kroków, dane z akcelerometru lub żyroskopu.

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ć wykorzystanie baterii.
  • Podczas rejestrowania czujnika za pomocą SensorManager zdefiniuj 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. Gdy urządzenie zostanie później wybudzone przez inny wyzwalacz, np. interakcję użytkownika, pobranie lokalizacji lub zaplanowane zadanie, system natychmiast wyśle dane z czujników zapisane w pamięci podręcznej.
  • Jeśli aplikacja wymaga danych o lokalizacji i danych z czujników, zsynchronizuj pobieranie i przetwarzanie zdarzeń. Łącząc odczyty z czujników z krótką blokadą uśpienia, którą system utrzymuje na potrzeby aktualizacji lokalizacji, unikasz konieczności używania blokady uśpienia, aby utrzymać aktywność procesora. Do obsługi przesyłania i przetwarzania tych połączonych danych użyj klasy worker lub krótkotrwałej blokady uśpienia.

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

Gdy urządzenie odbierze wiadomość FCM, utrzymywana jest krótka blokada uśpienia o nazwie GOOGLE_C2DM. W Androidzie 16 lub nowszym nazwa blokady uśpienia to GCM_MESSAGE.

Rekomendacja

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

  • Optymalizowanie częstotliwości dostarczania wiadomości FCM.
  • Nie używaj FCM o wysokim priorytecie, chyba że wiadomość rzeczywiście musi zostać dostarczona natychmiast.
  • Jak najszybciej wykonaj metodę onMessageReceived() lub zaplanuj klasę worker, aby kontynuować zadanie, jeśli wymagane jest dodatkowe przetwarzanie. Więcej informacji znajdziesz w wytycznych dotyczących Firebase.

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 wersje

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

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

Inne zadania używają tego wzorca:

*job*/@<name_space>@/<package_name>/<classname>
Android 16 QPR2 i nowsze wersje

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 używają tego wzorca:

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

Zwykłe zadania używają 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 QPR2 lub nowszym blokada uśpienia będzie się nazywać:

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

Rekomendacja

  • Nie uzyskuj ręcznej blokady uśpienia w przypadku pobierania lub przesyłania danych zainicjowanego przez użytkownika. Zamiast tego użyj interfejsu User-Initiated Data Transfer (UIDT) API. Jest to wyznaczona ścieżka dla długotrwałych zadań przesyłania danych zainicjowanych przez użytkownika.
  • Jeśli zidentyfikujesz blokady uśpienia utworzone przez JobScheduler, które powodują wysokie zużycie blokad uśpienia, może to być spowodowane nieprawidłową konfiguracją zadania, które nie może zostać ukończone w niektórych scenariuszach. Rozważ przeanalizowanie przyczyn zatrzymania zadania, zwłaszcza jeśli często występuje STOP_REASON_TIMEOUT.
  • Sprawdź wykorzystanie zadań JobScheduler. W szczególności postępuj zgodnie z naszymi wskazówkami dotyczącymi optymalizacji wykorzystania 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 używają tych nazw:

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

Rekomendacja

  • Zapoznaj się z naszymi wskazówkami dotyczącymi optymalizacji wykorzystania lokalizacji. Rozważ wdrożenie limitów czasu, wykorzystanie grupowania żądań lokalizacji lub korzystanie z pasywnych aktualizacji lokalizacji.
  • Unikaj uzyskiwania oddzielnej, ciągłej blokady uśpienia na potrzeby buforowania danych o lokalizacji, ponieważ jest to zbędne i należy ją usunąć. Gdy żądasz aktualizacji lokalizacji za pomocą interfejsów API FusedLocationProvider lub LocationManager, system automatycznie wybudza urządzenie podczas wywołania zwrotnego zdarzenia lokalizacji. Zamiast tego przechowuj zdarzenia lokalizacji w pamięci lub pamięci masowej, i przetwarzaj je okresowo za pomocą WorkManager.

Zdalne przesyłanie wiadomości

W tej sekcji omawiamy scenariusze związane ze zdalnym przesyłaniem wiadomości, w których aplikacje mogą potrzebować utrzymywać połączenia lub reagować na zdarzenia z innych urządzeń, co może mieć wpływ na wykorzystanie blokad uśpienia. Typowe przypadki użycia:

  • Aplikacje towarzyszące do monitorowania obrazu lub dźwięku, które muszą monitorować zdarzenia występujące na urządzeniu zewnętrznym połączonym przez sieć lokalną.
  • Aplikacje do obsługi wiadomości, które utrzymują połączenie gniazda sieciowego z wersją na komputery.

Większość wybudzeń w tych scenariuszach zdalnego przesyłania wiadomości to blokady uśpienia jądra. Ponieważ blokady uśpienia jądra nie są przypisywane do aplikacji, nie ma tu powiązanych nazw blokad uśpienia.

Rekomendacja

  • Jeśli zdarzenia sieciowe można przetwarzać po stronie serwera, użyj FCM, aby otrzymywać informacje na kliencie. Jeśli wymagane jest dodatkowe przetwarzanie danych FCM, możesz zaplanować priorytetową klasę worker.
  • Jeśli zdarzenia muszą być przetwarzane po stronie klienta za pomocą połączenia gniazda, blokada uśpienia nie jest potrzebna do nasłuchiwania przerwań zdarzeń. Gdy pakiety danych docierają do radia Wi-Fi lub komórkowego, sprzęt radiowy wywołuje przerwanie w postaci blokady uśpienia jądra. Możesz wtedy zaplanować klasę worker lub uzyskać blokadę uśpienia, aby przetworzyć dane.
  • Jeśli na przykład używasz ktor-network do nasłuchiwania pakietów danych w gnieździe sieciowym, blokadę uśpienia należy uzyskać tylko wtedy, gdy pakiety zostały dostarczone do klienta.

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 wersje

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

*job*/<package_name>/androidx.work.impl.background.systemjob.SystemJobService
Android 16 QPR2 i nowsze wersje

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 używają tego wzorca:

*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 QPR2 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

  • Uaktualnij wersję WorkManagera do najnowszej stabilnej wersji, aby tagi blokady uśpienia były bardziej szczegółowe na Androidzie 16 QPR2 lub nowszym.
  • Sprawdź wykorzystanie workerów WorkManagera. W szczególności sprawdź, czy jest ono zgodne z naszymi wskazówkami dotyczącymi optymalizacji wykorzystania baterii w przypadku interfejsów API do planowania zadań. Aby tagi blokady uśpienia były bardziej szczegółowe na Androidzie 16 QPR2 lub nowszym, użyj metody setTraceTag w klasie worker, aby dodać więcej informacji do debugowania , np. która klasa zaplanowała workera.
  • Jeśli zidentyfikujesz blokady uśpienia utworzone przez WorkManagera, które powodują wysokie zużycie blokad uśpienia, może to być spowodowane nieprawidłową konfiguracją workera, który nie może zostać ukończony w niektórych scenariuszach. Rozważ przeanalizowanie przyczyn zatrzymania workera, zwłaszcza jeśli często występuje dużo przypadków STOP_REASON_TIMEOUT.
  • Oprócz rejestrowania przyczyn zatrzymania workera, zapoznaj się z naszą dokumentacją dotyczącą debugowania workerów. Rozważ też zbieranie i analizowanie śladów systemowych, aby dowiedzieć się, kiedy blokady uśpienia są uzyskiwane i zwalniane.

_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ę.