Rozwiązywanie problemów z monitorowaniem wydajności i najczęstsze pytania

Jak wyświetlać komunikaty z dziennika dotyczące zdarzeń związanych z wydajnością

1. Aby włączyć rejestrowanie debugowania dla Performance Monitoring w momencie kompilacji, dodaj element <meta-data> do pliku AndroidManifest.xml aplikacji w ten sposób:

   <application>
       <meta-data
         android:name="firebase_performance_logcat_enabled"
         android:value="true" />
   </application>

2. Sprawdź, czy w logach nie ma komunikatów o błędach.

3. Performance Monitoring oznacza swoje komunikaty dziennika tagiem FirebasePerformance. Za pomocą filtrowania logcat możesz wyświetlić ślad długości trwania i logowanie zapytań sieci HTTP/S, uruchamiając to polecenie:

   adb logcat -s FirebasePerformance

4. Sprawdź, czy występują te typy dzienników, które wskazują, że Performance Monitoring rejestruje zdarzenia dotyczące skuteczności:

   • Logging trace metric: TRACE_NAME, FIREBASE_PERFORMANCE_CONSOLE_URL
   • Logging network request trace: URL

5. Kliknij adres URL, aby wyświetlić dane w konsoli Firebase. Dane mogą się zaktualizować w panelu dopiero po kilku minutach.

Jeśli Twoja aplikacja nie rejestruje zdarzeń związanych z wydajnością, zapoznaj się z wskazówkami dotyczącymi rozwiązywania problemów.

Dodano pakiet SDK do aplikacji, ale w konsoli nadal wyświetla się komunikat o konieczności dodania pakietu SDK

Firebase może wykryć, czy do aplikacji Performance Monitoring dodano pakiet SDK, gdy otrzyma z niej informacje o zdarzeniach (np. interakcjach z aplikacją). Zazwyczaj w ciągu 10 minut od uruchomienia aplikacji na stronie Wydajność w konsoliFirebase pojawi się komunikat „Wykryty pakiet SDK”. Następnie w ciągu 30 minut panel wyświetla wstępnie przetworzone dane.

Jeśli od dodania do aplikacji najnowszej wersji pakietu SDK minęło ponad 10 minut, a nadal nie widać żadnych zmian, sprawdź logi, aby się upewnić, że Performance Monitoring rejestruje zdarzenia. Aby rozwiązać problem z opóźnionym wykryciem pakietu SDK, wykonaj odpowiednie czynności opisane poniżej.

Konsola informuje, że pakiet SDK został wykryty, ale nie wyświetla żadnych danych

Performance Monitoring przetwarza dane o wydarzeniu skuteczności przed wyświetleniem ich w panelu Skuteczność.

Jeśli od pojawienia się komunikatu „Wykryto pakiet SDK” minęło ponad 24 godziny, a nadal nie widzisz danych, sprawdź panel stanu Firebase, aby się dowiedzieć, czy nie ma tam żadnej znanej awarii. Jeśli nie ma przerwy w działaniu usługi, skontaktuj się z zespołem pomocy Firebase.

Aplikacja nie rejestruje zdarzeń dotyczących wydajności

Jeśli nie widzisz wiadomości z dziennika dotyczących zdarzeń związanych z wydajnością, wykonaj te czynności:

1. Sprawdź konfigurację wtyczki Performance Monitoring Gradle w ten sposób:

   1. Sprawdź, czy wtyczka została dodana prawidłowo. Sprawdź te kwestie:

      • Dodano wtyczkę (apply plugin: 'com.google.firebase.firebase-perf') w pliku build.gradle modułu (na poziomie aplikacji).
      • Do pliku build.gradle na poziomie projektu dodano zależność classpath dla wtyczki (classpath 'com.google.firebase:perf-plugin:1.4.2').

   2. Upewnij się, że wtyczka nie jest wyłączona za pomocą żadnego z tych flag:

      • instrumentationEnabled w pliku build.gradle (na poziomie aplikacji) modułu
      • firebasePerformanceInstrumentationEnabled w pliku gradle.properties

