Monitorowanie jakości technicznej aplikacji przy użyciu Android Vitals

Nowe statystyki dotyczące problemów z jakością aplikacji i rekomendacje

Od września 2024 roku w Konsoli Play znajdziesz nowe statystyki i rekomendacje na stronach Podsumowanie Android Vitals oraz Awarie i błędy ANR, które pomogą Ci określić priorytety problemów z jakością.

Obecnie wyświetlane są problemy ze zgodnością aplikacji, informacje o niewłaściwym działaniu i niektóre rekomendacje dotyczące UX. W przyszłym roku będziemy nadal wykrywać i wyświetlać więcej problemów z jakością oraz przedstawiać więcej rekomendacji.

Funkcja Android Vitals ułatwia zrozumienie i poprawienie m.in. stabilności działania aplikacji, jej wydajności i wykorzystania przez nią baterii.

Wybieranie sposobu uzyskiwania dostępu do danych o aplikacji

Z Android Vitals możesz korzystać na 2 sposoby: w Konsoli Play i za pomocą interfejsu Play Developer Reporting API.

Interfejs API umożliwia automatyczny dostęp do Android Vitals deweloperom, którzy chcą zintegrować dane Android Vitals z innymi zbiorami danych lub uwzględniać je w swoich przepływach pracy. Więcej informacji o korzystaniu z interfejsu API do uzyskiwania dostępu do Android Vitals znajdziesz na stronie interfejsu Google Play Developer Reporting API.

Aby znaleźć i przejrzeć dane Android Vitals w Konsoli Play:

1. Otwórz Konsolę Play i wejdź na stronę Podsumowanie Android Vitals (Jakość > Android Vitals > Podsumowanie).
2. Za pomocą selektora zakresu dat w prawym górnym rogu wybierz zakres, który chcesz wyświetlić.

Ważne: jeśli żadne dane nie są dostępne, oznacza to, że aplikacja nie ma wystarczającej liczby punktów danych po zastosowaniu filtrów i nie można zidentyfikować problemów.

Monitorowanie podstawowych wskaźników aplikacji

U góry strony Podsumowanie Android Vitals znajdziesz dane dotyczące podstawowych wskaźników aplikacji. To najważniejsze dane techniczne, które wpływają na możliwość odkrycia aplikacji w Google Play. Podstawowe wskaźniki to między innymi:

• Częstotliwość błędów ANR postrzegana przez użytkowników
• Częstotliwość awarii postrzegana przez użytkowników

W przypadku tych danych Google Play określa progi niewłaściwego działania. Jeśli Twoja aplikacja je przekracza, prawdopodobnie będzie trudniejsza do odkrycia w Google Play. W niektórych przypadkach w informacjach o aplikacji może wyświetlać się ostrzeżenie, aby użytkownicy wiedzieli, czego mogą się spodziewać.

W sekcji „Problemy krytyczne” możesz szybko zidentyfikować obszary wymagające poprawy. Wyróżniamy 2 rodzaje problemów krytycznych:

• Niewłaściwe działanie: dane, które przekraczają progi niewłaściwego działania.
• Anomalie: znaczne zmiany w danych (np. nagły wzrost częstotliwości błędów ANR widocznych dla użytkowników).

Aby otrzymywać e-maile z powiadomieniami, wybierz Konfiguracja > Powiadomienia lub kliknij Zarządzaj powiadomieniami w rogu sekcji „Podstawowe wskaźniki” (Jakość > Android Vitals > Przegląd). Obecnie powiadomienia są dostępne tylko w przypadku anomalii.

Przeglądanie wszystkich podstawowych wskaźników

Na środku strony Podsumowanie Android Vitals zobaczysz informacje na temat wszystkich podstawowych wskaźników według aspektu jakości.

W tabeli możesz sprawdzić dane dotyczące bieżącego i poprzedniego okresu. Możesz też zobaczyć, jak Twoja aplikacja wypada na tle innych w Google Play.

Przeglądanie szczegółowych danych

Aby dowiedzieć się więcej o konkretnych danych, wybierz Wyświetl szczegóły () obok elementu. Na następnym ekranie możesz przejrzeć:

• progi niewłaściwego działania;
• porównanie kategorii;
• szczegółowe porównanie z wartościami referencyjnymi;
  • w górnej części strony, na karcie porównywania z aplikacjami z grupy porównawczej, wybierz Edytuj grupę porównawczą, aby edytować niestandardową grupę porównawczą – po utworzeniu takiej grupy możesz sprawdzić, jak Twoja aplikacja wypada na tle innych wybranych aplikacji w Google Play;
• trend danych w czasie.

Analizowanie danych za pomocą wymiarów

Aby porządkowanie i analizowanie informacji było łatwiejsze, dane są podzielone według wielu różnych wymiarów. Wszystkie dane są podzielone według tych wymiarów:

