Oszczędzaj energię i baterię

Energooszczędność jest szczególnie ważna w Wear OS. Zasady projektowania Wear OS design principles koncentrują się w dużej mierze na zużyciu energii przez urządzenie, ponieważ zegarek jest małym urządzeniem przeznaczonym do krótkich interakcji.

W porównaniu z większymi urządzeniami mobilnymi urządzenia z Wear OS mają mniejsze baterie, więc każde zużycie baterii jest bardziej zauważalne. Ponadto ładowanie urządzenia z Wear OS wymaga od użytkownika więcej wysiłku niż ładowanie urządzenia mobilnego. Użytkownicy mogą ładować swoje urządzenia mobilne w różnych odstępach czasu w ciągu dnia, ale przed naładowaniem urządzenia z Wear OS muszą je zdjąć.

Aby zwiększyć energooszczędność aplikacji, postępuj zgodnie z tymi sprawdzonymi metodami projektowania:

• Projekt aplikacji powinien dobrze wykorzystywać format Wear OS. Nie powinien być bezpośrednią kopią aplikacji mobilnej.
• W niektórych przypadkach używaj istniejącej aplikacji mobilnej. Na przykład korzystanie z internetu i synchronizacja na zegarku są kosztowne. Zastanów się, czy urządzenie mobilne nie mogłoby wykonać większości pracy, a urządzenie z Wear OS otrzymywałoby zmiany w danych.
• Zaprojektuj przypadki użycia pod kątem krótszych interakcji.
• Zastanów się, których zdarzeń Wear OS używasz i jak często one występują.

• Jeśli to możliwe, odłóż pracę aplikacji do czasu, gdy zegarek będzie się ładować. Dotyczy to zwłaszcza zadań wymagających dużej ilości danych, takich jak synchronizacja danych i porządkowanie baz danych.

  Jeśli urządzenie się ładuje i ma połączenie Wi-Fi, zaplanuj zadania pobierania wstępnego danych, obrazów i aktualizacji, które użytkownik prawdopodobnie będzie chciał zobaczyć w Twojej aplikacji.

Ten przewodnik dotyczący oszczędzania energii pomoże Ci zrozumieć, kiedy i jak system uruchamia Twoją aplikację oraz jak możesz ograniczyć czas jej działania i zużycie baterii. Aby dowiedzieć się więcej o tym, jak wykonywane są poszczególne działania, np. wczytywanie aplikacji lub przewijanie listy, zapoznaj się z wskazówkami dotyczącymi wydajności, takimi jak przewodnik dotyczący wydajności Compose na Wear OS.

Monitorowanie zużycia baterii w czasie

Aby przeanalizować statystyki baterii urządzenia z Wear OS, na którym działa Twoja aplikacja, wpisz to polecenie w oknie terminala na komputerze używanym do programowania:

adb shell dumpsys batterystats

Biblioteka na GitHubie zawiera parser statystyk baterii, który może być przydatny do uruchamiania razem z tym poleceniem.

Zdarzenia wpływające na żywotność baterii

Zanim zaczniesz myśleć o swojej aplikacji, warto zastanowić się ogólnie nad zdarzeniami, które zużywają energię na urządzeniu z Wear OS.

Poniższa tabela pokazuje względny wpływ na żywotność baterii w przypadku kilku typowych zdarzeń w aplikacjach na Wear OS. Dokładne zużycie energii różni się w zależności od urządzenia.

Minimalizowanie czasu włączenia ekranu

W aplikacji na Wear OS postępuj zgodnie z tymi zasadami dotyczącymi korzystania z ekranu:

• Blokady włączenia ekranu: jeśli to możliwe, unikaj ich. Aby przetestować, wyłącz Zawsze włączony wyświetlacz w ustawieniach systemu i sprawdź, czy ekran wyłącza się w okresie limitu czasu.
• Animacje: ograniczaj złożone animacje i zamiast nich skup się na krótkich przejściach, aby uzyskać bardziej profesjonalny wygląd. W szczególności unikaj długotrwałych animacji i pętli. Jeśli pętla jest wymagana, dodaj między pętlami przerwę, która będzie co najmniej tak długa jak sama animacja.
• Czas aktywności w trybie nieaktywnym: w razie potrzeby obsługuj tryb zawsze włączony, np. w przypadku zastosowań związanych z fitnessem. Jeśli Twoja aplikacja wymaga trybu zawsze włączonego, postępuj zgodnie z tymi zaleceniami dotyczącymi trybu nieaktywnego.

Minimalizowanie użycia procesora

W aplikacji na Wear OS postępuj zgodnie z tymi zasadami dotyczącymi użycia procesora:

• Utrzymuj krótki czas użycia.
• Grupuj powiązane operacje, aby zmaksymalizować czas, w którym proces aplikacji jest bezczynny.

Minimalizowanie blokad wybudzania