2. Sprawdź, czy pakiet SDK Performance Monitoring nie jest wyłączony za pomocą jednego z tych flag w pliku AndroidManifest.xml:

   • firebase_performance_collection_enabled
   • firebase_performance_collection_deactivated

3. Upewnij się, że Performance Monitoring nie jest wyłączony w czasie wykonywania.

4. Jeśli nie możesz znaleźć w aplikacji niczego, co jest wyłączone, skontaktuj się z zespołem pomocy Firebase.

Brak danych z wykresu skuteczności dotyczących śledzenia ekranu

Jeśli brakuje danych dotyczących śledzenia renderowania ekranu, wykonaj te czynności:

1. Upewnij się, że używasz najnowszej wersji pakietu SDK Androida (21.0.3). Ścieżki renderowania ekranu są dostępne tylko w wersji 15.2.0 lub nowszej.

2. Upewnij się, że akseleracja sprzętowa nie została wyłączona ręcznie na ekranie.

3. Upewnij się, że nie używasz DexGuard ani Jack. Performance Monitoring jest niezgodna z tymi zestawami narzędzi.

   • DexGuard wyłącza automatyczne zbieranie informacji o uruchamianiu aplikacji, jej działaniu na pierwszym planie i w tle. Jeśli jednak aplikacja korzysta z DexGuard, ścieżki kodu niestandardowego powinny działać normalnie.

   • Jack został wycofany i zwykle nie należy go używać w aplikacji.

W panelu skuteczności brakuje danych z niestandardowego śledzenia

Czy widzisz dane o skuteczności dla automatycznie zebranych ścieżek, ale nie dla ścieżek kodu niestandardowego? Wypróbuj te rozwiązania:

1. Jeśli ścieżki niestandardowego kodu zostały zinstrumentowane za pomocą Trace API, sprawdź konfigurację ścieżek, zwłaszcza te elementy:

   • Nazwy niestandardowych ścieżek kodu i niestandardowych danych muszą spełniać te wymagania: nie mogą zawierać spacji na początku ani na końcu, nie mogą zawierać znaku podkreślenia na początku (_), a ich maksymalna długość to 32 znaki.
   • Wszystkie ścieżki muszą być rozpoczęte i zakończone. Nie rejestruje się żadnych ścieżek, które nie zostały rozpoczęte, zatrzymane lub zatrzymane przed rozpoczęciem.

2. Jeśli za pomocą @AddTrace notacji instrumentowałeś niestandardowe logi kodu, sprawdź konfigurację wtyczki Performance Monitoring Gradle:

   1. Upewnij się, że wtyczka została prawidłowo dodana. Sprawdź te kwestie:

      • Dodano wtyczkę (apply plugin: 'com.google.firebase.firebase-perf') w pliku build.gradle modułu (na poziomie aplikacji).
      • Do pliku build.gradle na poziomie projektu dodano zależność classpath dla wtyczki (classpath 'com.google.firebase:perf-plugin:1.4.2').

   2. Upewnij się, że wtyczka nie jest wyłączona za pomocą żadnego z tych flag:

      • instrumentationEnabled w pliku build.gradle (na poziomie aplikacji) modułu
      • firebasePerformanceInstrumentationEnabled w pliku gradle.properties

3. Sprawdź komunikaty w logach, aby się upewnić, że Performance Monitoring rejestruje oczekiwane ślady kodu niestandardowego.

4. Jeśli Performance Monitoring rejestruje zdarzenia, ale po 24 godzinach nie wyświetla się żadna informacja, skontaktuj się z zespołem pomocy Firebase.

W panelu skuteczności brakuje danych o żądaniach sieci

Jeśli brakuje Ci danych o żądaniu sieci, wykonaj te czynności:

1. W przypadku aplikacji na Androida wtyczka Gradle Performance Monitoring umożliwia użycie instrumentacji, która zapewnia automatyczne monitorowanie żądań HTTP/S. Sprawdź te kwestie:

   1. Upewnij się, że wtyczka została prawidłowo dodana. Sprawdź te kwestie:

      • Dodano wtyczkę (apply plugin: 'com.google.firebase.firebase-perf') w pliku build.gradle modułu (na poziomie aplikacji).
      • Do pliku build.gradle na poziomie projektu dodano zależność classpath dla wtyczki (classpath 'com.google.firebase:perf-plugin:1.4.2').

   2. Upewnij się, że wtyczka nie jest wyłączona za pomocą żadnego z tych flag:

      • instrumentationEnabled w pliku build.gradle (na poziomie aplikacji) modułu
      • firebasePerformanceInstrumentationEnabled w pliku gradle.properties

2. Sprawdź, czy biblioteka sieciowa jest zgodna. Performance Monitoring automatycznie zbiera dane dotyczące żądań sieciowych, które korzystają z tych bibliotek sieciowych: OkHttp 3.x.x, Java's URLConnection i Apache HttpClient.

   Pamiętaj, że możesz dodać niestandardowe monitorowanie żądań sieciowych.

3. Pamiętaj:

   • W zależności od zachowania kodu i bibliotek sieciowych używanych przez kod Performance Monitoring może raportować tylko o żądaniach sieciowych, które zostały wykonane. Oznacza to, że połączenia HTTP/S, które pozostają otwarte, mogą nie zostać zgłoszone.

   • Performance Monitoring nie jest zgodna z DexGuard i Jack.

     • DexGuard wyłącza monitorowanie żądań sieciowych HTTP/S.
     • Jack został wycofany i zwykle nie należy go używać w aplikacji.

   • Performance Monitoring nie raportuje żądań sieciowych z nieprawidłowymi nagłówkami Content-Type. Nadal jednak będą akceptowane żądania sieci bez nagłówków Content-Type.

Dane żądań sieciowych nie są agregowane zgodnie z oczekiwaniami

Dowiedz się więcej o tym, jak Performance Monitoring agreguje dane dotyczące żądań sieci w ramach wzorca adresów URL.

Możesz też wypróbować niestandardowe wzorce adresów URL.

Co się stało z kartą Najważniejsze problemy na karcie Wydajność na stronie głównej projektu?

W nawiązaniu do naszego niedawnego wprowadzenia alertów, które automatycznie wysyłają powiadomienia po przekroczeniu ustawionych przez Ciebie progów, zastąpiliśmy Najczęstsze problemy Ostatnimi alertami. Problemy zostały wycofane i zastąpione przez alerty.

Selektor aplikacji u góry karty Skuteczność filtruje wpisy alertów w sekcji Ostatnie alerty. Wyświetlane są tylko 3 najnowsze alerty dotyczące wybranych aplikacji.

Więcej informacji o alertach znajdziesz w artykule Konfigurowanie alertów o problemach ze skutecznością.

Co się stało z możliwością ustawiania progów dla problemów w konsoli?

Performance Monitoring obsługuje alerty dotyczące danych, które przekraczają zdefiniowane progi. Aby uniknąć nieporozumień związanych z tymi konfigurowalnymi wartościami progowymi danych dotyczących skuteczności, usunęliśmy możliwość konfigurowania wartości progowych dla problemów.

Co się stało z informacjami Szczegóły i Dane w konsoli Firebase?

Zastąpiliśmy strony Szczegóły i Dane nowo zaprojektowanym, scentralizowanym interfejsem użytkownika, aby ułatwić rozwiązywanie problemów. Ten nowy interfejs rozwiązywania problemów zapewnia te same podstawowe funkcje, co interfejs Szczegóły i Dane. Więcej informacji o rozwiązywaniu problemów znajdziesz w artykule Wyświetlanie dodatkowych danych dotyczących konkretnego śledzenia.

