Traceview: czym jest, narzędzie do debugowania i profilowania Androida

Czym jest Traceview w Androidzie

Traceview — to graficzny profiler wbudowany w Android Studio, który wyświetla ślady wykonania metod aplikacji Android w formie osi czasu i tabeli wywołań. Wchodzi w skład Android SDK i jest dostępny przez Android Profiler od wersji Android Studio 3.0, a także przez narzędzie wiersza poleceń dmtracedump.

Przeznaczenie narzędzia

Głównym zadaniem Traceview jest pomoc programiście w znalezieniu metod, które zużywają najwięcej czasu CPU. W przeciwieństwie do prostego logowania, Traceview rejestruje dokładny czas wejścia i wyjścia z każdej metody, buduje Call Chart i Top-Down-drzewo, co pozwala wizualnie wykryć anomalie wydajności. Narzędzie jest szczególnie przydatne przy profilowaniu wątku UI, gdzie opóźnienie 16 ms prowadzi do pominięcia klatki.

Historia i rozwój

Traceview pojawił się już we wczesnych wersjach Android SDK jako samodzielne narzędzie do przeglądania plików .trace. Z wydaniem Android Studio 3.0 (2017) stał się częścią Android Profiler, zyskując integrację z żywą osią czasu CPU, pamięci i sieci. Według danych Google I/O 2018, zespół Android Studio kontynuuje rozwój profilera, dodając obsługę kodu natywnego przez systrace i perfetto. W aktualnych wersjach Android Studio Traceview działa w oparciu o format Perfetto, ale zachowuje wsteczną zgodność z klasycznym .trace.

Jak działa Traceview

Traceview otrzymuje dane od mechanizmu System Tracing w Android Runtime (ART). Gdy aplikacja jest uruchamiana z włączonym debugowaniem, ART zapisuje w buforze znaczniki czasu początku i końca każdej wykonywanej metody, w tym nazwę klasy, nazwę metody i ID wątku.

// Uruchomienie śledzenia w kodzie aplikacji
Debug.startMethodTracing("app_trace")

// Krytyczny fragment kodu do profilowania
loadHeavyData()

// Zatrzymanie śledzenia — plik zapisany na urządzeniu
Debug.stopMethodTracing()

System Tracing działa na poziomie maszyny wirtualnej ART i rejestruje każde wywołanie metody z dokładnością do mikrosekund. Dane są zapisywane w buforze cyklicznym, aby zminimalizować wpływ na wydajność samej aplikacji. Po zatrzymaniu debugowania bufor jest zapisywany do pliku .trace w wewnętrznym magazynie urządzenia.

Format pliku .trace

Plik .trace zawiera nagłówek z wersją formatu i czasem startu, po którym następują wpisy o każdym wywołaniu: thread ID, method ID, timestamp wejścia i timestamp wyjścia. Android Studio automatycznie ładuje plik .trace i buduje dwa główne widoki: Timeline Panel dla chronologii i Profile Panel dla hierarchii wywołań. Domyślnie maksymalny rozmiar bufora to 8 MB, ale można go zwiększyć przez Debug.startMethodTracing(filename, maxSize).

Kluczowe możliwości Traceview

Traceview oferuje kilka uzupełniających się widoków danych, z których każdy rozwiązuje inne zadanie przy analizie wydajności.

Call Chart (graf wywołań)

Call Chart — to pozioma oś czasu, gdzie każdy wątek jest wyświetlany na osobnej ścieżce. Metody są pokazane jako kolorowe prostokąty: szerokość prostokąta jest proporcjonalna do czasu wykonania, a zagnieżdżenie odzwierciedla hierarchię wywołań. Jeśli metoda wywołała inną metodę, prostokąt potomny jest rysowany wewnątrz nadrzędnego. Ta wizualizacja pozwala natychmiast zobaczyć, które operacje zablokowały wątek.

Drzewa Top-Down i Bottom-Up