• Artefakt: wersja aplikacji, w której wystąpił problem.
• Wersja Androida (SDK): wersja systemu operacyjnego Android zgłaszana przez urządzenie użytkownika.
• Format: typ urządzenia użytego do uruchomienia aplikacji (np. telefon, tablet, telewizor, urządzenie do noszenia).
• Model urządzenia: ogólny opis urządzenia składający się z unikalnego identyfikatora i marki, np. „Google oriole”. Jeden model może mieć warianty z różnymi wersjami Androida lub układu SOC, a także z różną ilością pamięci RAM i miejsca na dane.
• Kraj/region: lokalizacja zgłoszona przez urządzenie użytkownika w momencie wystąpienia problemu.

Wskazówka: aby zobaczyć podział według określonych aspektów sprzętu lub oprogramowania urządzenia (np. modelu urządzenia lub wersji Androida), obok elementu w tabeli kliknij symbol ().

Niektóre dane są podzielone według dodatkowych wymiarów:

• Nazwa blokady uśpienia: tagi, które zostały automatycznie określone przy użyciu interfejsu PowerManager API w aplikacji.
• Nazwa wybudzenia: tagi, które zostały automatycznie określone przy użyciu interfejsu API AlarmManager w aplikacji.
• Nazwa działania ANR: pełna i jednoznaczna nazwa klasy działania, w której wystąpił błąd ANR (jeśli jest dostępna).
• Typ błędu ANR: informacja (jeśli jest dostępna) o tym, kiedy wystąpił błąd ANR – np. podczas wykonywania usługi.

Aby w razie możliwości zobaczyć więcej szczegółów (np. klastry ANR lub klastry błędów związane z tym podziałem), obok elementu kliknij Wyświetl szczegóły ().

Wskazówka: za pomocą przełącznika u góry ekranu możesz przełączać się między danymi w kategorii i filtrować stronę.

Typy danych i wskaźniki

W Konsoli Play dostępne są dane Android Vitals z ostatnich 90 dni, a w interfejsie Play Developer Reporting API – z 3 lat.

Dane są zbierane od użytkowników różnych urządzeń z różnymi wersjami Androida i systemu operacyjnego, którzy zgodzili się na automatyczne udostępnianie danych dotyczących użytkowania i diagnostyki. Więcej informacji o tym, jak użytkownicy Androida zgadzają się na udostępnianie danych, znajdziesz w Centrum pomocy kont Google.

Funkcja Android Vitals jest codziennie aktualizowana. Czasami dane dotyczące urządzeń z Androidem 10 lub nowszym są dostarczane wcześniej niż te dotyczące urządzeń ze starszą wersją Androida. W takim przypadku widoczne są dane dotyczące urządzeń z Androidem 10 lub nowszym tylko z dostępnych dni.

Uwaga: dane Android Vitals nie obejmują problemów technicznych, które występują w przypadku modeli urządzeń bez certyfikacji lub wersji aplikacji, które nie zostały zainstalowane z Google Play.

Zwiń wszystko Rozwiń wszystko

Stabilność

Dane dotyczące częstotliwości błędów ANR

Dane dotyczące częstotliwości błędów ANR dostarczają informacji o jakości aplikacji. Te dane są obliczane na podstawie liczby użytkowników z błędami ANR ujednoliconej pod kątem użytkowania aplikacji. Są one zgłaszane jako odsetek aktywnych użytkowników dziennie, czyli osób korzystających z aplikacji w ciągu 1 dnia na 1 urządzeniu. Jeśli użytkownik korzysta z aplikacji na więcej niż 1 urządzeniu w ciągu 1 dnia, każde z tych urządzeń wpłynie na liczbę aktywnych użytkowników w danym dniu. Jeśli wielu użytkowników korzysta z tego samego urządzenia w ciągu 1 dnia, jest to liczone jako 1 aktywny użytkownik.

Wyróżniamy 3 rodzaje danych dotyczących częstotliwości błędów ANR:

• Częstotliwość błędów ANR widocznych dla użytkowników: odsetek aktywnych użytkowników dziennie, u których wystąpił co najmniej 1 błąd ANR widoczny dla użytkowników. Błędy ANR widoczne dla użytkowników to błędy ANR, które prawdopodobnie zostały wykryte przez użytkownika. Obecnie zliczane są tylko błędy ANR „Input dispatching timed out” (Przekroczono limit czasu wysyłania danych wejściowych). Te dane będą się zawsze znajdować niżej niż ogólna częstotliwość błędów ANR, ponieważ są ujednolicone pod kątem codziennego użytkowania, ale nie uwzględniają wszystkich błędów ANR.
  Częstotliwość błędów ANR widocznych dla użytkowników jest jednym z podstawowych wskaźników, co oznacza, że wpływa na możliwość odkrycia Twojej aplikacji w Google Play. Jest to ważne, ponieważ zliczane błędy ANR występują zawsze, gdy użytkownik korzysta z aplikacji, co powoduje najwięcej zakłóceń.