Dlaczego liczba próbek nie jest zgodna z moimi oczekiwaniami?

Performance Monitoring zbiera dane o skuteczności z urządzeń użytkowników aplikacji. Jeśli Twoja aplikacja ma wielu użytkowników lub generuje dużą liczbę działań, Performance Monitoring może ograniczyć zbieranie danych do podzbioru urządzeń, aby zmniejszyć liczbę przetwarzanych zdarzeń. Te limity są wystarczająco wysokie, aby nawet przy mniejszej liczbie zdarzeń wartości danych nadal odzwierciedlały wrażenia użytkownika związane z aplikacją.

Aby zarządzać ilością danych, które zbieramy, Performance Monitoring używa tych opcji próbkowania:

• Ograniczenie częstotliwości na urządzeniu: aby zapobiec nagłem wysyłaniu przez urządzenie dużej liczby strumieni, ograniczamy liczbę strumieni kodu i żądań sieci wysyłanych z urządzenia do 300 zdarzeń na 10 minut. Takie podejście chroni urządzenie przed instrumentacją w pętli, która może wysyłać duże ilości danych o wydajności, oraz zapobiega zakłócaniu pomiarów wydajności przez pojedyncze urządzenie.

• Próbkowanie dynamiczne:Performance Monitoring codziennie zbiera ograniczoną liczbę ścieżek kodu i ścieżek żądań sieci w przypadku wszystkich użytkowników aplikacji. Na urządzeniach pobierana jest dynamiczna częstotliwość próbkowania (za pomocą funkcji Firebase Remote Config), aby określić, czy losowe urządzenie powinno rejestrować i przesyłać ścieżki. Urządzenie, które nie zostało wybrane do próbkowania, nie wysyła żadnych zdarzeń. Dynamiczny współczynnik próbkowania jest specyficzny dla aplikacji i dostosowuje się, aby zapewnić, że całkowita objętość zebranych danych nie przekroczy limitu.

  Projekty, w których włączono integrację z BigQuery, mają wyższy limit liczby śladów żądań sieciowych.

  Sesje użytkownika wysyłają dodatkowe, szczegółowe dane z urządzenia użytkownika, co wymaga więcej zasobów na ich przechwytywanie i przesyłanie. Aby zminimalizować wpływ sesji użytkownika, Performance Monitoring może też ograniczyć liczbę sesji.

• Ograniczenie szybkości po stronie serwera: aby aplikacje nie przekraczały limitu próbkowania, Performance Monitoring może używać próbkowania po stronie serwera, aby pomijać niektóre zdarzenia otrzymywane z urządzeń. Chociaż tego typu ograniczenie nie zmienia skuteczności naszych danych, może powodować drobne zmiany w wzorce, w tym:

  • Liczba śladów może się różnić od liczby razy, kiedy fragment kodu został wykonany.
  • Ścieżki, które są ściśle powiązane w kodzie, mogą mieć różną liczbę próbek.

Co się stało z kartą Problemy w konsoli?

Zamiast karty Problemy wprowadzamy kartę Ostrzeżenia, która automatycznie wysyła powiadomienia, gdy przekroczysz ustawione progi. Aby sprawdzić stan progu, nie musisz już ręcznie sprawdzać konsoli Firebase. Więcej informacji o alertach znajdziesz w artykule Konfigurowanie alertów o problemach ze skutecznością.

Co się stało z kartami Na urządzeniu i Sieć w konsoli? Jak wyświetlić ścieżki na tych stronach?

W konsoli Firebase zmieniliśmy wygląd sekcji Performance Monitoring, aby na karcie Panel wyświetlały się najważniejsze dane i wszystkie ścieżki w jednym miejscu. W ramach przeprojektowania usunęliśmy strony Na urządzeniu i Sieć.