Drzewo Top-Down pokazuje czas wykonania metody z uwzględnieniem wszystkich jej zagnieżdżonych wywołań — Inclusive Time. Drzewo Bottom-Up natomiast pokazuje, które metody nadrzędne wywoływały daną metodę — przydatne do znajdowania źródła ciężkiej operacji. Różnica między Inclusive i Exclusive Time jest krytyczna: metoda może sama działać szybko, ale wywoływać wolną metodę potomną, co widać tylko w Inclusive Time.

Wyszukiwanie i filtrowanie

Traceview obsługuje wyszukiwanie po nazwie metody, pakiecie lub klasie. Wyniki są podświetlane na osi czasu, a w Profile Panel wyświetlana jest statystyka tylko dla znalezionych metod. Dostępne jest również filtrowanie po wątkach — można wyłączyć wyświetlanie wątków tła i skoncentrować się na głównym wątku (UI), gdzie opóźnienia są najbardziej krytyczne.

Eksport danych

Traceview umożliwia eksportowanie śladów w formacie CSV do dalszej analizy w arkuszach lub tworzenia wykresów. W Android Studio można również skopiować wybrany fragment osi czasu jako obraz — do wstawienia w raport błędu lub dokumentację. Dla CI/CD dostępny jest eksport w formacie Perfetto przez narzędzie cmdline-tools.

Jak używać Traceview w Android Studio

Profilowanie przez Traceview jest dostępne na dwa sposoby: przez Android Profiler z żywym przechwytywaniem i przez programowe uruchomienie Debug API. Pierwszy sposób jest wygodny do analizy ad-hoc, drugi — do powtarzalnych testów wydajności.

Przechwytywanie przez Android Profiler

W Android Studio otwórz zakładkę Profiler (View → Tool Windows → Profiler), wybierz urządzenie i proces swojej aplikacji. Kliknij na segment CPU, następnie wybierz tryb "Trace Java Methods" i kliknij Record. Po interakcji z aplikacją kliknij Stop — Traceview automatycznie otworzy zapisany ślad. Domyślny czas nagrywania jest ograniczony do 30 sekund, ale limit można zmienić w ustawieniach profilera.

Programowe uruchomienie debugowania

Do dokładnego profilowania konkretnego fragmentu kodu użyj Debug.startMethodTracing i Debug.stopMethodTracing. Plik jest zapisywany w zewnętrznym magazynie aplikacji w ścieżce zwracanej przez context.getExternalFilesDir(null). Po zakończeniu przenieś plik .trace na komputer przez Android Studio Device Explorer, a następnie otwórz przez File → Open w Android Studio.

Debug.startMethodTracing(
    "heavy_computation",
    Debug.TRACE_COUNT_ALLOCS
)

processLargeDataset()

Debug.stopMethodTracing()

Konfiguracja parametrów debugowania

Debug.startMethodTracing przyjmuje trzy parametry: nazwę pliku (bez rozszerzenia), maksymalny rozmiar bufora (domyślnie 8 MB) i flagi. Flaga TRACE_COUNT_ALLOCS dodaje zliczanie alokacji obiektów — przydatne do znajdowania wycieków pamięci. Do profilowania kodu natywnego Traceview się nie nadaje — użyj SimplePerf lub Perfetto. Do długich testów (powyżej 30 sekund) zaleca się zwiększenie bufora do 64–128 MB przez parametr maxSize.

Czytanie osi czasu Traceview

Oś czasu Traceview składa się z dwóch paneli: górny — Timeline Panel z kolorowymi prostokątami wywołań, dolny — Profile Panel z tabelą statystyk. Timeline Panel pokazuje wykonywanie wątków od lewej do prawej, gdzie każdy prostokąt to jedno wywołanie metody. Kolor prostokąta jest kodowany według typu metody: wywołania systemowe Androida (zielony), metody aplikacyjne (niebieski), wywołania bibliotek (pomarańczowy).

Jak czytać Profile Panel

W Profile Panel każdy wiersz to metoda z kolumnami Inclusive Time, Exclusive Time, Calls + Recur i CPU Time. Sortuj tabelę według Inclusive Time (malejąco), aby najpierw zobaczyć metody, które łącznie zajęły najwięcej czasu. Jeśli metoda z wysokim Inclusive Time ma niski Exclusive Time — problem leży w jej wywołaniach potomnych i należy rozwinąć drzewo. Na przykład ListView.getView może mieć wysoki Inclusive Time z powodu wywołania ładowania obrazu.