• Częstotliwość błędów ANR: odsetek użytkowników dziennie, u których wystąpił co najmniej 1 błąd ANR. Te dane obejmują błędy ANR, które nie są sklasyfikowane jako postrzegane przez użytkowników, ale nie możemy zagwarantować, że na nich nie wpływają.
• Częstotliwość wielokrotnych błędów ANR: odsetek użytkowników dziennie, u których wystąpiły co najmniej 2 błędy ANR. Te dane pomagają wyróżnić pętle błędów.

Rozwiązywanie problemu

Błędy ANR, które mają wpływ na dane dotyczące częstotliwości tych błędów, są widoczne na stronie Awarie i błędy ANR. Na tej stronie możesz filtrować błędy ANR postrzegane przez użytkowników.

Wskazówki dotyczące diagnozowania i naprawiania błędów ANR znajdziesz na stronie dla deweloperów aplikacji na Androida.

Dane dotyczące częstotliwości awarii

Dane dotyczące częstotliwości awarii dostarczają informacji o jakości aplikacji. Oblicza się je na podstawie liczby użytkowników z awariami ujednoliconej pod kątem użytkowania aplikacji. Są one zgłaszane jako odsetek użytkowników dziennie, czyli osób korzystających z aplikacji w ciągu 1 dnia na 1 urządzeniu. Jeśli użytkownik ma więcej niż 1 urządzenie, zostanie policzony więcej niż raz. Jeśli na przykład 2 użytkowników będzie korzystać z aplikacji na osobnych urządzeniach przez 2 dni, w rezultacie da to 4 sesje dzienne.

Wyróżniamy 3 rodzaje danych dotyczących częstotliwości awarii:

• Częstotliwość awarii widocznych dla użytkowników: odsetek użytkowników dziennie, u których wystąpiła co najmniej 1 widoczna dla nich awaria. Chodzi o awarię, która prawdopodobnie została zauważona przez użytkownika. Obejmuje to na przykład awarie, które mają miejsce, gdy aplikacja wyświetla aktywność lub działa jako usługa na pierwszym planie. Te dane będą miały zawsze niższe wartości niż ogólna częstotliwość awarii, ponieważ są ujednolicone pod kątem codziennego użytkowania, ale nie uwzględniają wszystkich awarii.
  Częstotliwość awarii widocznych dla użytkowników jest jednym z podstawowych wskaźników, co oznacza, że wpływa na możliwość odkrycia Twojej aplikacji w Google Play. Jest to ważne, ponieważ zliczane awarie występują zawsze, gdy użytkownik korzysta z aplikacji, co powoduje najwięcej zakłóceń. Dlatego upewnij się, że Twoja aplikacja nie przekracza progu niewłaściwego działania w przypadku tych danych.

• Częstotliwość awarii: odsetek użytkowników dziennie, u których wystąpiła co najmniej 1 awaria. Te dane obejmują awarie, które nie są sklasyfikowane jako postrzegane przez użytkowników, ale nie możemy zagwarantować, że na nich nie wpływają.

• Częstotliwość wielokrotnych awarii: odsetek użytkowników dziennie, u których wystąpiły co najmniej 2 awarie. Te dane pomagają wyróżnić pętle błędów.

Rozwiązywanie problemu

Wskazówki dotyczące diagnozowania i naprawiania awarii znajdziesz na stronie dla deweloperów aplikacji na Androida.

Czasy uruchomienia i wczytywania

Czas na uruchomienie (czas do początkowego wyświetlenia)

Na stronie Czas uruchomienia możesz zobaczyć szczegóły na temat czasu uruchomienia aplikacji „na zimno”, częściowo z pamięci i z pamięci. Jest to czas od chwili uruchomienia aplikacji przez użytkownika do momentu, gdy na ekranie pojawią się pierwsze klatki, czyli tzw. „czas do początkowego wyświetlenia”.

Po tym czasie Twoja aplikacja nie musi być gotowa na interakcje ze strony użytkownika, np. jeśli ma dodatkowe ekrany ładowania.

Szczegółowe informacje o zbieraniu danych

• Czas uruchomienia jest rejestrowany dopiero po wyzwoleniu działania przez użytkownika.
  • Przykład: w przypadku aplikacji klawiatury czas uruchomienia jest równy czasowi uruchomienia aplikacji towarzyszącej.
• Jeśli aplikacja uruchomi się wiele razy tego samego dnia z tego samego stanu systemu, zostanie zarejestrowany najdłuższy czas uruchomienia z danego dnia.
• Czas uruchomienia jest monitorowany po całkowitym załadowaniu pierwszej ramki aplikacji, nawet jeśli nie jest to ekran pozwalający użytkownikowi na interakcję.
  • Przykład: jeśli aplikacja rozpoczyna działanie od wyświetlenia ekranu powitalnego, czas uruchomienia to czas, jaki musi minąć, zanim wyświetli się taki ekran.

