Optymalizowanie baterii aplikacji za pomocą wskaźnika blokady uśpienia Android Vitals

Czas pracy na baterii jest kluczowym aspektem wygody użytkownika, a blokady uśpienia odgrywają w tym ważną rolę. Czy używasz ich w nadmiarze? W tym poście na blogu wyjaśnimy, czym są blokady uśpienia, jakie są sprawdzone metody ich używania i jak lepiej zrozumieć zachowanie aplikacji za pomocą wskaźnika w Konsoli Play.

Nadmierne użycie częściowej blokady uśpienia w Android Vitals

Konsola Play monitoruje teraz szybkie zużycie baterii, koncentrując się na nadmiernym użyciu częściowej blokady uśpienia jako kluczowym wskaźniku wydajności.

Ta funkcja zwiększa znaczenie efektywności baterii obok dotychczasowych podstawowych wskaźników stabilności: nadmiernej liczby awarii i błędów ANR. Określiliśmy próg niewłaściwego działania dotyczący nadmiernych blokad uśpienia. Od 1 marca 2026 r. możemy wykluczyć tytuł z widocznych miejsc, takich jak rekomendacje, jeśli nie spełnia on tego progu jakości. W niektórych przypadkach w informacjach o aplikacji możemy wyświetlać ostrzeżenie, aby poinformować użytkowników, że aplikacja może powodować nadmierne zużycie baterii.

Ostrzeżenie o nadmiernych blokadach uśpienia w podsumowaniu Android Vitals.

W przypadku urządzeń mobilnych wskaźnik Android Vitals dotyczy blokad uśpienia, które nie są wyłączone i są uzyskiwane, gdy ekran jest wyłączony, a aplikacja działa w tle lub jako usługa na pierwszym planie. Android Vitals uznaje użycie częściowej blokady uśpienia za nadmierne, jeśli:

• Blokady uśpienia są utrzymywane przez co najmniej 2 godziny w ciągu 24 godzin.
• Wpływa to na ponad 5% sesji aplikacji, uśrednionych w ciągu 28 dni.

Blokady uśpienia utworzone przez interfejsy API zainicjowane przez użytkownika dotyczące dźwięku, lokalizacji i JobScheduler są wyłączone z obliczeń blokad uśpienia.

Blokady uśpienia

Blokada uśpienia to mechanizm, który umożliwia aplikacji utrzymywanie procesora urządzenia w stanie działania, nawet gdy użytkownik nie korzysta z niego aktywnie. 

Częściowa blokada uśpienia utrzymuje procesor w stanie działania, nawet gdy ekran jest wyłączony, uniemożliwiając procesorowi przejście w stan niskiego zużycia energii „zawieszenia”. Pełna blokada uśpienia utrzymuje w stanie działania zarówno ekran, jak i procesor.

Istnieją 2 metody uzyskiwania częściowych blokad uśpienia:

• Aplikacja ręcznie uzyskuje i zwalnia blokadę uśpienia za pomocą interfejsów PowerManager API w określonym przypadku użycia. Często jest ona uzyskiwana w połączeniu z usługą na pierwszym planie – interfejsem API cyklu życia platformy przeznaczonym do działania widocznego dla użytkownika.
• Blokada uśpienia jest też uzyskiwana przez inny interfejs API i przypisywana do aplikacji ze względu na użycie tego interfejsu API. Więcej informacji na ten temat znajdziesz w sekcji dotyczącej sprawdzonych metod.

Blokady uśpienia są niezbędne do wykonywania zadań, takich jak pobieranie dużego pliku zainicjowane przez użytkownika, ale ich nadmierne lub nieprawidłowe użycie może prowadzić do znacznego szybkiego zużycia baterii. Zdarzały się przypadki, w których aplikacje utrzymywały blokady uśpienia przez wiele godzin lub nie zwalniały ich prawidłowo, co powodowało skargi użytkowników na znaczne szybkie zużycie baterii, nawet gdy nie korzystali z aplikacji.

Sprawdzone metody używania blokad uśpienia

Zanim omówimy, jak debugować nadmierne użycie blokad uśpienia, upewnij się, że stosujesz sprawdzone metody dotyczące blokad uśpienia. 

Zastanów się nad tymi 4 kluczowymi pytaniami.

