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, koncentrując się na nadmiernym użyciu częściowych blokad uśpienia jako kluczowym wskaźniku wydajności.

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 miejsc docelowych, 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ą objęte zwolnieniem i zostały uzyskane, gdy ekran jest wyłączony, a aplikacja działa w tle lub jako usługa 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;
• ma to wpływ 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 wchodzi z nim w interakcję. 

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 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 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żych plików zainicjowane przez użytkownika, ale ich nadmierne lub nieprawidłowe użycie może spowodować znaczne szybkie zużycie 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 używania 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:

Schemat decydowania, 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 ważne jest, aby uniemożliwić zawieszenie 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 żadnych 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 ważne jest prawidłowe nazewnictwo, które ułatwia debugowanie:

• W nazwie nie umieszczaj żadnych informacji umożliwiających identyfikację (PII), 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 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 w pamięci podręcznej.
  • Użyj setPriority(PRIORITY_PASSIVE), aby zastosować metodę 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 i są powiązane 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 nazwa blokady 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 procesy robocze lub zadania

Blokady uśpienia utrzymywane przez procesy robocze 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 procesy robocze 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, aby debugować problemy w terenie. 

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

Zrzut ekranu narzędzia Background Task Inspector, w którym udało się zidentyfikować proces roboczy „WeatherSyncWorker”, który często ponawiał próbę i nie powiódł 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ę procesów roboczych i ich stanów (zakończony, wykonywany, w kolejce), co umożliwia sprawdzanie szczegółów i zrozumienie łańcuchów procesów roboczych. 

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

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

WorkManager getStopReason

Aby debugować w terenie procesy robocze 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 procesu roboczego (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 przypadku bardziej złożonych scenariuszy obejmujących ręcznie utrzymywane blokady uśpienia lub interfejsy API utrzymujące blokadę uśpienia zalecamy debugowanie za pomocą 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 wskaźniki 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ą interfejsu Perfetto.
• Ręcznie rejestrując dane bezpośrednio na urządzeniu w opcjach programisty. 

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

Niezależnie od wybranej metody ważne jest, aby zbierać dane z kategorii Atrace „power:PowerManagement”, co umożliwi wyświetlanie ścieżek stanu urządzenia. 

Sprawdzanie interfejsu Perfetto i analiza SQL

Dane o systemie można otwierać i sprawdzać w interfejsie Perfetto. 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.

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 identyfikowanie 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 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 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ęściowych blokad uśpienia w Android Vitals to tylko niewielka część naszych ciągłych działań na rzecz wspierania deweloperów 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, to klucz do sukcesu aplikacji w Google Play.