Dane Android Vitals

• Liczba pasujących sesji: odsetek sesji, w których wystąpił problem długiego czasu uruchamiania w poszczególnych stanach systemu:
  • Powolne uruchomienie „na zimno”: co najmniej 5 sekund,
  • Powolne uruchomienie „na ciepło”: co najmniej 2 sekundy,
  • Powolne uruchomienie z pamięci: co najmniej 1 sekunda.
• Liczba sesji: przybliżona liczba zarejestrowanych sesji.
• 90/99 centyl: 10%/1% sesji dziennych, podczas których wystąpił długi czas uruchomienia aplikacji.

Rozwiązywanie problemu

Jeśli aplikacja często uruchamia się powoli, poszukaj rozwiązań na stronie dla deweloperów aplikacji na Androida.

Renderowanie

Całe renderowanie

Współczynnik powolnych sesji (30 FPS lub 20 FPS) [tylko gry]

Dlaczego to jest ważne

Za pomocą powolnych sesji możesz poznać liczbę klatek, od której zależy płynność działania gry.

Przeglądanie danych o aplikacji

Na stronie Powolne sesje znajdują się szczegółowe informacje o odsetku sesji dziennych, podczas których u użytkowników wystąpiło ponad 25% klatek o szybkości poniżej 30 lub 20 FPS, w zależności od wybranej wartości referencyjnej. Możesz też sprawdzić podział sesji według liczby klatek w grze. Liczba klatek w sesji jest mierzona na 75. centylu, co oznacza, że 75% klatek osiąga co najmniej taką liczbę klatek.

Docelową szybkością klatek w większości gier w Google Play powinno być co najmniej 30 FPS. Pozwala to na zapewnienie użytkownikom płynnego działania gry, niezależnie od jej typu. Niektórzy preferują jednak gry z prędkością co najmniej 60 FPS, zwłaszcza na zaawansowanych urządzeniach. Sprawdzaj współczynnik powolnych sesji (30 FPS), aby mieć pewność, że uzyskujesz taki wynik. Pamiętaj, że dane te obejmują tylko sesje, w których ponad 25% klatek osiąga mniej niż 30 FPS, więc cechują się pewną tolerancją dla zmienności liczby klatek.

Mimo że 30 FPS zapewnia płynne działanie, może się zdarzyć, że konieczne będzie zmniejszenie liczby klatek poniżej tego poziomu. Użytkownicy mogą też chcieć zagrać w grę na telefonach, które nie obsługują takiej szybkości. W takich przypadkach co najmniej 75% klatek w sesji nadal powinno mieć szybkość co najmniej 20 FPS. Sprawdzaj współczynnik powolnych sesji (20 FPS), aby mieć pewność, że uzyskujesz taki wynik.

Android Vitals zgłasza powolne sesje (30 i 20 FPS) zarówno na poszczególnych urządzeniach, jak i na wszystkich urządzeniach i we wszystkich sesjach. Przeglądaj łączne dane, aby poznać ogólne działanie gry, ale zwróć też uwagę na wydajność na poszczególnych urządzeniach. W przyszłości Google Play zacznie zachęcać użytkowników do odchodzenia od gier, które nie zapewniają szybkości 20 FPS na telefonach.

Android Vitals rozpoczyna monitorowanie liczby klatek dopiero po minucie gry.

Szczegółowe informacje o zbieraniu danych

Dane o powolnych sesjach są obliczane na podstawie danych zebranych przy użyciu narzędzia SurfaceFlinger. Liczba klatek w sesji jest szacowana na podstawie czasu między klatkami wyświetlanymi w ramach aplikacji i obejmuje klatki wyrenderowane przez OpenGL, Vulkan oraz zestaw narzędzi interfejsu Androida. Te dane są obecnie dostępne tylko w przypadku gier.

Dane dotyczące liczby klatek w powolnych sesjach są zbierane na urządzeniach z Androidem 9 i nowszym.

Panel

• Reprezentatywna liczba klatek: liczba klatek w grze na urządzeniach z Androidem 9 lub nowszym obliczona na 75. percentylu. Oznacza to, że 75% sesji miało taką lub większą liczbę klatek przez 75% czasu.
• Częstotliwość powolnych sesji w czasie: seria czasowa pokazująca odsetek sesji uznawanych za powolne.
• Rozkład liczby klatek: histogram przedstawiający 75 percentyl liczby klatek w sesjach. Oznacza to, że 75% klatek w sesji było szybszych niż liczba klatek używanych do grupowania sesji.

Rozwiązywanie problemu

Jeśli w przypadku aplikacji występuje duża liczba powolnych sesji, poszukaj rozwiązań na stronie dla deweloperów aplikacji na Androida.

Renderowanie zestawu narzędzi intefejsu Androida

Nadmierna liczba spowolnionych klatek [tylko aplikacje]

Przeglądanie danych o aplikacji