Wykrywanie wąskich gardeł

Szukaj metod z anomalnie wysokim Real Time przy niskim CPU Time — to wskazuje na blokadę (oczekiwanie I/O, operacja sieciowa, lock contention). Metody z wysokim CPU Time wymagają optymalizacji algorytmu. Dla wątku UI krytyczne jest, aby każda metoda mieściła się w 16 ms — jeśli jakieś wywołanie przekracza ten próg, aplikacja pomija klatkę i użytkownik widzi drgania. Według zaleceń Google, łączny czas wszystkich wywołań w wątku UI na jedną klatkę nie powinien przekraczać 8–10 ms, pozostawiając zapas na operacje systemowe.

Traceview vs Systrace: porównanie narzędzi

Chociaż i Traceview, i Systrace należą do narzędzi debugowania Androida, rozwiązują one różne zadania i są używane na różnych etapach profilowania. Główna różnica to poziom szczegółowości: Traceview działa na poziomie metod Java/Kotlin, Systrace — na poziomie procesów systemowych (CPU, GPU, Binder, SurfaceFlinger).

W praktyce oba narzędzia się uzupełniają: najpierw Systrace pomaga określić, który komponent systemowy powoduje problem (np. częste GC lub blokady Binder), a następnie Traceview pozwala zagłębić się w konkretną metodę wewnątrz aplikacji. W Android Studio oba narzędzia są połączone w Android Profiler — CPU Profiler automatycznie dobiera optymalny tryb nagrywania. Na urządzeniach z Android 12+ Systrace i Traceview działają w oparciu o Perfetto, co daje jednolity format danych dla wszystkich rodzajów profilowania.

Przykłady kodu z Traceview

Do efektywnego profilowania nie wystarczy samo uruchomienie debugowania — trzeba prawidłowo umieścić punkty przechwytywania i interpretować wyniki. Poniżej znajdują się dwa praktyczne przykłady: profilowanie listy RecyclerView i porównanie dwóch algorytmów w teście wydajności.

Profilowanie ładowania RecyclerView

Pierwszy przykład — debugowanie ścieżki krytycznej podczas przewijania listy. RecyclerView wywołuje onBindViewHolder dla każdego widocznego elementu, a jeśli ta metoda wykonuje się dłużej niż 16 ms, przewijanie staje się szarpane. Debugowanie wokół onBindViewHolder pokaże, które konkretnie operacje wewnątrz niego zajmują czas.

class MyAdapter : RecyclerView.Adapter<ViewHolder>() {
    override fun onBindViewHolder(
        holder: ViewHolder,
        position: Int
    ) {
        Debug.startMethodTracing("bind_card_$position")

        holder.bind(items[position])

        Debug.stopMethodTracing()
    }
}

Porównanie dwóch algorytmów

Drugi przykład — test A/B prędkości dwóch implementacji: ładowanie obrazów przez Glide w porównaniu z ręcznym BitmapFactory. Taki ślad pozwala obiektywnie porównać Inclusive Time obu strategii i wybrać optymalną. Ważne jest uruchamianie każdego testu na rozgrzanym urządzeniu (po 3–5 cyklach) i w identycznych warunkach (obciążenie w tle, temperatura).

fun compareImageLoadingStrategies() {
    // Test A: Glide
    Debug.startMethodTracing("glide_test")
    loadWithGlide()
    Debug.stopMethodTracing()

    // Test B: BitmapFactory
    Debug.startMethodTracing("bitmap_test")
    loadWithBitmapFactory()
    Debug.stopMethodTracing()
}

Po uruchomieniu otwórz oba pliki .trace w Android Studio i porównaj Inclusive Time w Profile Panel. Jeśli Glide pokazuje 3x mniejszy Inclusive Time przy tym samym zadaniu — to obiektywna podstawa do wyboru biblioteki. Według danych Tony'ego Jona (twórca Glide, 2023), biblioteka używa buforowania i puli wątków, co daje przewagę do 40% przy powtarzających się ładowniach.