1. Czy rozważasz alternatywne opcje blokad uśpienia?

Zanim zdecydujesz się na ręczne uzyskanie częściowej blokady uśpienia, zapoznaj się z tym schematem blokowym:

Schemat blokowy, który pomaga zdecydować, kiedy ręcznie uzyskać blokadę uśpienia

1. Czy ekran musi pozostać włączony?
   • Tak: zamiast tego zapoznaj się z dokumentacją dotyczącą utrzymywania ekranu włączonego.
2. Czy aplikacja korzysta z usługi na pierwszym planie?
   • Nie: nie musisz ręcznie uzyskiwać blokady uśpienia.
3. Czy zawieszenie urządzenia ma negatywny wpływ na wygodę użytkownika?
   • Nie: np. aktualizowanie powiadomienia po wybudzeniu urządzenia nie wymaga blokady uśpienia.
   • Tak: jeśli konieczne jest uniemożliwienie zawieszenia urządzenia, np. w przypadku ciągłej komunikacji z urządzeniem zewnętrznym, kontynuuj.
4. Czy istnieje już interfejs API, który utrzymuje urządzenie w stanie działania?
   • Aby zidentyfikować sytuacje, w których blokady uśpienia są tworzone przez inne interfejsy API, takie jak LocationManager, możesz skorzystać z dokumentacji Identyfikowanie blokad uśpienia utworzonych przez inne interfejsy API.
   • Jeśli nie ma interfejsów API, przejdź do ostatniego pytania.
5. Jeśli odpowiesz na wszystkie te pytania i stwierdzisz, że nie ma alternatywy, możesz ręcznie uzyskać blokadę uśpienia.

2. Czy prawidłowo nazywasz blokadę uśpienia?

Podczas ręcznego uzyskiwania blokad uśpienia ważne jest, aby prawidłowo je nazywać, co ułatwia debugowanie:

• Nie podawaj w nazwie żadnych informacji umożliwiających identyfikację, takich jak adresy e-mail. Jeśli zostaną wykryte informacje umożliwiające identyfikację, blokada uśpienia zostanie zarejestrowana jako _UNKNOWN, co utrudni debugowanie.
• Nie nazywaj blokady uśpienia programowo za pomocą nazw klas lub metod, ponieważ mogą one zostać zaciemnione przez narzędzia takie jak Proguard. Zamiast tego użyj zakodowanego na stałe ciągu znaków.
• Nie dodawaj liczników ani unikalnych identyfikatorów do tagów blokad uśpienia. Za każdym razem, gdy blokada uśpienia jest uruchamiana, należy używać tego samego tagu, aby system mógł agregować użycie według nazwy, co ułatwia wykrywanie nieprawidłowych zachowań.

3. Czy uzyskana blokada uśpienia jest zawsze zwalniana?

Jeśli ręcznie uzyskujesz blokadę uśpienia, upewnij się, że jej zwolnienie zawsze się wykonuje. Niezwolnienie blokady uśpienia może spowodować szybkie zużycie baterii. 

Jeśli na przykład podczas przetwarzaniaWork() zostanie zgłoszony nieobsłużony wyjątek, wywołanie release() może nigdy nie nastąpić. Zamiast tego możesz użyć bloku try-finally, aby zagwarantować zwolnienie blokady uśpienia, nawet jeśli wystąpi wyjątek.

Możesz też dodać do blokady uśpienia limit czasu, aby mieć pewność, że zostanie ona zwolniona po określonym czasie, co uniemożliwi jej utrzymywanie w nieskończoność.

fun processingWork() {
    wakeLock.apply {
        try {
            acquire(60 * 10 * 1000) // timeout after 10 minutes
            doTheWork()
        } finally {
            release()
        }
    }
}

4. Czy możesz zmniejszyć częstotliwość wybudzania?

W przypadku okresowych żądań danych zmniejszenie częstotliwości wybudzania urządzenia przez aplikację jest kluczem do optymalizacji baterii. Oto kilka przykładów zmniejszenia częstotliwości wybudzania:

• WorkManager: zwiększ okresowy interwał w PeriodicWorkRequests.
• SensorManager: wykorzystaj grupowanie, określając maxReportLatencyMs podczas rejestrowania detektora zdarzeń.
• Dostawca uśrednionej lokalizacji:
  • Zmniejsz częstotliwość pobierania lokalizacji, używając getLastLocation w przypadku najnowszej lokalizacji zapisanej w pamięci podręcznej.
  • Użyj setPriority(PRIORITY_PASSIVE), aby zastosować metodę aktualizacji, która mniej obciąża baterię.
  • Możesz też wykorzystać mechanizm grupowania lokalizacji, ustawiając minimalny interwał aktualizacji za pomocą setMinUpdateIntervalMillis.

Więcej informacji znajdziesz w dokumentacji dotyczącej sprawdzonych metod używania blokad uśpienia.

Debugowanie nadmiernego użycia blokad uśpienia

Nawet przy najlepszych intencjach może dojść do nadmiernego użycia blokad uśpienia. Jeśli Twoja aplikacja zostanie oznaczona w Konsoli Play, możesz ją debugować w ten sposób:

Wstępna identyfikacja w Konsoli Play

Panel Android Vitals dotyczący nadmiernego użycia częściowej blokady uśpienia zawiera podział nazw blokad uśpienia, które nie są wyłączone, powiązanych z Twoją aplikacją, oraz pokazuje sesje i czasy trwania, których to dotyczy. Pamiętaj, aby korzystać z dokumentacji, która pomoże Ci określić, czy blokada uśpienia jest utrzymywana przez aplikację, czy przez inny interfejs API.

Panel Android Vitals dotyczący nadmiernego użycia częściowej blokady uśpienia przewinięty w dół do sekcji podziałów, aby wyświetlić tagi nadmiernych blokad uśpienia.

Debugowanie nadmiernych blokad uśpienia utrzymywanych przez klasy worker lub zadania

Blokady uśpienia utrzymywane przez klasy worker możesz zidentyfikować za pomocą tej nazwy blokady uśpienia:

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

Pełna lista wariantów nazw blokad uśpienia utrzymywanych przez klasy worker jest dostępna w dokumentacji. Aby debugować te blokady uśpienia, możesz użyć narzędzia Background Task Inspector do debugowania lokalnie lub skorzystać z getStopReason do debugowania problemów w terenie. 

Narzędzie do sprawdzania zadań w tle w Android Studio

Zrzut ekranu narzędzia Background Task Inspector, w którym udało się zidentyfikować klasę worker „WeatherSyncWorker”, która często ponawiała próbę i nie powiodła się.

Aby lokalnie debugować problemy z WorkManager, użyj tego narzędzia na emulatorze lub podłączonym urządzeniu (poziom API 26 lub nowszy). Wyświetla ono listę klas worker i ich stanów (zakończone, wykonywane, w kolejce), co umożliwia sprawdzanie szczegółów i zrozumienie łańcuchów klas worker. 

Może na przykład ujawnić, czy klasa worker często kończy się niepowodzeniem lub ponawia próbę z powodu ograniczeń systemu. 

Więcej informacji znajdziesz w dokumentacji narzędzia do sprawdzania zadań w tle.

WorkManager getStopReason

Aby debugować w terenie klasy worker z nadmiernymi blokadami uśpienia, użyj WorkInfo.getStopReason() w WorkManager 2.9.0 lub nowszym albo JobParameters.getStopReason() w JobScheduler dostępnym w pakiecie SDK 31 lub nowszym. 

Ten interfejs API pomaga rejestrować przyczynę zatrzymania klasy worker (np. STOP_REASON_TIMEOUT, STOP_REASON_QUOTA), co pozwala wykrywać problemy takie jak częste przekroczenia limitu czasu z powodu wyczerpania czasu działania.

backgroundScope.launch {
    WorkManager.getInstance(context)
        .getWorkInfoByIdFlow(workRequest.id)
        .collect { workInfo ->
            logStopReason(workRequest.id, workInfo?.stopReason)
        }
}

Więcej informacji znajdziesz w artykule Optymalizowanie wykorzystania baterii w przypadku interfejsów API do planowania zadań.

Debugowanie innych typów nadmiernych blokad uśpienia

W bardziej złożonych scenariuszach, w których blokady uśpienia są utrzymywane ręcznie lub przez interfejsy API, do debugowania zalecamy użycie zbierania danych o systemie.