Na stronie Nadmierna liczba spowolnionych klatek znajdują się szczegółowe informacje o odsetku sesji dziennych, podczas których u użytkowników wystąpiło ponad 50% klatek wyrenderowanych z opóźnieniem w stosunku do nominalnego czasu renderowania na urządzeniu. Podczas czynności wykonywanych przez użytkownika aplikacja powinna być wyświetlana z szybkością 60 klatek na sekundę bez pominięcia lub opóźnienia jakichkolwiek klatek.

Szczegółowe informacje o zbieraniu danych

Google zbiera dane o czasie renderowania każdej klatki przez aplikację za pomocą platformy zestawu narzędzi interfejsu. Klatki wyrenderowane bezpośrednio z wykorzystaniem interfejsu OpenGL lub Vulkan nie są brane pod uwagę.

Panel

Jeśli wybierzesz wiersz, zobaczysz dane wyrażone w percentylach.

• Liczba pasujących sesji: procent sesji dziennych, podczas których u użytkowników wystąpiło ponad 50% klatek z czasem renderowania dłuższym niż 16 ms. Sesja dzienna oznacza dzień, w którym aplikacja była używana. Jeśli na przykład 2 użytkowników będzie korzystać z aplikacji przez 2 dni, w rezultacie da to 4 sesje dzienne.
• Liczba sesji: przybliżona liczba zarejestrowanych sesji.
• 90/99 centyl: 90%/99% łącznej liczby klatek miało czas renderowania krótszy niż pokazywana liczba. Te liczby są oparte na wszystkich zebranych klatkach.

Jeśli klikniesz wpis w tabeli, pokaże się wykres „Rozkład czasu renderowania interfejsu”. Najlepiej, gdy większość klatek aplikacji jest wyświetlanych w czasie 16 ms lub krócej.

Dane pod wykresem przedstawiają informacje o wydajności renderowania aplikacji i mogą Ci pomóc w znalezieniu głównej przyczyny problemów ze zbyt długim renderowaniem. Jeśli na przykład odsetek „Dużych opóźnień sygnału wejściowego” jest wysoki, przyjrzyj się kodowi aplikacji, który obsługuje wprowadzanie danych przez użytkowników. Aby dowiedzieć się więcej o tych danych, przeczytaj artykuł o testowaniu wydajności UI.

• Pominięte synchronizacje Vsync: dotyczy wszystkich klatek renderowanych dłużej niż 16 ms. Jest to stosunek liczby pominiętych zdarzeń Vsync do liczby klatek.
• Duże opóźnienie sygnału wejściowego: dotyczy wszystkich klatek renderowanych dłużej niż 16 ms. Jest to stosunek liczby zdarzeń przesłania sygnałów wejściowych, które trwały dłużej niż 24 ms, do liczby klatek.
• Powolny wątek UI: dotyczy wszystkich klatek renderowanych dłużej niż 16 ms. Jest to stosunek liczby przypadków, gdy wykonanie wątków UI trwało dłużej niż 8 ms, do liczby klatek.
• Powolne przesyłanie poleceń rysowania: dotyczy wszystkich klatek renderowanych dłużej niż 16 ms. Jest to stosunek liczby przypadków, gdy przesłanie polecenia rysowania do GPU trwało dłużej niż 12 ms, do liczby klatek.
• Powolne przesyłanie bitmap: dotyczy wszystkich klatek renderowanych dłużej niż 16 ms. Jest to stosunek liczby przypadków, gdy przesłanie bitmapy do GPU trwało dłużej niż 3,2 ms, do liczby klatek.

Rozwiązywanie problemu

Jeśli w przypadku aplikacji występuje duża liczba klatek z czasem renderowania dłuższym niż 16 ms, poszukaj rozwiązań na stronie dla deweloperów aplikacji na Androida.

Nadmierna liczba zablokowanych klatek [tylko aplikacje]

Przeglądanie danych o aplikacji

Na stronie Nadmierna liczba spowolnionych klatek znajdują się szczegółowe informacje o odsetku sesji dziennych, podczas których u użytkowników wystąpiło ponad 50% klatek wyrenderowanych z opóźnieniem w stosunku do nominalnego czasu renderowania na urządzeniu. Podczas czynności wykonywanych przez użytkownika aplikacja powinna być wyświetlana z szybkością 60 klatek na sekundę bez pominięcia lub opóźnienia jakichkolwiek klatek.

Szczegółowe informacje o zbieraniu danych

Google zbiera dane o czasie renderowania każdej klatki przez aplikację za pomocą platformy zestawu narzędzi interfejsu. Klatki wyrenderowane bezpośrednio z wykorzystaniem interfejsu OpenGL lub Vulkan nie są brane pod uwagę.

Panel

Jeśli wybierzesz wiersz, zobaczysz dane wyrażone w percentylach.