Tabela prześledzeń u dołu karty Panel zawiera te same informacje, które są widoczne na kartach Na urządzeniu i Sieć, ale z dodatkowymi funkcjami, takimi jak możliwość sortowania prześledzeń według procentowej zmiany konkretnego rodzaju danych. Aby wyświetlić wszystkie dane i rodzaje danych dotyczące konkretnego śledzenia, kliknij jego nazwę w tabeli śledzenia.

Na tych podkartach tabeli śladów możesz wyświetlać ścieżki:

• Ślady żądań sieciowych (zarówno domyślne, jak i niestandardowe) – podkarta Żądania sieciowe.
• Ścieżki niestandardowego kodu – karta Ścieżki niestandardowe
• Ścieżki uruchamiania aplikacji, ścieżki aplikacji na pierwszym planie i ścieżki aplikacji działającej w tle – podkarta Ścieżki niestandardowe.
• Ścieżki renderowania ekranu – karta Renderowanie ekranu
• Ścieżki wczytywania strony – karta Wczytywanie strony

Szczegółowe informacje o tabeli prześwietleń oraz dane i metryki związane z wyświetlaniem znajdziesz na stronie przeglądu konsoli (iOS+ | Android | Sieć).

Dlaczego liczba wolno renderowanych i zablokowanych klatek nie jest zgodna z moim oczekiwaniami?

Czasy renderowania spowolnionych i zablokowanych klatek są obliczane przy założeniu częstotliwości odświeżania urządzenia wynoszącej 60 Hz. Jeśli częstotliwość odświeżania urządzenia jest niższa niż 60 Hz, czas renderowania każdej klatki będzie dłuższy, ponieważ w sekundzie wyrenderowanych zostanie mniej klatek. Wolniejsze czasy renderowania mogą powodować zgłaszanie większej liczby spowolnionych lub zablokowanych klatek, ponieważ więcej klatek będzie renderowanych wolniej lub zablokowanych. Jeśli jednak częstotliwość odświeżania urządzenia jest wyższa niż 60 Hz, czas renderowania każdej klatki będzie krótszy. Może to spowodować, że zgłoszonych zostanie mniej ujęć wolnych lub zablokowanych. Jest to obecne ograniczenie pakietu SDK Performance Monitoring.

Dlaczego nie widzę śladów fragmentów?

Aby oprócz aktywności aplikacji zobaczyć też wydajność fragmentów, sprawdź, czy Twoja aplikacja używa pakietu Android SDK w wersji 20.1.0 lub nowszej.Performance Monitoring Więcej informacji znajdziesz w artykule Dodawanie monitorowania wydajności do aplikacji.

Jak sprawdzić, które ślady są powiązane z fragmentami i aktywnościami?

Każdy z fragmentów i śladów aktywności jest oparty na nazwie klasy zdefiniowanej w aplikacji. Każdy z wykresów ekranu zawiera prefiks st, a za nim nazwę klasy. W konsoli Firebase prefiks jest usuwany. Więcej informacji znajdziesz w artykule Dane o skuteczności renderowania ekranu (aplikacje na urządzenia z systemem Android i Apple) .

Dlaczego widzę mniej ścieżek fragmentów niż innych ścieżek?

Performance Monitoring przeprowadza próbkowanie zdarzeń na podstawie wszystkich zdarzeń zebranych na urządzeniu. Dzięki temu możemy zbierać na urządzeniach użytkowników minimalną liczbę zdarzeń, która jest potrzebna do przedstawienia danych o skuteczności.

Jakie otrzymuję powiadomienia, gdy wystąpi problem z wydajnością renderowania mojej aplikacji?

Performance Monitoring pozwala konfigurować alerty dotyczące interesujących Cię wskaźników. W przypadku generowanych ścieżek renderowania ekranu możesz skonfigurować alerty, które będą Cię powiadamiać, gdy odsetek klatek z wydłużonym czasem renderowania lub zamrożonych klatek przekroczy ustawiony przez Ciebie próg.

Po włączeniu wtyczki Performance Monitoring Gradle czas kompilacji jest długi. Co mogę zrobić, aby to poprawić?

