Prawdziwa praca nad aplikacją na Androida na urządzenia do noszenia zaczyna się, gdy ekran się wyłącza. WHOOP pomaga użytkownikom zrozumieć, jak ich organizm reaguje na trening, regenerację, sen i stres. Dla wielu użytkowników WHOOP korzystających z Androida niezawodna synchronizacja w tle i łączność są tym, co umożliwia uzyskanie tych informacji.

W tym roku w Google Play opublikowaliśmy nowy wskaźnik w Android Vitals: zbyt wiele częściowych blokad uśpienia. Ten wskaźnik mierzy odsetek sesji użytkowników, w których łączne użycie blokady uśpienia (z wyłączeniem wyjątków) przekracza 2 godziny w ciągu 24 godzin. Celem tego wskaźnika jest pomoc w identyfikowaniu i usuwaniu możliwych przyczyn szybkiego zużycia baterii, co ma kluczowe znaczenie dla zapewnienia użytkownikom jak najlepszych wrażeń.

Od 1 marca 2026 r. aplikacje, które nadal nie będą spełniać progu jakości, mogą zostać wykluczone z platform Google Play, na których można je znaleźć. W informacjach o aplikacji w Sklepie Google Play może też pojawić się ostrzeżenie, że aplikacja może zużywać więcej baterii niż oczekiwano.

Według Mayanka Sainiego, starszego inżyniera Androida w firmie WHOOP, „dało to zespołowi możliwość podniesienia poprzeczki w zakresie wydajności Androida”. Funkcje Android Vitals wykazały, że odsetek nadmiernych częściowych blokad uśpienia w aplikacji wynosi 15%, co przekracza zalecany próg 5%.

Zespół uznał wskaźnik Android Vitals za wyraźny sygnał, że praca w tle utrzymywała procesor w stanie aktywności dłużej niż to konieczne. Rozwiązanie tego problemu pozwoliłoby im nadal zapewniać użytkownikom doskonałe wrażenia, a jednocześnie zmniejszyć marnowany czas w tle i utrzymać niezawodne i terminowe połączenie Bluetooth oraz synchronizację.

Identyfikowanie problemu

Aby dowiedzieć się, od czego zacząć, zespół najpierw sprawdził dane Android Vitals, aby uzyskać więcej informacji o tym, które blokady wybudzania wpływają na ten wskaźnik. Dzięki panelowi Android Vitals dotyczącemu nadmiernych częściowych blokad uśpienia udało im się ustalić, że największy wpływ na nadmierne częściowe blokady uśpienia ma jeden z workerów WorkManager (w panelu oznaczony jako androidx.work.impl.background.systemjob.SystemJobService). Aby zapewnić „zawsze włączone” WHOOP, aplikacja używa WorkManager do zadań w tle, takich jak okresowa synchronizacja i dostarczanie cyklicznych aktualizacji na urządzenie do noszenia. 

Zespół wiedział, że WorkManager uzyskuje blokadę uśpienia podczas wykonywania zadań w tle, ale wcześniej nie miał wglądu w to, jak rozkłada się cała praca w tle (nie tylko WorkManager), dopóki w Android Vitals nie wprowadzono wskaźnika nadmiernych częściowych blokad uśpienia.

Dzięki temu, że panel wskazał WorkManager jako głównego sprawcę problemu, zespół mógł skupić się na określeniu, który z procesów miał największy wpływ na ten problem, i podjąć działania w celu jego rozwiązania.

Wykorzystywanie wewnętrznych danych i statystyk do lepszego określania przyczyny

Firma WHOOP miała już skonfigurowaną infrastrukturę wewnętrzną do monitorowania danych WorkManagera. Okresowo monitorują:

1. Średni czas działania: jak długo działa pracownik?
2. Przekroczenia limitu czasu: jak często pracownik przekracza limit czasu zamiast ukończyć zadanie?
3. Ponowne próby: jak często instancja robocza ponawia próbę, jeśli zadanie przekroczy limit czasu lub się nie powiedzie?
4. Anulowania: jak często zlecenie zostało anulowane?

Śledzenie nie tylko sukcesów i porażek pracowników, ale też innych aspektów ich pracy pozwala zespołowi ocenić jej wydajność.

Wewnętrzne dane oznaczyły wysoki średni czas działania w przypadku kilku instancji roboczych, co pozwoliło jeszcze bardziej zawęzić zakres analizy. 

Oprócz wewnętrznych danych zespół korzystał też z inspektora zadań w tle w Android Studio, aby sprawdzać i debugować interesujące go procesy robocze, ze szczególnym uwzględnieniem powiązanych blokad wybudzania, co było zgodne z danymi oznaczonymi w Android Vitals.