• Liczba pasujących sesji: procent sesji dziennych, podczas których u użytkowników wystąpiło ponad 50% klatek z czasem renderowania dłuższym niż 16 ms. Sesja dzienna oznacza dzień, w którym aplikacja była używana. Jeśli na przykład 2 użytkowników będzie korzystać z aplikacji przez 2 dni, w rezultacie da to 4 sesje dzienne.
• Liczba sesji: przybliżona liczba zarejestrowanych sesji.
• 90/99 centyl: 90%/99% łącznej liczby klatek miało czas renderowania krótszy niż pokazywana liczba. Te liczby są oparte na wszystkich zebranych klatkach.

Jeśli klikniesz wpis w tabeli, pokaże się wykres „Rozkład czasu renderowania interfejsu”. Najlepiej, gdy większość klatek aplikacji jest wyświetlanych w czasie 16 ms lub krócej.

Dane pod wykresem przedstawiają informacje o wydajności renderowania aplikacji i mogą Ci pomóc w znalezieniu głównej przyczyny problemów ze zbyt długim renderowaniem. Jeśli na przykład odsetek „Dużych opóźnień sygnału wejściowego” jest wysoki, przyjrzyj się kodowi aplikacji, który obsługuje wprowadzanie danych przez użytkowników. Aby dowiedzieć się więcej o tych danych, przeczytaj artykuł o testowaniu wydajności UI.

• Pominięte synchronizacje Vsync: dotyczy wszystkich klatek renderowanych dłużej niż 16 ms. Jest to stosunek liczby pominiętych zdarzeń Vsync do liczby klatek.
• Duże opóźnienie sygnału wejściowego: dotyczy wszystkich klatek renderowanych dłużej niż 16 ms. Jest to stosunek liczby zdarzeń przesłania sygnałów wejściowych, które trwały dłużej niż 24 ms, do liczby klatek.
• Powolny wątek UI: dotyczy wszystkich klatek renderowanych dłużej niż 16 ms. Jest to stosunek liczby przypadków, gdy wykonanie wątków UI trwało dłużej niż 8 ms, do liczby klatek.
• Powolne przesyłanie poleceń rysowania: dotyczy wszystkich klatek renderowanych dłużej niż 16 ms. Jest to stosunek liczby przypadków, gdy przesłanie polecenia rysowania do GPU trwało dłużej niż 12 ms, do liczby klatek.
• Powolne przesyłanie bitmap: dotyczy wszystkich klatek renderowanych dłużej niż 16 ms. Jest to stosunek liczby przypadków, gdy przesłanie bitmapy do GPU trwało dłużej niż 3,2 ms, do liczby klatek.

Rozwiązywanie problemu

Jeśli w przypadku aplikacji występuje duża liczba klatek z czasem renderowania dłuższym niż 16 ms, poszukaj rozwiązań na stronie dla deweloperów aplikacji na Androida.

Wykorzystanie baterii

Ciągłe blokady uśpienia i ciągłe częściowe blokady uśpienia (w tle)

Strony Ciągłe częściowe blokady uśpienia i Ciągłe częściowe blokady uśpienia (w tle) pokazują częściowe blokady uśpienia wywołane w aplikacji przez klasę PowerManager. Dzięki częściowej blokadzie uśpienia procesor może działać, podczas gdy podświetlenie ekranu i klawiatury jest wyłączone.

Szczegółowe informacje o zbieraniu danych

• Ze względu na zachowanie prywatności tagi identyfikacyjne częściowych blokad uśpienia są anonimowe.
• Dane o częściowych blokadach uśpienia są zbierane, gdy bateria urządzenia się nie ładuje, a jego ekran jest wyłączony.
• Dane o częściowych blokadach uśpienia (w tle) są zbierane tylko wtedy, gdy aplikacja działa w tle.
• Google oblicza maksymalny czas trwania częściowej blokady uśpienia w czasie sesji baterii, aby pokazać, w jak wielu sesjach występuje długa blokada uśpienia. Jeśli na przykład użytkownik powoduje uruchomienie blokady uśpienia trwającej 2 godziny, Google użyje wartości maksymalnej równej 1 godzinie.
• W przypadku aplikacji, które w pliku manifestu mają określony identyfikator sharedUserId: dane pokazują się tylko wtedy, gdy zainstalowana jest maksymalnie jedna aplikacja z tym samym identyfikatorem sharedUserId.

Dane Android Vitals

• Liczba pasujących sesji: procent sesji baterii, podczas których u użytkowników wystąpiła co najmniej jedna blokada uśpienia trwająca ponad godzinę.
• Liczba sesji: przybliżona liczba zarejestrowanych sesji.
• 90/99 centyl: 10%/1% sesji dziennych, podczas których czas trwania częściowej blokady uśpienia u użytkowników był dłuższy niż pokazywana liczba.
• Próg niewłaściwego działania: jeśli odsetek wystąpień w aplikacji jest równy lub wyższy niż wyświetlony próg, aplikacja należy do dolnych 25% spośród 1000 najczęściej instalowanych aplikacji w Google Play.