Zbieranie danych o systemie

Dane o systemie to zaawansowane narzędzie do debugowania, które rejestruje szczegółowe informacje o aktywności systemu w danym okresie, co pozwala uzyskać wgląd w stan procesora, aktywność wątków, aktywność sieci i dane związane z baterią, takie jak czas trwania zadania i użycie blokady uśpienia.

Dane o systemie możesz zbierać na kilka sposobów: 

• Za pomocą narzędzia wiersza poleceń do zbierania danych o systemie .
• Za pomocą profilera procesora w Android Studio
• Za pomocą Perfetto UI.
• Ręcznie rejestrując dane bezpośrednio na urządzeniu w opcjach programisty. 

Włącz kategorię Atrace „power:PowerManagement” w Perfetto UI na karcie Aplikacje i usługi Androida. 

Niezależnie od wybranej metody musisz zbierać dane z kategorii Atrace „power:PowerManagement”, aby móc wyświetlać ślady stanu urządzenia. 

Sprawdzanie w Perfetto UI i analiza SQL

Dane o systemie można otwierać i sprawdzać w Perfetto UI. Po otwarciu danych zobaczysz wizualizację różnych procesów na osi czasu. W tym przewodniku skupimy się na śladach w sekcji „Stan urządzenia”.

Przypnij ślady w sekcji „Stan urządzenia”, takie jak „Najpopularniejsza aplikacja”, „Stan ekranu”, „Długie blokady uśpienia” i „Zadania”, aby wizualnie zidentyfikować długotrwałe fragmenty blokad uśpienia.

Każdy blok zawiera nazwę zdarzenia, czas jego rozpoczęcia i zakończenia. W Perfetto nazywa się to fragmentem.

Aby przeprowadzić skalowalną analizę wielu danych, możesz użyć analizy SQL w Perfetto. Zapytanie SQL może znaleźć wszystkie blokady uśpienia posortowane według czasu trwania, co ułatwia identyfikację głównych przyczyn nadmiernego użycia.

Oto przykładowe zapytanie sumujące wszystkie tagi blokad uśpienia, które wystąpiły w danych o systemie, posortowane według łącznego czasu trwania:

SELECT slice.name as name, track.name as track_name,SUM(dur / 100000) as total_dur_ms
FROM slice
JOIN track ON slice.track_id = track.id
WHERE track.name = 'WakeLocks'GROUP BY slice.name, track.name
ORDER BY total_dur_ms DESC

Używanie ProfilingManager do zbierania danych w terenie

W przypadku problemów, które trudno odtworzyć, ProfilingManager (dodany w pakiecie SDK 35) to programowy interfejs API, który umożliwia deweloperom zbieranie danych o systemie w terenie za pomocą wyzwalaczy rozpoczęcia i zakończenia. Zapewnia większą kontrolę nad punktami wyzwalania rozpoczęcia i zakończenia zbierania danych oraz wymusza ograniczanie szybkości na poziomie systemu, aby zapobiec negatywnemu wpływowi na wydajność urządzenia. 

Więcej informacji o tym, jak wdrożyć zbieranie danych o systemie w terenie, w tym o tym, jak programowo rejestrować dane, analizować dane profilowania i używać lokalnych poleceń debugowania, znajdziesz w dokumentacji ProfilingManager.

Dane o systemie zebrane za pomocą ProfilingManager będą podobne do tych zebranych ręcznie, ale procesy systemowe i inne procesy aplikacji zostaną z nich usunięte.

Podsumowanie

Wskaźnik nadmiernego użycia częściowej blokady uśpienia w Android Vitals to tylko niewielka część naszego ciągłego zaangażowania w pomoc deweloperom w zmniejszaniu szybkiego zużycia baterii i poprawianiu jakości aplikacji. 

Dzięki zrozumieniu i prawidłowemu wdrożeniu blokad uśpienia możesz znacząco zoptymalizować wydajność baterii aplikacji. Korzystanie z alternatywnych interfejsów API, przestrzeganie sprawdzonych metod dotyczących blokad uśpienia oraz używanie zaawansowanych narzędzi do debugowania, takich jak Background Task Inspector, dane o systemie i ProfilingManager, to klucz do sukcesu aplikacji w Google Play.