Badanie: rozróżnianie wersji pracowników

WHOOP stosuje w przypadku niektórych pracowników zarówno harmonogramy jednorazowe, jak i okresowe. Dzięki temu aplikacja może ponownie wykorzystać tę samą logikę procesu roboczego w przypadku identycznych zadań o tych samych kryteriach sukcesu, które różnią się tylko czasem wykonania.

Korzystając z wewnętrznych danych, mogli zawęzić wyszukiwanie do konkretnego pracownika, ale nie mogli stwierdzić, czy błąd wystąpił, gdy pracownik był zatrudniony jednorazowo, okresowo czy w obu przypadkach. Wprowadzili więc aktualizację, aby używać metody setTraceTag WorkManagera do rozróżniania jednorazowych i okresowych wariantów tego samego procesu.

Te dodatkowe informacje pozwoliłyby im jednoznacznie określić, która wersja usługi Worker (okresowa czy jednorazowa) miała największy wpływ na sesje z nadmierną liczbą częściowych blokad wybudzania. Zespół był jednak zaskoczony, gdy dane wykazały, że żadna z tych wersji nie przyczynia się do wzrostu liczby wyświetleń bardziej niż druga.

Manmeet Tuteja, inżynier Androida II w firmie WHOOP, powiedział: „Ten podział pomógł nam też potwierdzić, że problem występuje w obu wariantach, co wskazywało na problem ze wspólną logiką biznesową w implementacji procesu roboczego, a nie na konfigurację harmonogramu”.

Szczegółowe informacje o zachowaniu pracowników i usuwanie głównej przyczyny

Zespół, wiedząc, że musi przyjrzeć się logice wewnątrz instancji roboczej, ponownie przeanalizował zachowanie instancji roboczych, które zostały oznaczone podczas śledztwa. Szukali w szczególności przypadków, w których praca mogła utknąć i nie została ukończona.

Wszystko to doprowadziło do znalezienia głównej przyczyny zbyt częstych blokad uśpienia:

CoroutineWorker, który został zaprojektowany tak, aby przed przejściem dalej czekać na połączenie z czujnikiem WHOOP. 

Jeśli praca rozpoczęła się bez podłączonego czujnika, ikona whoopSensorFlow– która wskazuje, czy czujnik jest podłączony – miała wartość null. SensorWorker nie potraktował tego jako warunku wcześniejszego zakończenia i działał dalej, czekając w nieskończoność na połączenie. W rezultacie WorkManager utrzymywał częściową blokadę uśpienia do czasu przekroczenia limitu czasu zadania, co prowadziło do wysokiego wykorzystania blokady uśpienia w tle i częstego, niechcianego ponownego planowania SensorWorker.

Aby rozwiązać ten problem, zespół WHOOP zaktualizował logikę procesu roboczego, tak aby przed próbą wykonania podstawowej logiki biznesowej sprawdzać stan połączenia.

Jeśli czujnik jest niedostępny, worker kończy działanie, co pozwala uniknąć przekroczenia limitu czasu i zwolnić blokadę uśpienia. Poniższy fragment kodu pokazuje rozwiązanie:

class SensorWorker(appContext: Context, params: WorkerParameters): CoroutineWorker(appContext, params) {
   override suspend fun doWork(): Result {
      ...
      // Check the sensor state and perform work or return failure
       return whoopSensorFlow.replayCache
            .firstOrNull()
            ?.let { cachedData ->
                processSensorData(cachedData)
                Result.success()
            } ?: run {
                Result.failure()
            }
}

Zmniejszenie o 90% liczby sesji z nadmierną liczbą częściowych blokad uśpienia

Po wdrożeniu poprawki zespół nadal monitorował panel Android Vitals, aby potwierdzić wpływ zmian. 

W efekcie firma WHOOP odnotowała spadek odsetka nadmiernych częściowych blokad uśpienia z 15% do poniżej 1% w ciągu zaledwie 30 dni  od wprowadzenia zmian w usłudze Worker. 

Dzięki tym zmianom zespół odnotował mniej przypadków przekroczenia limitu czasu pracy bez jej ukończenia, co przełożyło się na krótsze średnie czasy działania. 

Rada zespołu WHOOP dla innych deweloperów, którzy chcą zwiększyć wydajność pracy w tle:

Rozpocznij

Jeśli chcesz zmniejszyć liczbę nadmiernych częściowych blokad uśpienia w aplikacji lub poprawić wydajność procesów roboczych, wyświetl wskaźnik nadmiernych częściowych blokad uśpienia w Android Vitals i zapoznaj się z dokumentacją dotyczącą blokad uśpienia, aby poznać więcej sprawdzonych metod i strategii debugowania.