Czas pracy na baterii jest kluczowym aspektem wygody użytkowników, 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ęściowych blokad uśpienia w Android Vitals

Konsola Play monitoruje teraz szybkie zużycie baterii, a jako kluczowy wskaźnik wydajności traktuje nadmierne użycie częściowych blokad uśpienia.

Ta funkcja zwiększa znaczenie efektywności baterii obok dotychczasowych wskaźników stabilności podstawowych wskaźników: nadmiernej liczby awarii widocznych dla użytkowników 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. jeśli tytuł nie będzie spełniać tego progu jakości, możemy wykluczyć go z widocznych powierzchni, takich jak rekomendacje. 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 (działająca) na pierwszym planie. Android Vitals uznaje użycie częściowych blokad 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, takie jak audio, lokalizacja 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, co uniemożliwia procesorowi przejście w stan „zawieszenia” o niskim zużyciu energii. Pełna blokada uśpienia utrzymuje w stanie działania zarówno ekran, jak i procesor.

Istnieją 2 sposoby 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 to uzyskiwane 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 uzyskiwana przez inny interfejs API i przypisywana do aplikacji ze względu na użycie interfejsu API. Więcej informacji na ten temat znajdziesz w sekcji Sprawdzone metody.

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 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 prowadziło do skarg użytkowników na 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 używania blokad uśpienia. 

Zastanów się nad tymi 4 kluczowymi pytaniami.

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

Zanim rozważysz 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żytkowników?
   • Nie: na przykład 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ć scenariusze, 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?

W przypadku ręcznego uzyskiwania blokad uśpienia prawidłowe nazewnictwo jest ważne do debugowania:

• W nazwie nie umieszczaj żadnych informacji umożliwiających identyfikację (PII), takich jak adresy e-mail. Jeśli zostaną wykryte informacje PII, 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 kluczem do optymalizacji baterii jest zmniejszenie częstotliwości wybudzania urządzenia przez aplikację. 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ń.
• Fused Location Provider:
  • Zmniejsz częstotliwość pobierania lokalizacji, używając getLastLocation w przypadku najnowszej lokalizacji zapisanej w pamięci podręcznej.
  • Użyj setPriority(PRIORITY_PASSIVE) w przypadku metody aktualizacji, która zużywa mniej baterii.
  • 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ęściowych blokad 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ęściowych blokad 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ę.

Do lokalnego debugowania problemów 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

Do debugowania w terenie klas worker z nadmiernymi blokadami uśpienia użyj WorkInfo.getStopReason() w WorkManager 2.9.0 lub nowszym albo w JobScheduler JobParameters.getStopReason() 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 obejmujących ręcznie utrzymywane blokady uśpienia lub interfejsy API utrzymujące blokadę uśpienia zalecamy użycie zbierania danych na temat wydajności w całym systemie do debugowania.

Zbieranie danych na temat wydajności w całym systemie

Dane na temat wydajności w całym 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 na temat wydajności w całym systemie możesz rejestrować na kilka sposobów: 

• Za pomocą narzędzia wiersza poleceń do zbierania danych na temat wydajności w całym systemie.
• Za pomocą profilera procesora w Android Studio
• Za pomocą Perfetto UI.
• Ręcznie rejestrując dane na urządzeniu bezpośrednio z opcji programisty. 

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

Niezależnie od wybranej metody musisz mieć pewność, że zbierasz dane z kategorii „power:PowerManagement” Atrace , aby móc wyświetlać ścieżki stanu urządzenia. 

Sprawdzanie w Perfetto UI i analiza SQL

Dane na temat wydajności w całym 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 ścieżkach w sekcji „Stan urządzenia”.

Przypnij ścieżki 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.

Do skalowalnej analizy 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 pomaga zidentyfikować główne przyczyny nadmiernego użycia.

Oto przykładowe zapytanie sumujące wszystkie tagi blokad uśpienia, które wystąpiły w danych na temat wydajności w całym 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 na temat wydajności w całym 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 profilu oraz wymusza ograniczanie liczby żądań na poziomie systemu, aby zapobiec negatywnemu wpływowi na wydajność urządzenia. 

Więcej informacji o tym, jak wdrożyć zbieranie danych na temat wydajności w całym 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 na temat wydajności w całym 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ęściowych blokad 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łowej implementacji blokad uśpienia możesz znacznie zoptymalizować wydajność baterii aplikacji. Wykorzystanie alternatywnych interfejsów API, przestrzeganie sprawdzonych metod używania blokad uśpienia oraz korzystanie z zaawansowanych narzędzi do debugowania, takich jak Background Task Inspector, śledzenie systemu i ProfilingManager, są kluczowe dla sukcesu aplikacji w Google Play.