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

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

1. Włącz logowanie debugowania dla Performance Monitoring podczas kompilacji, dodając 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 komunikatach logu nie ma komunikatów o błędach.

3. Performance Monitoring oznacza komunikaty logu tagiem FirebasePerformance. Korzystając z filtrowania logcat, możesz wyświetlić ślad czasu trwania i logowanie żądań sieciowych HTTP/S, uruchamiając to polecenie:

   adb logcat -s FirebasePerformance

4. Sprawdź, czy występują te typy logów, które wskazują, że Performance Monitoring rejestruje zdarzenia związane z wydajnoś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. Zanim dane zostaną zaktualizowane w panelu, może minąć kilka minut.

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

Pakiet SDK do wyświetlania reklam został dodany do aplikacji, ale w konsoli nadal wyświetla się komunikat o konieczności dodania pakietu SDK do wyświetlania reklam

Firebase może wykryć, czy pakiet SDK Performance Monitoring został pomyślnie dodany do aplikacji, gdy otrzyma z niej informacje o zdarzeniach (np. interakcjach z aplikacją). Zwykle w ciągu 10 minut od uruchomienia aplikacji w panelu wydajności konsoli Firebase pojawi się komunikat „Wykryto pakiet SDK”. Następnie w ciągu 30 minut na panelu pojawią się pierwsze przetworzone dane.

Jeśli od dodania najnowszej wersji pakietu SDK do aplikacji minęło więcej niż 10 minut i nadal nie widzisz żadnych zmian, sprawdź komunikaty logu, aby upewnić się, że Performance Monitoring rejestruje zdarzenia. Aby rozwiązać problem z opóźnionym komunikatem o wykryciu pakietu SDK, wykonaj odpowiednie czynności opisane poniżej.

Konsola informuje, że pakiet SDK został wykryty, ale nie wyświetlają się żadne dane

Performance Monitoring przetwarza dane zdarzeń dotyczących wydajności, zanim wyświetli je w panelu wydajności.

Jeśli od wyświetlenia komunikatu „Wykryto pakiet SDK” minęło ponad 24 godziny, a dane nadal nie są widoczne, sprawdź panel stanu Firebase, aby dowiedzieć się, czy nie wystąpiła znana przerwa w działaniu. Jeśli nie ma przerwy w działaniu, skontaktuj się z zespołem pomocy Firebase.

Aplikacja nie rejestruje zdarzeń związanych z wydajnością

Jeśli nie widzisz komunikatów logu dotyczących zdarzeń związanych z wydajnością, wykonaj te czynności rozwiązywania problemów:

1. Sprawdź konfigurację wtyczki Performance Monitoring do Gradle:

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

      • Wtyczka (apply plugin: 'com.google.firebase.firebase-perf') została dodana w pliku build.gradle modułu (na poziomie aplikacji).
      • W pliku build.gradle na poziomie projektu uwzględniono zależność ścieżki klasy dla wtyczki (classpath 'com.google.firebase:perf-plugin:2.0.2').

   2. Upewnij się, że wtyczka nie jest wyłączona przez żadną z tych flag:

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

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

   • firebase_performance_collection_enabled
   • firebase_performance_collection_deactivated

3. Upewnij się, że Performance Monitoring nie jest wyłączone w czasie działania.

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

W panelu wydajności brakuje danych śledzenia ekranu

Jeśli brakuje danych dotyczących śladów renderowania ekranu, wypróbuj następujące kroki rozwiązywania problemów:

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

2. Upewnij się, że nie wyłączono ręcznie akceleracji sprzętowej na ekranie.

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

   • DexGuard wyłącza automatyczne zbieranie śladów uruchamiania aplikacji, aplikacji na pierwszym planie i aplikacji w tle. Jeśli jednak aplikacja używa DexGuard, wszystkie ślady kodu niestandardowego powinny działać normalnie.

   • Jack jest wycofany i nie powinien być używany w aplikacji.

W panelu wydajności brakuje niestandardowych danych śledzenia

Czy widzisz dane o skuteczności dotyczące automatycznie zbieranych logów czasu, ale nie logów czasu niestandardowego kodu? Wykonaj następujące czynności rozwiązywania problemów:

1. Jeśli ślady kodu niestandardowego zostały zinstrumentowane za pomocą interfejsu Trace API, sprawdź konfigurację śladów, a zwłaszcza te elementy:

   • Nazwy niestandardowych śladów kodu i wskaźników niestandardowych muszą spełniać te wymagania: nie mogą zawierać spacji na początku ani na końcu, nie mogą zaczynać się od znaku podkreślenia (_) i mogą mieć maksymalnie 32 znaki.
   • Wszystkie logi czasu muszą zostać uruchomione i zatrzymane. Ślady, które nie zostały uruchomione, zatrzymane lub zatrzymane przed uruchomieniem, nie będą rejestrowane.

2. Jeśli ślady niestandardowego kodu zostały zinstrumentowane za pomocą notacji @AddTrace, sprawdź konfigurację wtyczki Performance Monitoring do Gradle:

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

      • Wtyczka (apply plugin: 'com.google.firebase.firebase-perf') została dodana w pliku build.gradle modułu (na poziomie aplikacji).
      • W pliku build.gradle na poziomie projektu uwzględniono zależność ścieżki klasy dla wtyczki (classpath 'com.google.firebase:perf-plugin:2.0.2').

   2. Upewnij się, że wtyczka nie jest wyłączona przez żadną z tych flag:

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

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

4. Jeśli Performance Monitoring rejestruje zdarzenia, ale po 24 godzinach nie wyświetlają się żadne dane, skontaktuj się z zespołem pomocy Firebase.

W panelu wydajności brakuje danych o żądaniach sieciowych

Jeśli brakuje danych żądań sieciowych, wykonaj te czynności rozwiązywania problemów:

1. W przypadku aplikacji na Androida wtyczka Gradle Performance Monitoring umożliwia instrumentację, która zapewnia automatyczne monitorowanie żądań sieciowych HTTP/S. Sprawdź, czy:

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

      • Wtyczka (apply plugin: 'com.google.firebase.firebase-perf') została dodana w pliku build.gradle modułu (na poziomie aplikacji).
      • W pliku build.gradle na poziomie projektu uwzględniono zależność ścieżki klasy dla wtyczki (classpath 'com.google.firebase:perf-plugin:2.0.2').

   2. Upewnij się, że wtyczka nie jest wyłączona przez żadną z tych flag:

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

2. Sprawdź, czy biblioteka sieciowa jest zgodna. Performance Monitoring automatycznie zbiera dane o żądaniach sieciowych, które korzystają z tych bibliotek sieciowych: OkHttp 3.x.x, URLConnection w języku Java i Apache HttpClient.

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

3. Pamiętaj:

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

   • Performance Monitoring nie jest zgodny z DexGuard i Jack.

     • DexGuard wyłącza monitorowanie żądań sieciowych HTTP/S.
     • Jack jest wycofany i nie powinien być używany w aplikacji.

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

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

Dowiedz się więcej o tym, jak Performance Monitoring agreguje dane żądań sieciowych we wzorcach adresów URL.

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

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

Zastąpiliśmy Najważniejsze problemy Ostatnimi alertami, ponieważ niedawno wprowadziliśmy alerty, które automatycznie powiadamiają Cię o przekroczeniu ustawionych progów. Problemy zostały wycofane i zastąpione alertami.

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 dotyczących problemów z wydajnoś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ą określone progi. Aby uniknąć nieporozumień związanych z tymi konfigurowalnymi progami wskaźników skuteczności, usunęliśmy możliwość konfigurowania progów dla problemów.

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

Zastąpiliśmy strony Szczegóły i Dane nowym, scentralizowanym interfejsem, aby ułatwić rozwiązywanie problemów. Ten nowy interfejs rozwiązywania problemów oferuje tę samą główną funkcjonalność, która była dostępna w sekcjach Szczegóły i Dane. Więcej informacji o rozwiązywaniu problemów znajdziesz w artykule Wyświetlanie dodatkowych danych dotyczących konkretnego logu czasu oczekiwania.

Dlaczego liczba próbek nie jest taka, jakiej oczekuję?

Performance Monitoring zbiera dane o skuteczności z urządzeń użytkowników aplikacji. Jeśli aplikacja ma wielu użytkowników lub generuje dużą aktywność związaną z wydajnością, Performance Monitoring może ograniczyć zbieranie danych do podzbioru urządzeń, aby zmniejszyć liczbę przetwarzanych zdarzeń. Te limity są na tyle wysokie, że nawet przy mniejszej liczbie zdarzeń wartości danych nadal odzwierciedlają wrażenia użytkowników aplikacji.

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