W większości przypadków unikaj operacji, które uniemożliwiają przejście aplikacji w stan uśpienia, takich jak blokady wybudzania. Na przykład w aplikacjach treningowych długotrwałe treningi nie wymagają blokady wybudzania. Używaj czasu aktywności procesora podczas odbierania wywołań zwrotnych z interfejsu Sensor API, np. podczas korzystania z funkcji dotyczących zdrowia na Wear OS.

W niektórych przypadkach można uzyskać blokadę wybudzania, np. gdy aplikacja wykonuje jedną z tych czynności:

• Odtwarza multimedia w tle.
• Używa WorkManager lub JobScheduler. (Gdy zadanie jest wykonywane w tle, system utrzymuje blokadę wybudzania w Twoim imieniu).

Aby debugować blokady uśpienia lokalnie, użyj narzędzia Background Task Inspector w Android Studio, śledzenia systemu lub adb shell dumpsys batterystats, aby sprawdzić poszczególne wystąpienia długotrwałych blokad uśpienia, a także podsumowania łącznej liczby i czasu trwania blokad uśpienia. Porównaj liczbę i czas trwania blokad wybudzania, które utrzymuje Twoja aplikacja, z interaktywnymi wzorcami użycia aplikacji:

• Sprawdź, czy nie ma nieoczekiwanych blokad wybudzania.
• Jeśli czas trwania jest dłuższy niż oczekiwano, sprawdź, czy praca nie jest blokowana przez jakąś zależność, np. dostępność sieci.

Sprawdzanie, jak aplikacja staje się nieaktywna

Zastanów się, co robi aktywna aplikacja, gdy występują kluczowe zdarzenia urządzenia, takie jak:

• Ekran wyłącza się, a urządzenie przechodzi w tryb nieaktywny.

• Aplikacja zostaje zamknięta przez przesunięcie.

Aby przeanalizować aktywność aplikacji, użyj narzędzi opisanych w tych sekcjach.

Profiler zużycia energii

Profiler zużycia energii jest dostępny w menu Android Studio po wybraniu kolejno Widok > Okna narzędzi > Profiler:

1. Sprawdź śledzenie systemu, gdy ekran się wyłącza, a urządzenie przechodzi w tryb nieaktywny.
2. Sprawdź, czy praca jest kontynuowana, i poziom użycia procesora przez urządzenie.

Perfetto

Perfetto umożliwia zarejestrowanie śladu, a następnie sprawdzenie aplikacji, aby zobaczyć, czy są jakieś wątki wykonujące pracę, gdy ekran się wyłącza, urządzenie przechodzi w tryb nieaktywny lub użytkownik zamyka aktywność aplikacji.

Zdefiniuj zdarzenia niestandardowe, aby oznaczyć ważne zdarzenia aplikacji, w tym zdarzenia specyficzne dla domeny. W przypadku aplikacji do multimediów obejmuje to zadania takie jak pobieranie list odtwarzania, pobieranie konkretnego elementu multimedialnego, rozpoczynanie odtwarzania i zatrzymywanie odtwarzania. Dzięki zdefiniowaniu tych zdarzeń możesz je zobaczyć w Perfetto i porównać ich czas z użyciem procesora i energii przez aplikację.

Możesz też użyć interfejsu wiersza poleceń Androida, aby zainstalować android-profiler umiejętność (android skills add android-profiler), która umożliwia agentom AI rejestrowanie śledzenia systemu Perfetto z wiersza poleceń i analizowanie szyn zasilania, blokad uśpienia i stanów zawieszenia urządzenia.

Analizowanie zaplanowanych zadań aplikacji

Zaplanowane zadania, które korzystają z WorkManager, umożliwiają wykonywanie pracy w tle w aplikacji. Chociaż niektóre zadania w tle muszą być wykonywane okresowo, nie uruchamiaj zadań zbyt często ani na zbyt długo, ponieważ może to spowodować wyczerpanie baterii urządzenia.

Aby sprawdzić wykonywanie zaplanowanych zadań i workerów, użyj narzędzia Background Task Inspector w Android Studio (Widok > Okna narzędzi > Sprawdzanie aplikacji) lub uruchom adb shell dumpsys jobscheduler i adb shell dumpsys batterystats. Sprawdź częstotliwość wykonywania i łączny czas trwania:

• Jeśli zadanie jest wykonywane bardzo często, rozważ zmniejszenie tej częstotliwości.
• Sprawdź, czy łączny czas wykonywania jest zgodny z oczekiwaniami i nie jest znacznie dłuższy.

Możesz też zarejestrować śledzenie systemu, aby skorelować wykonywanie zadań z aktywnością aplikacji na osi czasu. Weź pod uwagę te kwestie:

• Czas wykonywania powinien być odpowiedni dla Twojej aplikacji.
• Zastanów się, czy zadania są wykonywane, gdy aplikacja jest uruchomiona, czy też reprezentują okresową pracę w tle.

Czujniki