Performance Monitoring na Androida korzysta z instrumentacji kodu bajtowego, aby udostępniać niektóre funkcje domyślne, takie jak monitorowanie żądań sieciowych HTTP/S. W ramach kompilacji proces wymaga iteracji przez wszystkie klasy aplikacji (w tym zależności) w celu instrumentowania kodu, który jest kluczowy dla pomiaru wydajności żądań sieciowych aplikacji.

Oto kilka najważniejszych czynników, które mogą zwiększyć czas kompilacji:

• Liczba zajęć lub plików
• Rozmiar każdej z tych klas (wiersze kodu)
• Konfiguracja maszyny
• Początkowa kompilacja w porównaniu z kolejną kompilacją (kolejne kompilacje są zwykle szybsze niż początkowa)

Aby zoptymalizować czas kompilacji, rozważ modułowanie kodu.

Począwszy od wersji 1.3.3 wtyczki Performance Monitoring skupiliśmy się na znacznym ulepszaniu stopniowego przetwarzania kompilacji i buforowania danych wejściowych biblioteki. Aby korzystać z najnowszych ulepszeń czasu kompilacji, upewnij się, że używasz najnowszej wersji wtyczki (1.4.2).

Jeśli chcesz skrócić czas kompilacji, możesz wyłączyć wtyczkęPerformance Monitoring na potrzeby kompilacji debugowania na komputerze lokalnym. Nie zalecamy jednak stosowania tego podejścia w przypadku wersji produkcyjnych, ponieważ może to spowodować pominięcie pomiarów wydajności żądań sieci w aplikacji.

Co zrobić, jeśli występują błędy kompilacji z powodu niezgodnych z pluginem Gradle bibliotek?Performance Monitoring

Performance Monitoring na Androida korzysta z instrumentacji kodu bajtowego, aby udostępniać niektóre funkcje domyślne, takie jak monitorowanie żądań sieciowych HTTP/S. W ramach kompilacji proces wymaga iteracji przez wszystkie klasy aplikacji (w tym zależności) w celu instrumentowania kodu, który jest kluczowy dla pomiaru wydajności żądań sieciowych aplikacji.

Jeśli po integracji z wtyczką Performance Monitoring pojawią się błędy kompilacji, takie jak JSR/RET are not supported with computeFrames option, może to być spowodowane tym, że masz też zależność od biblioteki, która jest niezgodna z wtyczką Gradle Performance Monitoring.

Aby tego uniknąć, możesz wykluczyć z instrumentacji klasy lub biblioteki, które nie są zgodne. Aby to zrobić:

1. Zaktualizuj do najnowszej wersji wtyczki Performance Monitoring Gradle (co najmniej wersja 1.4.0).
2. Zaktualizuj wersję wtyczki Android Gradle do wersji 7.2.0 lub nowszej.
3. Aby wykluczyć z instrumentacji niezgodne klasy i biblioteki, dodaj do pliku build.gradle modułu (na poziomie aplikacji) ten parametr:

   android {
     // ...
     androidComponents {
       onVariants(selector().all(), {
           instrumentation.excludes.add("example.incompatible.library")
       })
     }
   }

   Aby dowiedzieć się więcej o właściwości exclude interfejsu Instrumentation API wtyczki Gradle na Androida, zapoznaj się z artykułem Instrumentacja.

Jeśli napotkasz błędy kompilacji z powodu niezgodnych bibliotek, zgłoś problem na GitHubie, aby można było wykluczyć je z instrumentacji w pluginie Performance Monitoring.

Dane Performance Monitoring są eksportowane do BigQuery dłużej niż oczekiwano. Czy nie jest to w czasie rzeczywistym?

Jeśli masz włączoną integrację BigQuery w Firebase Performance Monitoring, Twoje dane będą eksportowane do BigQuery w ciągu 12–24 godzin od zakończenia dnia (czasu pacyficznego).