• Ograniczanie liczby żądań na urządzeniu: aby zapobiec wysyłaniu przez urządzenie nagłych serii logów czasu, ograniczamy liczbę logów czasu kodu i logów czasu żądań sieciowych wysyłanych z urządzenia do 300 zdarzeń co 10 minut. Takie podejście chroni urządzenie przed zapętlonymi instrumentacjami, które mogą wysyłać duże ilości danych o skuteczności, i zapobiega zniekształcaniu pomiarów wydajności przez pojedyncze urządzenie.

• Dynamiczne próbkowanie: Performance Monitoring zbiera ograniczoną liczbę logów czasu kodu i logów czasu żądań sieciowych na aplikację dziennie u wszystkich użytkowników aplikacji. Na urządzeniach jest pobierana dynamiczna częstotliwość próbkowania (za pomocą Firebase Remote Config), aby określić, czy losowe urządzenie powinno przechwytywać i wysyłać logi czasu. Urządzenie, które nie zostało wybrane do próbkowania, nie wysyła żadnych zdarzeń. Dynamiczna częstotliwość próbkowania jest zależna od aplikacji i jest dostosowywana tak, aby łączna ilość zebranych danych nie przekraczała limitu.

  Projekty, które mają włączoną integrację z BigQuery, mają wyższy limit liczby logów czasu żądań sieciowych.

  Sesje użytkowników wysyłają dodatkowe, szczegółowe dane z urządzenia użytkownika, co wymaga więcej zasobów do przechwytywania i wysyłania danych. Aby zminimalizować wpływ sesji użytkowników, Performance Monitoring może też ograniczyć liczbę sesji.

• Ograniczanie liczby żądań po stronie serwera: aby aplikacje nie przekraczały limitu próbkowania, Performance Monitoring może używać próbkowania po stronie serwera do odrzucania niektórych zdarzeń otrzymanych z urządzeń. Chociaż ten rodzaj ograniczenia nie wpływa na skuteczność naszych danych, może powodować niewielkie zmiany wzorców, w tym:

  • Liczba logów czasu może się różnić od liczby wykonań fragmentu kodu.
  • Ślady, 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?

Zastąpiliśmy kartę Problemy alertami, które automatycznie powiadamiają Cię o przekroczeniu ustawionych progów. Nie musisz już ręcznie sprawdzać konsoli Firebase, aby określić stan progu. Więcej informacji o alertach znajdziesz w artykule Konfigurowanie alertów dotyczących problemów z wydajnością.

Co się stało z kartami Na urządzeniu i Sieć w konsoli? Jak mogę wyświetlić logi czasu oczekiwania, które były na tych stronach?

Zmieniliśmy sekcję Performance Monitoring w konsoli Firebase, aby na karcie Panel wyświetlały się najważniejsze dane i wszystkie logi czasu w jednym miejscu. W ramach zmian usunęliśmy strony Na urządzeniu i Sieć.

Tabela śladów u dołu karty Panel zawiera te same informacje co karty Na urządzeniu i Sieć, ale ma też pewne dodatkowe funkcje, m.in. możliwość sortowania śladów według zmiany procentowej określonych danych. Aby wyświetlić wszystkie dane i wskaźniki dotyczące konkretnego logu czasu, kliknij jego nazwę w tabeli logów czasu.

Ślady możesz wyświetlać na tych podkartach tabeli śladów:

• Logi czasu żądań sieciowych (zarówno gotowe, jak i niestandardowe) – podkarta Żądania sieciowe.
• Ślady niestandardowego kodu – podkarta Ślady niestandardowe
• Ślady uruchomienia aplikacji, aplikacji na pierwszym planie i aplikacji w tle – podkarta Ślady niestandardowe
• Ślady renderowania ekranu – podkarta Renderowanie ekranu
• Ślady wczytywania strony – podkarta Wczytywanie strony

Szczegółowe informacje o tabeli logów czasu oraz wyświetlaniu danych i statystyk znajdziesz na stronie przeglądu konsoli (iOS+ | Android | Web).

Dlaczego liczba powolnych i zamrożonych klatek jest inna, niż się spodziewam?