Rozwiązywanie problemu

Jeśli w aplikacji często występują ciągłe częściowe blokady uśpienia, poszukaj rozwiązań na stronie dla programistów aplikacji na Androida.

Zbyt częste wybudzenia

Strona Zbyt częste wybudzenia pokazuje wybudzenia aplikacji Alarm Manager uruchomione przez aplikację. Dane wybudzeń dotyczą klas ELAPSED_REALTIME_WAKEUP lub RTC_WAKEUP.

Szczegółowe informacje o zbieraniu danych

• Ze względu na zachowanie prywatności tagi identyfikacyjne wybudzeń są anonimowe.
• Dane o wybudzeniach są zbierane, gdy bateria urządzenia się nie ładuje.
• Aby przedstawić znormalizowane dane, liczba wybudzeń jest porównywana do czasu, w którym urządzenie korzysta z zasilania z baterii. Google oblicza liczbę wybudzeń na użytkownika w ciągu godziny, by pokazać, u jak wielu użytkowników występuje duża częstotliwość wybudzeń.
• W przypadku aplikacji, które w pliku manifestu mają określony identyfikator sharedUserId: dane pokazują się tylko wtedy, gdy zainstalowana jest maksymalnie jedna aplikacja z tym samym identyfikatorem sharedUserId.

Dane Android Vitals

• Liczba pasujących sesji: procent sesji baterii, podczas których u użytkowników wystąpiło ponad 10 wybudzeń na godzinę. Sesja baterii to zbiór wszystkich raportów o stanie baterii, które zostały odebrane w ciągu danego 24-godzinnego okresu. W Androidzie 10 raport o stanie baterii odnosi się do przedziału czasu między dwoma ładowaniami baterii od poziomu naładowania poniżej 20% do powyżej 80% lub od dowolnego poziomu do 100%. W Androidzie 11 i nowszych raporty o stanie baterii odnoszą się do okresu o stałej długości 24 godzin. Google zbiera te dane tylko wtedy, gdy urządzenie nie jest podłączone do ładowarki.
• Liczba sesji: przybliżona liczba zarejestrowanych sesji.
• 90/99 centyl: 10%/1% sesji dziennych, podczas których liczba wybudzeń na godzinę u użytkownika była większa niż pokazywana wartość.
• Próg niewłaściwego działania: jeśli odsetek wystąpień w aplikacji jest równy lub wyższy niż wyświetlony próg, aplikacja należy do dolnych 25% spośród 1000 najczęściej instalowanych aplikacji w Google Play.

Rozwiązywanie problemu

Jeśli w przypadku aplikacji często występują wybudzenia, poszukaj rozwiązań na stronie dla programistów aplikacji na Androida.

Nadmierne skanowania Wi-Fi (w tle)

Strona Nadmierne skanowania Wi-Fi (w tle) pokazuje, kiedy skanowania Wi-Fi wpływają na większe wykorzystanie baterii.

Szczegółowe informacje o zbieraniu danych

Dane o skanowaniu Wi-Fi są zbierane, gdy bateria urządzenia się nie ładuje, a aplikacja działa w tle.

Dane Android Vitals

• Liczba pasujących sesji: odsetek sesji baterii, podczas których u użytkowników wystąpiły ponad 4 skanowania Wi-Fi na godzinę.
• Liczba sesji: przybliżona liczba zarejestrowanych sesji.
• 90/99 centyl: 10%/1% sesji dziennych, podczas których liczba skanowań Wi-Fi w tle na godzinę u użytkowników była większa niż pokazywana liczba.

Rozwiązywanie problemu

Jeśli aplikacja ma wysoką liczbę skanowań Wi-Fi w tle, poszukaj rozwiązań na stronie dla deweloperów aplikacji na Androida.

Nadmierne użycie sieci (w tle)

Strona Nadmierne użycie sieci pokazuje, kiedy usługa w tle zużywa dużą ilość danych sieciowych. Jeśli wykorzystanie danych sieci komórkowej odbywa się w tle, użytkownicy nie mogą w łatwy sposób wyłączyć ich transferu.

Szczegółowe informacje o zbieraniu danych

Dane o użyciu sieci komórkowej są zbierane, gdy bateria urządzenia się nie ładuje, a aplikacja działa w tle.

Dane Android Vitals

• Liczba pasujących sesji: procent sesji baterii, podczas których u użytkowników wystąpiło pobranie ponad 50 MB danych sieci komórkowej w tle dziennie.
• Liczba sesji: przybliżona liczba zarejestrowanych sesji.
• 90/99 centyl: 10%/1% sesji dziennych, podczas których dzienne użycie danych sieci komórkowej w tle u użytkowników było większe niż pokazywana liczba.

Rozwiązywanie problemu

