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 kluczowym wskaźnikiem wydajności jest 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. Jeśli od 1 marca 2026 r. tytuł nie będzie spełniać tego progu jakości, możemy wykluczyć go z widocznych miejsc, 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 korzysta z usługi 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 przejście procesora 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 tego 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 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 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 negatywnie wpłynie na wrażenia użytkownika?
   • 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ć 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 do tagów blokad uśpienia liczników ani unikalnych identyfikatorów. 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 interwał okresowy 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), 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ęś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 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, 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ć 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 debugowania 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 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, w których blokady uśpienia są utrzymywane ręcznie lub przez interfejsy API, zalecamy użycie zbierania danych na temat wydajności systemu do debugowania.

Zbieranie danych na temat wydajności systemu

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

• Za pomocą narzędzia wiersza poleceń do zbierania danych na temat wydajności systemu.
• Za pomocą profilera procesora w Android Studio
• Za pomocą interfejsu Perfetto.
• Ręcznie, bezpośrednio na urządzeniu, w opcjach programisty directly from the developer options. 

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

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

Sprawdzanie interfejsu Perfetto i analiza SQL

Dane na temat wydajności systemu 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, godzinę 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, które sumuje wszystkie tagi blokad uśpienia występujące w danych na temat wydajności systemu, 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 systemu 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 systemu 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 systemu 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. Wykorzystywanie 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 na temat wydajności systemu i ProfilingManager, to klucz do sukcesu aplikacji w Google Play.