Na przykład dane z 19 kwietnia będą dostępne w BigQuery 20 kwietnia w godzinach 12:00–24:00 (wszystkie daty i godziny podane są w czasie pacyficznym).

Co oznaczają dane o wydajności otrzymywane niemal w czasie rzeczywistym?

Firebase Performance Monitoring przetwarza gromadzone dane o skuteczności w miarę ich napływania, dzięki czemu dane są wyświetlane w konsoli Firebase w czasie zbliżonym do rzeczywistego. Przetworzone dane wyświetlają się w konsoli w ciągu kilku minut od ich zebrania, stąd termin „prawie w czasie rzeczywistym”.

Aby korzystać z przetwarzania danych w czasie zbliżonym do rzeczywistego, upewnij się, że Twoja aplikacja korzysta z wersji pakietu SDK zgodnego z czasem rzeczywistym.

Jak mogę uzyskać dane o skuteczności mojej aplikacji w czasie zbliżonym do rzeczywistego?

Aby korzystać z przetwarzania danych w czasie zbliżonym do rzeczywistego, musisz tylko sprawdzić, czy Twoja aplikacja używa pakietu SDK Performance Monitoring w wersji zgodnej z przetwarzaniem danych w czasie rzeczywistym.

Oto wersje pakietu SDK, które obsługują działanie w czasie rzeczywistym:

• iOS – wersja 7.3.0 lub nowsza.
• tvOS – wersja 8.9.0 lub nowsza.
• Android – wersja 19.0.10 lub nowsza (lub Firebase Android BoM 26.1.0 lub nowsza)
• Wersja internetowa – wersja 7.14.0 lub nowsza

Pamiętaj, że zawsze zalecamy używanie najnowszej wersji pakietu SDK, ale każda wersja wymieniona powyżej umożliwi Performance Monitoring przetwarzanie danych w czasie zbliżonym do rzeczywistego.

Które wersje pakietu SDK Performance Monitoring są uznawane za kompatybilne z czasem rzeczywistym?

Oto wersje pakietu SDK, które obsługują przetwarzanie danych w czasie rzeczywistym:

• iOS – wersja 7.3.0 lub nowsza.
• tvOS – wersja 8.9.0 lub nowsza.
• Android – wersja 19.0.10 lub nowsza (lub Firebase Android BoM 26.1.0 lub nowsza)
• Wersja internetowa – wersja 7.14.0 lub nowsza

Pamiętaj, że zawsze zalecamy używanie najnowszej wersji pakietu SDK, ale każda wersja wymieniona powyżej umożliwi Performance Monitoring przetwarzanie danych w czasie zbliżonym do rzeczywistego.

Co się stanie, jeśli nie zaktualizuję aplikacji, aby używała wersji pakietu SDK zgodnej z czasem rzeczywistym?

Jeśli Twoja aplikacja nie korzysta z wersji pakietu SDK zgodnej z czasem rzeczywistym, nadal będziesz mieć widoczne wszystkie dane o jej działaniu w konsoli Firebase. Wyświetlanie danych o skuteczności będzie jednak opóźnione o około 36 godzin od momentu ich zebrania.

Zaktualizowałem/zaktualizowałam pakiet SDK do wersji zgodnej z czasem rzeczywistym, ale niektórzy użytkownicy nadal korzystają ze starszych wersji aplikacji. Czy nadal będę widzieć dane o jej działaniu w konsoli Firebase?

Tak. Bez względu na to, z której wersji pakietu SDK korzysta instancja aplikacji, zobaczysz dane o wydajności pochodzące od wszystkich użytkowników.

Jeśli jednak wyświetlane są najnowsze dane (starsze mniej więcej niż 36 godzin), wyświetlane dane pochodzą od użytkowników instancji aplikacji korzystających z kompatybilnej z czasem rzeczywistym wersji pakietu SDK. Dane niezwiązane z obecnością obejmują jednak dane o skuteczności ze wszystkich wersji aplikacji.