Jeśli aplikacja wykazuje duże użycie sieci w tle, poszukaj rozwiązań na stronie dla deweloperów aplikacji na Androida.

Uprawnienia

Odmowy przyznania uprawnień

Na stronie Odmowy przyznania uprawnień są wyświetlane szczegóły na temat procentu dziennych sesji uprawnień, podczas których użytkownicy odmówili ich przyznania. Dzienna sesja uprawnień oznacza dzień, w którym Twoja aplikacja co najmniej raz poprosiła użytkownika o przyznanie uprawnień.

Szczegółowe informacje o zbieraniu danych

Dane o odmowach przyznania uprawnień są gromadzone, gdy użytkownicy odpowiadają na prośby o przyznanie uprawnień w aplikacji.

Dane Android Vitals

• Odmowy: procent sesji uprawnień dziennie, podczas których użytkownicy odmówili przyznania uprawnień.
• Nie pytaj ponownie: procent dziennych sesji uprawnień, podczas których użytkownicy odmówili przyznania uprawnień, wybierając opcję Nie pytaj ponownie.
• Łączna liczba sesji: przybliżona liczba zarejestrowanych sesji.

Rozwiązywanie problemu

Jeśli w aplikacji często występują odmowy przyznania uprawnień, poszukaj rozwiązań na stronie dla deweloperów aplikacji na Androida.

Progi niewłaściwego działania dotyczące podstawowych wskaźników

W Google Play obowiązują progi niewłaściwego działania dotyczące podstawowych wskaźników aplikacji.

Jeśli Twoja aplikacja przekracza próg niewłaściwego działania, prawdopodobnie będzie trudniejsza do odkrycia w Google Play. Jeśli Twoja aplikacja działa niewłaściwie na określonych modelach urządzeń, Google Play skieruje użytkowników tych urządzeń do innych, lepiej dostosowanych aplikacji. W niektórych przypadkach w informacjach o aplikacji może wyświetlać się ostrzeżenie, aby użytkownicy wiedzieli, czego mogą się spodziewać, wraz z opcją wyszukania alternatywnych aplikacji o wyższej jakości technicznej.

Podczas oceny jakości aplikacji Google Play bierze zwykle pod uwagę dane z ostatnich 28 dni. W przypadku nagłego wzrostu może działać szybciej.

Zwiń wszystko Rozwiń wszystko

Stabilność

Progi dotyczące częstotliwości błędów ANR postrzeganej przez użytkowników

W Google Play obowiązują progi niewłaściwego działania dotyczące częstotliwości błędów ANR widocznych dla użytkowników:

• Niewłaściwe działanie na poziomie ogólnym: błąd ANR widoczny dla użytkowników wystąpił u co najmniej 0,47% aktywnych użytkowników dziennie na wszystkich modelach urządzeń.

• Niewłaściwe działanie na poziomie urządzenia: błąd ANR widoczny dla użytkowników wystąpił u co najmniej 8% aktywnych użytkowników dziennie na 1 modelu urządzenia.

Aby ograniczyć częstotliwość błędów ANR, napraw błędy w podstawowych klastrach ANR zgłaszanych na stronie Awarie i błędy ANR. Im większa liczba użytkowników, których dotyczy problem, tym bardziej dany klaster przyczynia się do częstotliwości błędów ANR.

Jeśli określone aspekty sprzętu lub oprogramowania urządzenia mogą wpływać na częstotliwość błędów ANR, Android Vitals Cię o tym powiadomi. Możesz też samodzielnie przeglądać powiązania na stronie Zasięg i urządzenia – przegląd (Wersja > Zasięg i urządzenia > Przegląd).

Progi dotyczące częstotliwości awarii postrzeganej przez użytkowników

W Google Play obowiązują progi niewłaściwego działania dotyczące częstotliwości awarii widocznych dla użytkowników:

• Niewłaściwe działanie na poziomie ogólnym: awaria widoczna dla użytkowników wystąpiła u co najmniej 1,09% użytkowników dziennie na wszystkich modelach urządzeń.

• Niewłaściwe działanie na poziomie urządzenia: awaria widoczna dla użytkowników wystąpiła u co najmniej 8% użytkowników dziennie na 1 modelu urządzenia.

Aby ograniczyć częstotliwość awarii, napraw błędy w klastrach powiązanych z awarią zgłoszonych na stronie Awarie i błędy ANR. Im większa liczba użytkowników, których dotyczy problem, tym bardziej dany klaster przyczynia się do częstotliwości awarii.

Jeśli określone aspekty sprzętu lub oprogramowania urządzenia mogą wpływać na częstotliwość awarii, Android Vitals Cię o tym powiadomi. Możesz też samodzielnie przeglądać powiązania na stronie Zasięg i urządzenia – przegląd (Wersja > Zasięg i urządzenia > Przegląd).

Powiązane materiały

Poznaj sprawdzone metody korzystania z Android Vitals do poprawy działania i stabilności aplikacji.