Urządzenia z Wear OS mają wiele różnych czujników, np. GPS. W większości przypadków używaj funkcji dotyczących zdrowia na Wear OS zamiast bezpośrednio korzystać z SensorManager. W wielu przypadkach funkcje dotyczące zdrowia inteligentnie grupują dane, aby poprawić wydajność baterii.

Aby przeanalizować użycie czujników w aplikacji, uruchom to polecenie w oknie terminala na komputerze używanym do programowania:

adb shell dumpsys sensorservice

Wyniki tego polecenia pokazują:

• Aktualne i poprzednie rejestracje czujników.
• Konfigurację czujnika, w tym grupowanie, jeśli jest ustawione.
• Ostatnio pobrane dane.

Testowanie wyrejestrowania z czujników

Aby sprawdzić, czy aplikacja przestaje pobierać dane z czujników zgodnie z oczekiwaniami, przetestuj te scenariusze:

1. Zamknij aplikację przez przesunięcie.
2. Dotknij ekranu dłonią. Spowoduje to wyłączenie ekranu lub przejście w tryb nieaktywny.

Użyj polecenia ADB z poprzedniej sekcji, aby sprawdzić, czy czujnik jest prawidłowo oznaczony jako wyrejestrowany.

Warstwa danych

Podczas korzystania z interfejsu Data Layer API każda transmisja zużywa trochę energii. W szczególności, jeśli używasz tego interfejsu API do wysyłania danych, aplikacja musi się wybudzić, aby je odebrać. Z tych powodów używaj tego interfejsu API z rozwagą.

Oto kilka dodatkowych sprawdzonych metod korzystania z interfejsu Data Layer API:

• Zanim skonfigurujesz odbiornik za pomocą WearableListenerService, poczekaj, aż aplikacja będzie aktywna.
• Nie używaj interfejsu Data Layer API do okresowego pingowania zegarka, aby sprawdzić, czy urządzenie lub aplikacja towarzysząca jest dostępna. Wysyłając wiadomości wielokrotnie, aplikacja wybudza radio i proces aplikacji zdalnej, co powoduje większe niż konieczne zużycie baterii urządzenia. Zamiast tego użyj CapabilityClient, aby wykryć dostępność i możliwości urządzenia, lub wysyłaj wiadomości tylko wtedy, gdy zmieni się stan.

• Zamiast konfigurować szybkie aktualizacje, przesyłaj zmiany stanu. Te zmiany stanu umożliwiają urządzeniu z Wear OS wykonywanie lokalnych obliczeń danych, np. gdy rozpoczęła się sesja treningowa.

  Przesyłaj tylko zmiany stanu, które aktualizują interfejs. Jeśli na przykład ekran aktywności pokazuje tylko „przebiegnięte kilometry” z dokładnością do 1 miejsca po przecinku, nie wysyłaj zmiany stanu do Wear OS za każdym razem, gdy użytkownik przebiegnie kolejny metr.

Aby przeanalizować użycie interfejsu Data Layer API w aplikacji, uruchom to polecenie w oknie terminala na komputerze deweloperskim:

adb shell dumpsys activity service WearableService

Wyniki tego polecenia obejmują:

• RpcService: umożliwia sprawdzenie, jak często i które ścieżki są wywoływane za pomocą MessageClient.
• DataService: umożliwia sprawdzenie, jak często ustawiane są elementy danych za pomocą DataClient.

Aplikacje treningowe

Jeśli utrzymujesz aplikację treningową, używaj funkcji dotyczących zdrowia, aby zoptymalizować użycie czujników przez aplikację.

• W przypadku ExerciseClient użyj śledzenia systemu, Perfetto lub adb shell dumpsys batterystats, aby sprawdzić prawidłowe działanie w trybie nieaktywnym. Sprawdź, czy aplikacja nie wybudza się częściej niż co minutę lub dwie, aby odbierać dane ExerciseUpdate.
• Do całodziennego monitorowania ogólnego stanu zdrowia używaj PassiveMonitoringClient, zgodnie z opisem w przewodniku dotyczącym monitorowania danych o zdrowiu i aktywności fizycznej w tle.

Kafelki i widżety

Jeśli Twoja aplikacja obsługuje kafelek lub widżet, postępuj zgodnie z tymi sprawdzonymi metodami:

• Wyłącz automatyczne odświeżanie lub zwiększ częstotliwość odświeżania do 2 godzin lub więcej.
• Do wysyłania aktualizacji danych używaj Komunikacji w chmurze Firebase (FCM) lub odpowiednio zaplanowanych zadań. Uważaj, aby nie dopuścić do szybkiego tempa aktualizacji, które może spowodować, że system będzie planować powtarzające się zadania z większą częstotliwością niż użytkownik lub platforma mogą uzyskać dostęp do danych potrzebnych do wykonania tego zadania.
• Nie planuj pracy dla kafelka ani widżetu, gdy użytkownik z nim nie wchodzi w interakcję.
• Stosuj podejście „offline first”.
• Udostępniaj jedną bazę danych głównej aplikacji, kafelkom i widżetom. Pomaga to też zachować spójność danych w interfejsie.