Powolne renderowanie klatek i zawieszone klatki są obliczane przy założeniu, że częstotliwość odświeżania urządzenia wynosi 60 Hz. Jeśli częstotliwość odświeżania urządzenia jest niższa niż 60 Hz, każda klatka będzie miała dłuższy czas renderowania, ponieważ na sekundę renderowanych jest mniej klatek. Dłuższy czas renderowania może powodować zgłaszanie większej liczby wolnych lub zawieszonych klatek, ponieważ więcej klatek będzie renderowanych wolniej lub będzie się zawieszać. 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ć zgłaszanie mniejszej liczby powolnych lub zawieszonych klatek. Jest to obecne ograniczenie pakietu SDK Performance Monitoring.

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

Aby oprócz aktywności aplikacji widzieć też wydajność fragmentów, upewnij się, że aplikacja korzysta z 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 logi czasu są powiązane z fragmentami i aktywnościami?

Każdy ślad fragmentu i aktywności jest oparty na nazwie klasy zdefiniowanej w aplikacji. Każdy ślad ekranu zawiera prefiks st, po którym następuje nazwa klasy. W konsoli Firebase prefiks jest usuwany. Więcej informacji znajdziesz w artykule Dane o wydajności renderowania ekranu (aplikacje na Apple i Androida) .

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

Performance Monitoring przeprowadza próbkowanie zdarzeń we wszystkich zdarzeniach zebranych na urządzeniu. Dzięki temu możemy zbierać z urządzeń użytkowników minimalną liczbę zdarzeń potrzebną do dostarczania wskaźników skuteczności.

Jak otrzymam powiadomienie, gdy wystąpi problem z wydajnością renderowania aplikacji?

Performance Monitoring umożliwia skonfigurowanie alertów dotyczących danych, które są dla Ciebie ważne. W przypadku wygenerowanych śladów renderowania ekranu możesz skonfigurować alerty, które będą Cię powiadamiać, gdy odsetek powolnych i zamrożonych klatek przekroczy ustawiony przez Ciebie próg.

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

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

Oto kilka najważniejszych czynników, które mogą wydłużyć czas kompilacji:

• Liczba klas lub plików
• rozmiar każdej z tych klas (liczba wierszy kodu),
• Konfiguracja maszyny
• kompilacja początkowa a kolejna (kolejne kompilacje są zwykle szybsze niż początkowa);

Aby zoptymalizować czas kompilacji, rozważ podzielenie kodu na moduły.

Począwszy od wersji 1.3.3 wtyczki Performance Monitoring, skupiliśmy się na wprowadzeniu znacznych ulepszeń w procesie kompilacji przyrostowej i buforowaniu danych wejściowych biblioteki. Aby korzystać z najnowszych ulepszeń czasu kompilacji, używaj najnowszej wersji wtyczki (wersja 2.0.2).

Pamiętaj, że możesz wyłączyć wtyczkę Performance Monitoring w kompilacjach do debugowania lokalnie, jeśli chcesz uniknąć długiego czasu kompilacji. Nie zalecamy jednak tego podejścia w przypadku kompilacji produkcyjnych, ponieważ może to spowodować pominięcie pomiarów wydajności żądań sieciowych w aplikacji.

Co zrobić, jeśli wystąpią błędy kompilacji spowodowane niezgodnością bibliotek z wtyczką Gradle Performance Monitoring?

Performance Monitoring na Androida używa instrumentacji kodu bajtowego, aby udostępniać gotowe funkcje, takie jak monitorowanie żądań sieciowych HTTP/S. W ramach kompilacji proces wymaga iteracji przez wszystkie klasy aplikacji (w tym zależności) w celu instrumentacji 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 zależnością od biblioteki, która jest niezgodna z wtyczką Performance Monitoring do Gradle.

Aby rozwiązać ten problem, możesz wykluczyć niezgodne klasy lub biblioteki z instrumentacji, wykonując te czynności:

1. Zaktualizuj wtyczkę Gradle Performance Monitoring do najnowszej wersji (co najmniej 1.4.0).
2. Zaktualizuj wtyczkę Androida do obsługi Gradle do wersji 7.2.0 lub nowszej.
3. Dodaj do pliku build.gradle modułu (na poziomie aplikacji) tę flagę, aby wykluczyć niezgodne klasy i biblioteki z instrumentacji:

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

   Więcej informacji o właściwości exclude interfejsu API Instrumentation wtyczki Androida do obsługi Gradle znajdziesz w artykule o instrumentacji.

