Na tej stronie znajdziesz wskazówki dotyczące rozwiązywania problemów, które pomogą Ci zacząć korzystać z Performance Monitoring lub funkcji i narzędzi Performance Monitoring.
Pierwsze kroki w rozwiązywaniu problemów
Poniższe 2 sprawdzone metody są zalecane wszystkim użytkownikom przed podjęciem dalszych działań.
1. Sprawdzanie wiadomości w dzienniku pod kątem zdarzeń związanych z wydajnością
Sprawdź wiadomości w logach, aby upewnić się, że pakiet SDK Performance Monitoring rejestruje zdarzenia związane z wydajnością.
Wyświetlanie wiadomości logu dotyczących zdarzeń związanych z wydajnością
Włącz logowanie debugowania dla Performance Monitoring w momencie kompilacji, dodając element
<meta-data>
do plikuAndroidManifest.xml
aplikacji w ten sposób:<application> <meta-data android:name="firebase_performance_logcat_enabled" android:value="true" /> </application>
Sprawdź, czy w komunikatach dziennika nie ma żadnych błędów.
Performance Monitoring oznacza swoje wiadomości w logach symbolem
FirebasePerformance
. Korzystając z filtrowania logcat, możesz wyświetlić śledzenie czasu trwania i logowanie żądań sieciowych HTTP/S, uruchamiając to polecenie:adb logcat -s FirebasePerformance
Sprawdź, czy występują te typy dziennikó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
Kliknij adres URL, aby wyświetlić dane w konsoli Firebase. Aktualizacja danych w panelu może potrwać kilka chwil.
Jeśli Twoja aplikacja nie rejestruje zdarzeń związanych z wydajnością, zapoznaj się z wskazówkami dotyczącymi rozwiązywania problemów.
2. Sprawdzanie panelu stanu Firebase
Otwórz Panel stanu Firebase, aby sprawdzić, czy występuje przerwa w dostępie do Firebase lub Performance Monitoring.
Pierwsze kroki w Performance Monitoring
Jeśli dopiero zaczynasz korzystać z Performance Monitoring(iOS+ | Android | Web), poniższe wskazówki dotyczące rozwiązywania problemów mogą Ci pomóc w przypadku problemów związanych z wykrywaniem pakietu SDK przez Firebase lub wyświetlaniem pierwszych danych o wydajności w konsoli Firebase.
Pakiet SDK został dodany do aplikacji, ale konsola nadal wyświetla komunikat o konieczności dodania pakietu SDK
Firebase może wykryć, czy pakiet SDK został dodany do aplikacji, gdy otrzyma z niej informacje o zdarzeniach (np. interakcjach z aplikacją). Zwykle w ciągu 10 minut od uruchomienia aplikacji na panelu Firebasekonsoli wyświetla się komunikat „Wykryto pakiet SDK”.Performance Monitoring W ciągu 30 minut w panelu wyświetlą się wstępnie przetworzone dane.
Jeśli od dodania najnowszej wersji pakietu SDK do aplikacji minęło więcej niż 10 minut, a nadal nie widzisz żadnych zmian, sprawdź komunikaty w dzienniku, 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.
Aplikacja rejestruje zdarzenia: czynności związane z rozwiązywaniem problemów
Upewnij się, że używasz Performance Monitoring pakietu SDK do Androida w wersji 19.1.0 lub nowszej (albo Firebase BoM w wersji 26.3.0 lub nowszej). Więcej informacji znajdziesz w informacjach o wersji.
Jeśli nadal pracujesz lokalnie, spróbuj wygenerować więcej zdarzeń na potrzeby zbierania danych:
- Wygeneruj zdarzenia, przełączając aplikację między tłem a pierwszym planem kilka razy, wchodząc z nią w interakcję przez poruszanie się po ekranach lub wywołując żądania sieciowe.
Sprawdź, czy plik konfiguracji Firebase (
google-services.json
) został prawidłowo dodany do aplikacji i czy nie został zmodyfikowany. Sprawdź te kwestie:Nazwa pliku konfiguracyjnego nie zawiera dodatkowych znaków, np.
(2)
.Plik konfiguracyjny znajduje się w katalogu modułu (na poziomie aplikacji).
Identyfikator aplikacji Firebase na Androida (
mobilesdk_app_id
) podany w pliku konfiguracyjnym jest prawidłowy w przypadku Twojej aplikacji. Znajdź identyfikator aplikacji Firebase na karcie Twoje aplikacje w settings ustawieniach projektu.
Jeśli w pliku konfiguracyjnym aplikacji coś jest nie tak, wykonaj te czynności:
Usuń plik konfiguracyjny, który masz obecnie w aplikacji.
Aby pobrać nowy plik konfiguracyjny i dodać go do aplikacji na Androida, wykonaj te instrukcje.
Jeśli pakiet SDK rejestruje zdarzenia i wszystko wydaje się być prawidłowo skonfigurowane, ale nadal nie widzisz komunikatu o wykryciu pakietu SDK ani przetworzonych danych (po 10 minutach), skontaktuj się z zespołem pomocy Firebase.
Aplikacja nie rejestruje zdarzeń: kroki rozwiązywania problemów
Sprawdź konfigurację Performance Monitoring wtyczki Gradle:
Sprawdź, czy wtyczka została dodana prawidłowo. Sprawdź te kwestie:
- W pliku
build.gradle
modułu (na poziomie aplikacji) dodano wtyczkę (
).apply plugin: 'com.google.firebase.firebase-perf' - W pliku na poziomie projektu
build.gradle
uwzględniono zależność classpath wtyczki (
).classpath 'com.google.firebase:perf-plugin:1.4.2'
- W pliku
Sprawdź, czy wtyczka nie jest wyłączona za pomocą jednego z tych flag:
instrumentationEnabled
w module (na poziomie aplikacji)build.gradle
firebasePerformanceInstrumentationEnabled
w Twoimgradle.properties
pliku
Sprawdź, czy Performance Monitoring pakiet SDK nie jest wyłączony za pomocą jednego z tych flag w pliku
AndroidManifest.xml
:firebase_performance_collection_enabled
firebase_performance_collection_deactivated
Upewnij się, że Performance Monitoring nie jest wyłączony w czasie działania.
Jeśli nie możesz znaleźć w aplikacji niczego, co jest wyłączone, skontaktuj się z zespołem pomocy Firebase.
Konsola informuje, że pakiet SDK został wykryty, ale nie wyświetla żadnych danych
Performance Monitoring przetwarza dane o zdarzeniach związanych ze skutecznością, zanim wyświetli je 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 dowiedzieć się, czy nie występuje znana awaria. Jeśli nie ma awarii, skontaktuj się z zespołem pomocy Firebase.
Rozwiązywanie ogólnych problemów
Jeśli pakiet SDK został dodany i używasz w aplikacji funkcji Performance Monitoring, poniższe wskazówki dotyczące rozwiązywania problemów mogą pomóc w przypadku ogólnych problemów związanych z funkcjami i narzędziami Performance Monitoring.
Aplikacja nie rejestruje zdarzeń związanych z wydajnością
Jeśli nie widzisz komunikatów dziennika dotyczących zdarzeń związanych z wydajnością, wykonaj te czynności:
Sprawdź konfigurację Performance Monitoring wtyczki Gradle:
Sprawdź, czy wtyczka została dodana prawidłowo. Sprawdź te kwestie:
- W pliku
build.gradle
modułu (na poziomie aplikacji) dodano wtyczkę (
).apply plugin: 'com.google.firebase.firebase-perf' - W pliku na poziomie projektu
build.gradle
uwzględniono zależność classpath wtyczki (
).classpath 'com.google.firebase:perf-plugin:1.4.2'
- W pliku
Sprawdź, czy wtyczka nie jest wyłączona za pomocą jednego z tych flag:
instrumentationEnabled
w module (na poziomie aplikacji)build.gradle
firebasePerformanceInstrumentationEnabled
w Twoimgradle.properties
pliku
Sprawdź, czy Performance Monitoring pakiet SDK nie jest wyłączony za pomocą jednego z tych flag w pliku
AndroidManifest.xml
:firebase_performance_collection_enabled
firebase_performance_collection_deactivated
Upewnij się, że Performance Monitoring nie jest wyłączony w czasie działania.
Jeśli nie możesz znaleźć w aplikacji niczego, co jest wyłączone, skontaktuj się z zespołem pomocy Firebase.
W Panelu wyników brakuje danych śledzenia ekranu
Jeśli brakuje Ci danych dotyczących śladów renderowania ekranu, wykonaj te czynności:
Upewnij się, że używasz najnowszej wersji pakietu SDK na Androida (21.0.5). Ślady renderowania ekranu są dostępne tylko w przypadku wersji 15.2.0 lub nowszej.
Sprawdź, czy nie została ręcznie wyłączona akceleracja sprzętowa na ekranie.
Upewnij się, że nie używasz DexGuard ani Jacka. Performance Monitoring jest niezgodny z tymi łańcuchami narzędzi.
DexGuard wyłącza automatyczne zbieranie logów czasu uruchamiania aplikacji, działania aplikacji na pierwszym planie i działania aplikacji w tle. Jeśli jednak aplikacja korzysta z DexGuard, wszelkie ślady kodu niestandardowego powinny działać normalnie.
Jack jest przestarzały i zwykle nie powinien być używany w aplikacji.
Na panelu skuteczności brakuje danych śledzenia niestandardowego
Czy widzisz dane o skuteczności automatycznie zbieranych logów czasu, ale nie widzisz ich w przypadku logów czasu z kodu niestandardowego? Wypróbuj te rozwiązania:
Jeśli ślady kodu niestandardowego zostały zaimplementowane za pomocą interfejsu Trace API, sprawdź konfigurację śladów, a zwłaszcza te elementy:
- Nazwy śladów kodu niestandardowego i danych 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 (
_
), a ich maksymalna długość to 32 znaki. - Wszystkie ślady muszą być uruchomione i zatrzymane. Żadne ślady, które nie zostały rozpoczęte, nie zostały zatrzymane lub zostały zatrzymane przed rozpoczęciem, nie zostaną zarejestrowane.
- Nazwy śladów kodu niestandardowego i danych 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 (
Jeśli logi czasu niestandardowego kodu zostały instrumentowane za pomocą
@AddTrace
notacji, sprawdź konfigurację wtyczki Gradle:Performance MonitoringSprawdź, czy wtyczka została dodana prawidłowo. Sprawdź te kwestie:
- W pliku
build.gradle
modułu (na poziomie aplikacji) dodano wtyczkę (
).apply plugin: 'com.google.firebase.firebase-perf' - W pliku na poziomie projektu
build.gradle
uwzględniono zależność classpath wtyczki (
).classpath 'com.google.firebase:perf-plugin:1.4.2'
- W pliku
Sprawdź, czy wtyczka nie jest wyłączona za pomocą jednego z tych flag:
instrumentationEnabled
w module (na poziomie aplikacji)build.gradle
firebasePerformanceInstrumentationEnabled
w Twoimgradle.properties
pliku
Sprawdź wiadomości w logach, aby upewnić się, że Performance Monitoring rejestruje oczekiwane ślady kodu niestandardowego.
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 skuteczności brakuje danych o żądaniach sieciowych
Jeśli brakuje Ci danych o żądaniach sieciowych, wykonaj te czynności:
W przypadku aplikacji na Androida Performance Monitoringwtyczka Gradle umożliwia instrumentację, która zapewnia automatyczne monitorowanie żądań sieciowych HTTP/S. Sprawdź, czy:
Sprawdź, czy wtyczka została dodana prawidłowo. Sprawdź te kwestie:
- W pliku
build.gradle
modułu (na poziomie aplikacji) dodano wtyczkę (
).apply plugin: 'com.google.firebase.firebase-perf' - W pliku na poziomie projektu
build.gradle
uwzględniono zależność classpath wtyczki (
).classpath 'com.google.firebase:perf-plugin:1.4.2'
- W pliku
Sprawdź, czy wtyczka nie jest wyłączona za pomocą jednego z tych flag:
instrumentationEnabled
w module (na poziomie aplikacji)build.gradle
firebasePerformanceInstrumentationEnabled
w Twoimgradle.properties
pliku
Sprawdź, czy biblioteka sieciowa jest niekompatybilna. Performance Monitoring automatycznie zbiera wskaźniki dotyczące żądań sieciowych, które korzystają z tych bibliotek sieciowych: OkHttp 3.x.x, URLConnection w Javie i Apache HttpClient.
Pamiętaj, że możesz dodać niestandardowe monitorowanie żądań sieciowych.
Pamiętaj:
W zależności od działania kodu i bibliotek sieciowych używanych przez Twój kod Performance Monitoring może raportować tylko ukończone żądania sieciowe. Oznacza to, że otwarte połączenia HTTP/S mogą nie być zgłaszane.
Performance Monitoring nie jest zgodny z DexGuard i Jackiem.
- DexGuard wyłącza monitorowanie żądań sieciowych HTTP/S.
- Jack jest przestarzały i zwykle nie powinien być używany w aplikacji.
Performance Monitoring nie raportuje żądań sieciowych z nieprawidłowymi
Content-Type
nagłówkami. Żądania sieciowe bez nagłówkówContent-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.
Najczęstsze pytania
Co się stało z sekcją Najważniejsze problemy na karcie Skuteczność na stronie głównej projektu?
Zastąpiliśmy sekcję Najważniejsze problemy sekcją Ostatnie alerty. Jest to kontynuacja niedawnego wprowadzenia alertów, które automatycznie powiadamiają Cię o przekroczeniu ustawionych przez Ciebie 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ą zdefiniowane progi. Aby uniknąć nieporozumień związanych z tymi konfigurowalnymi progami dla danych o 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 nowo zaprojektowanym, scentralizowanym interfejsem, aby ułatwić Ci rozwiązywanie problemów. Ten nowy interfejs rozwiązywania problemów oferuje te same podstawowe funkcje co sekcje Szczegóły i Dane. Więcej informacji o rozwiązywaniu problemów znajdziesz w sekcji Wyświetlanie większej ilości 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 Twojej aplikacji. Jeśli Twoja aplikacja ma wielu użytkowników lub generuje dużą liczbę danych o wydajności, 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żytkowników związane z aplikacją.
Aby zarządzać ilością zbieranych danych, Performance Monitoring korzysta z tych opcji próbkowania:
Ograniczanie liczby żądań na urządzeniu: aby zapobiec wysyłaniu przez urządzenie nagłych serii śladów, ograniczamy liczbę śladów kodu i żądania sieciowe wysyłane 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 wydajności, i zapobiega zniekształcaniu pomiarów wydajności przez jedno urządzenie.
Próbkowanie dynamiczne: Performance Monitoring codziennie zbiera ograniczoną liczbę śladów kodu i śladów żądań sieciowych w przypadku wszystkich użytkowników aplikacji. Na urządzeniach pobierana jest dynamiczna częstotliwość próbkowania (za pomocą Firebase Remote Config), aby określić, czy losowe urządzenie ma przechwytywać i wysyłać ślady. Urządzenie, które nie zostało wybrane do próbkowania, nie wysyła żadnych zdarzeń. Dynamiczna częstotliwość próbkowania jest specyficzna dla aplikacji i dostosowuje się tak, aby ogólna ilość zebranych danych nie przekraczała limitu.
Projekty, w których włączono integrację z BigQuery, mają wyższy limit liczby śladów żądań sieciowych.
Sesje użytkowników wysyłają dodatkowe, szczegółowe dane z urządzenia użytkownika, co wymaga większych zasobów do rejestrowania i przesył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 mieć pewność, że aplikacje nie przekraczają limitu próbkowania, Performance Monitoring może stosować próbkowanie po stronie serwera, aby odrzucać niektóre zdarzenia otrzymywane z urządzeń. Chociaż ten rodzaj ograniczenia nie zmienia skuteczności naszych danych, może powodować niewielkie zmiany wzorców, w tym:
- Liczba śladów może się różnić od liczby uruchomień 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 wprowadzeniem alertów, które automatycznie powiadamiają Cię o przekroczeniu ustawionych przez Ciebie progów. Nie musisz już ręcznie sprawdzać Firebase konsoli, 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 wyświetlić ślady, które znajdowały się na tych stronach?
Przeprojektowaliśmy sekcję Performance Monitoring w Firebase konsoli, aby na karcie Panel wyświetlać kluczowe dane i wszystkie logi czasu w jednym miejscu. W ramach zmiany wyglądu usunęliśmy strony Na urządzeniu i Sieć.
Tabela śladów u dołu karty Panel zawiera wszystkie informacje wyświetlane na kartach Na urządzeniu i Sieć, ale z dodatkowymi funkcjami, w tym możliwością sortowania śladów według procentowej zmiany określonych danych. Aby wyświetlić wszystkie dane i rodzaje danych dotyczące konkretnego śladu, kliknij jego nazwę w tabeli śladów.
Ślady możesz wyświetlić w tych podkartach tabeli śladów:
- Logi czasu żądań sieciowych (gotowe i niestandardowe) – karta Żądania sieciowe
- Logi czasu własnego kodu – karta Logi czasu niestandardowego
- Logi czasu uruchomienia aplikacji, działania aplikacji na pierwszym planie i działania aplikacji w tle – karta Niestandardowe logi czasu
- Logi czasu renderowania ekranu – karta Renderowanie ekranu
- Logi czasu wczytania strony – karta Wczytanie strony
Szczegółowe informacje o tabeli śladów oraz wyświetlaniu danych i statystyk znajdziesz na stronie przeglądu konsoli (iOS | Android | Internet).
Dlaczego liczba wolno wyrenderowanych i zamrożonych klatek nie jest taka, jakiej się spodziewam?
Spowolnione i zablokowane 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 renderowana wolniej, ponieważ na sekundę renderowanych jest mniej klatek. Dłuższy czas renderowania może powodować zgłaszanie większej liczby spowolnionych lub zamrożonych klatek, ponieważ więcej klatek będzie renderowanych wolniej lub będzie zamrożonych. Jeśli jednak częstotliwość odświeżania urządzenia jest wyższa niż 60 Hz, każda klatka będzie renderowana szybciej. Może to spowodować zgłaszanie mniejszej liczby powolnych lub zamrożonych klatek. Jest to obecne ograniczenie pakietu Performance Monitoring SDK.
Dlaczego nie widzę śladów fragmentów?
Aby oprócz aktywności w aplikacji sprawdzać też skuteczność fragmentów, upewnij się, że Twoja aplikacja korzysta z Performance Monitoringpakietu Android SDK w wersji 20.1.0 lub nowszej. Więcej informacji znajdziesz w sekcji Dodawanie monitorowania wydajności do aplikacji.
Jak sprawdzić, które ślady 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, a po nim nazwę klasy. W konsoli Firebase prefiks jest usuwany. Więcej informacji znajdziesz w artykule Dane o skuteczności renderowania ekranu (aplikacje na Androida i iOS) .
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ń potrzebnych do podawania danych o skuteczności.
Jak otrzymam powiadomienie o problemie z wydajnością renderowania mojej aplikacji?
Performance Monitoring umożliwia skonfigurowanie alertów dotyczących wskaźników, na których Ci zależy. 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 czas kompilacji jest długi.Performance Monitoring Jak mogę to poprawić?
Performance Monitoring na Androida korzysta z instrumentacji kodu bajtowego, aby udostępniać niektóre gotowe funkcje, takie jak monitorowanie żądań sieciowych HTTP/S. Proces kompilacji wymaga iteracji wszystkich klas aplikacji (w tym zależności), aby instrumentować kod, który ma kluczowe znaczenie w pomiarze wydajności żądań sieciowych aplikacji.
Oto niektóre z głównych czynników, które mogą wydłużyć czas kompilacji:
- Liczba zajęć lub plików
- Rozmiar każdej z tych klas (liczba wierszy kodu)
- Konfiguracja maszyny
- pierwsza kompilacja a kolejna (kolejne kompilacje są zwykle szybsze niż pierwsza);
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 znaczących ulepszeń w zakresie przetwarzania przyrostowego i buforowania danych wejściowych biblioteki. Aby korzystać z najnowszych ulepszeń czasu kompilacji, używaj najnowszej wersji wtyczki (wersja 1.4.2).
Pamiętaj, że możesz wyłączyć wtyczkęPerformance Monitoring w przypadku lokalnych kompilacji debugowania, jeśli chcesz uniknąć długiego czasu kompilacji. Nie jest to jednak zalecane w przypadku kompilacji produkcyjnych, ponieważ może spowodować pominięcie pomiarów wydajności żądań sieciowych w aplikacji.
Co zrobić, jeśli podczas kompilacji wystąpią błędy spowodowane przez biblioteki niezgodne z wtyczką Gradle Performance Monitoring?
Performance Monitoring na Androida korzysta z instrumentacji kodu bajtowego, aby udostępniać niektóre gotowe funkcje, takie jak monitorowanie żądań sieciowych HTTP/S. Proces kompilacji wymaga iteracji wszystkich klas aplikacji (w tym zależności), aby instrumentować kod, który ma kluczowe znaczenie w pomiarze wydajności żądań sieciowych aplikacji.
Jeśli po integracji z wtyczką Performance Monitoring pojawią się błędy kompilacji, np. JSR/RET are not supported with
computeFrames option
lub podobne, może to oznaczać, że masz też zależność od biblioteki, która jest niezgodna z wtyczką Gradle Performance Monitoring.
Aby temu zapobiec, możesz wykluczyć niekompatybilne klasy lub biblioteki z instrumentacji, wykonując te czynności:
- Zaktualizuj wtyczkę Performance MonitoringGradle do najnowszej wersji (minimum 1.4.0).
- Zaktualizuj wtyczkę Androida do obsługi Gradle do wersji 7.2.0 lub nowszej.
- Aby wykluczyć niekompatybilne klasy lub biblioteki z instrumentacji, dodaj do pliku
build.gradle
modułu (na poziomie aplikacji) ten flagę: Więcej informacji o właściwościandroid { // ... androidComponents { onVariants(selector().all(), { instrumentation.excludes.add("example.incompatible.library") }) } }
exclude
interfejsu APIInstrumentation
wtyczki Androida do obsługi Gradle znajdziesz w sekcji Instrumentacja.
Jeśli napotkasz błędy kompilacji spowodowane niekompatybilnymi bibliotekami, zgłoś problem w GitHubie, aby można było wykluczyć te biblioteki z instrumentacji w Performance Monitoring.
Eksportowanie danych z 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 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 między południem a północą (wszystkie daty i godziny są podane według czasu pacyficznego).
Przetwarzanie i wyświetlanie danych w czasie zbliżonym do rzeczywistego
Co oznaczają dane o skuteczności „niemal w czasie rzeczywistym”?
Firebase Performance Monitoring przetwarza zebrane dane o skuteczności na bieżąco, co powoduje, że w konsoli Firebase są one wyświetlane niemal w czasie rzeczywistym. Przetworzone dane są wyświetlane w konsoli w ciągu kilku minut od ich zebrania, stąd określenie „niemal w czasie rzeczywistym”.
Aby korzystać z przetwarzania danych w czasie zbliżonym do rzeczywistego, upewnij się, że Twoja aplikacja używa wersji pakietu SDK zgodnej z przetwarzaniem w czasie 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 zadbać o to, aby Twoja aplikacja używała pakietu SDK w wersji Performance Monitoring, która jest zgodna z przetwarzaniem danych w czasie rzeczywistym.
Są to wersje pakietu SDK zgodne z czasem rzeczywistym:
- iOS – wersja 7.3.0 lub nowsza
- tvOS – wersja 8.9.0 lub nowsza
- Android – wersja 19.0.10 lub nowsza (albo Firebase Android BoM wersja 26.1.0 lub nowsza)
- Internet – wersja 7.14.0 lub nowsza
Zalecamy używanie najnowszej wersji pakietu SDK, ale każda z wersji wymienionych powyżej umożliwi Performance Monitoring przetwarzanie danych w czasie zbliżonym do rzeczywistego.
Które wersje pakietu Performance Monitoring SDK są zgodne z czasem 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 (albo Firebase Android BoM wersja 26.1.0 lub nowsza)
- Internet – wersja 7.14.0 lub nowsza
Zalecamy używanie najnowszej wersji pakietu SDK, ale każda z wersji wymienionych powyżej umożliwi Performance Monitoring przetwarzanie danych w czasie zbliżonym do rzeczywistego.
Co się stanie, jeśli nie zaktualizuję aplikacji, aby korzystała z wersji pakietu SDK zgodnej z działaniem w czasie rzeczywistym?
Jeśli Twoja aplikacja nie używa wersji pakietu SDK zgodnej z czasem rzeczywistym, w Firebasekonsoli nadal będziesz widzieć wszystkie dane o jej działaniu. Wyświetlanie danych o skuteczności będzie jednak opóźnione o około 36 godzin od momentu ich zebrania.
Mam już wersję pakietu SDK zgodną z czasem rzeczywistym, ale niektórzy użytkownicy nadal korzystają ze starszych wersji mojej aplikacji. Czy nadal będę widzieć dane o ich działaniu w konsoli Firebase?
Tak. Niezależnie od tego, z której wersji pakietu SDK korzysta instancja aplikacji, zobaczysz dane o wydajności wszystkich użytkowników.
Jeśli jednak przeglądasz najnowsze dane (starsze o mniej więcej 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.
Kontaktowanie się z zespołem pomocy Firebase
Jeśli skontaktujesz się z zespołem pomocy Firebase, zawsze podawaj identyfikator aplikacji Firebase. Identyfikator aplikacji Firebase znajdziesz na karcie Twoje aplikacje w settings ustawieniach projektu.