Jeśli wystąpią błędy kompilacji spowodowane niezgodnymi bibliotekami, zgłoś problem na GitHubie, aby można było wykluczyć te biblioteki z instrumentacji we wtyczce Performance Monitoring.

thought Eksportowanie danych Performance Monitoring do BigQuery trwa dłużej niż oczekiwano. Czy nie jest to czas rzeczywisty?

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

Na przykład dane z 19 kwietnia będą dostępne w BigQuery 20 kwietnia między godziną 12:00 a północą (wszystkie daty i godziny są podawane według czasu pacyficznego).

Ile niestandardowych wzorców adresów URL mogę utworzyć?

Możesz utworzyć maksymalnie 400 niestandardowych wzorców adresów URL na aplikację i maksymalnie 100 niestandardowych wzorców adresów URL na domenę w przypadku danej aplikacji.

Co oznaczają dane o skuteczności „w czasie zbliżonym do rzeczywistego”?

Firebase Performance Monitoring przetwarza zebrane dane o skuteczności na bieżąco, co pozwala na wyświetlanie ich w konsoli Firebase w czasie zbliżonym do rzeczywistego. Przetworzone dane są wyświetlane w konsoli w ciągu kilku minut od ich zebrania, stąd określenie „czas zbliżony do rzeczywistego”.

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

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

Aby korzystać z przetwarzania danych w czasie zbliżonym do rzeczywistego, musisz tylko upewnić się, że Twoja aplikacja używa wersji pakietu SDK Performance Monitoring, która jest zgodna z przetwarzaniem danych w czasie rzeczywistym.

Oto wersje pakietu SDK zgodne z funkcją ochrony 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 w wersji 26.1.0 lub nowszej)
• Internet – wersja 7.14.0 lub nowsza

Zawsze zalecamy używanie najnowszej wersji pakietu SDK, ale każda wersja wymieniona powyżej umożliwi usłudze Performance Monitoring przetwarzanie danych w czasie zbliżonym do rzeczywistego.

Które wersje pakietu SDK Performance Monitoring są zgodne z funkcją określania stawek w czasie rzeczywistym?

Oto wersje pakietu SDK zgodne z przetwarzaniem 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 w wersji 26.1.0 lub nowszej)
• Internet – wersja 7.14.0 lub nowsza

Zawsze zalecamy używanie najnowszej wersji pakietu SDK, ale każda z wymienionych powyżej wersji umożliwi usłudze 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 określaniem stawek w czasie rzeczywistym?

Jeśli Twoja aplikacja nie używa wersji pakietu SDK zgodnej z funkcją monitorowania w czasie rzeczywistym, nadal będziesz widzieć wszystkie dane o skuteczności aplikacji w konsoli Firebase. Jednak wyświetlanie danych o skuteczności będzie opóźnione o około 36 godzin od momentu ich zebrania.

Mam zaktualizowaną wersję pakietu SDK zgodną z danymi w czasie rzeczywistym, ale niektórzy użytkownicy nadal korzystają ze starszych wersji mojej aplikacji. Czy nadal będę widzieć ich dane o skuteczności w konsoli Firebase?

Tak. Niezależnie od tego, której wersji pakietu SDK używa instancja aplikacji, zobaczysz dane o skuteczności dotyczące wszystkich użytkowników.

Jeśli jednak przeglądasz najnowsze dane (sprzed mniej niż około 36 godzin), wyświetlane dane pochodzą od użytkowników instancji aplikacji korzystających z wersji pakietu SDK zgodnej z czasem rzeczywistym. Starsze dane obejmują jednak dane o skuteczności ze wszystkich wersji aplikacji.

Dlaczego nie widzę danych o skuteczności w czasie rzeczywistym?

Aby wyświetlać dane o skuteczności w czasie rzeczywistym, upewnij się, że Twoja aplikacja korzysta z pakietu SDK Performance Monitoring w wersji zgodnej z przetwarzaniem 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 w wersji 26.1.0 lub nowszej)
• Internet – wersja 7.14.0 lub nowsza

Zawsze zalecamy używanie najnowszej wersji pakietu SDK, ale każda wersja wymieniona powyżej umożliwi usłudze Performance Monitoring przetwarzanie danych w czasie zbliżonym do rzeczywistego.