Android Profiler: co to jest, możliwości CPU, Memory i Network

Czym jest Android Profiler?

Android Profiler — to komponent Android Studio, który zastąpił przestarzałe Android Monitor i DDMS. Zapewnia jednolity interfejs do profilowania wszystkich aspektów aplikacji: CPU Profiler do analizy procesora, Memory Profiler do pracy z pamięcią, Network Profiler do żądań sieciowych i Energy Profiler do zużycia energii. Dane są zbierane automatycznie po uruchomieniu aplikacji przez Android Studio.

Profiler działa zarówno na emulatorze, jak i na fizycznym urządzeniu podłączonym przez USB. Według danych Google I/O 2023, Android Profiler jest używany w ponad 70% projektów Android i uważany za standardowe narzędzie diagnostyki wydajności. Główna zaleta w porównaniu z rozwiązaniami zewnętrznymi — zerowa integracja: nie trzeba dodawać zależności w build.gradle ani modyfikować kodu aplikacji.

Architektura Android Profiler opiera się na Perfetto — systemowym tracerze Androida, który zbiera dane na poziomie jądra i aplikacji. Perfetto zapewnia minimalny narzut (poniżej 1% CPU) i obsługuje długoterminowe nagrywanie do 30 minut. Pozwala to profilować nie tylko szybkie operacje, ale także długie scenariusze — przejścia między ekranami, synchronizację w tle, zużycie pamięci w ciągu godziny użytkowania.

Jakie dane zbiera Android Profiler

Profiler zbiera cztery typy danych: CPU — obciążenie każdego rdzenia i wątku, Memory — Java Heap, Native Heap, Stack, Graphics, Network — wszystkie przychodzące i wychodzące żądania, Energy — kategorie zużycia energii (Idle, Light, Medium, Heavy). Dane są zsynchronizowane w osi czasu — można jednocześnie zobaczyć, jak zmiana CPU wpływa na pamięć i zużycie energii.

CPU Profiler: analiza procesora i wątków

CPU Profiler pokazuje obciążenie procesora w czasie rzeczywistym na osi czasu, podzielone według wątków aplikacji. Każdy wątek jest reprezentowany kolorową linią lub obszarem — im szerszy obszar, tym więcej czasu procesora zajmuje wątek. Obszary czerwone oznaczają pracę aplikacji, niebieskie — wywołania systemowe, szare — oczekiwanie.

Do szczegółowej analizy CPU Profiler obsługuje trzy tryby nagrywania: Trace Java Methods (tracowanie wszystkich metod Java), Trace C/C++ Functions (tracowanie funkcji natywnych NDK) i Sample Java Methods (próbkowanie, tryb zalecany). Próbkowanie daje najmniejszy narzut i nadaje się do codziennego profilowania, a pełne tracowanie — do znajdowania złożonych problemów.

// Przykład: analiza CPU Profiler pokaże tę metodę jako bottleneck
class DataProcessor {
    suspend fun processLargeDataset(items: List<Item>): List<Result> {
        // CPU Profiler pokaże wysokie obciążenie CPU w inBackgroundThread
        return withContext(Dispatchers.Default) {
            items.map { it.computeHeavyTransformation() }
        }
    }
}

// Zalecenie po profilowaniu:
// computeHeavyTransformation zajmuje 80% czasu — buforujemy wynik
class DataProcessorOptimized {
    private val cache = LruCache<String, Result>(100)

    suspend fun processLargeDataset(items: List<Item>): List<Result> {
        return withContext(Dispatchers.Default) {
            items.mapNotNull { cache.get(it.id) ?: it.computeHeavyTransformation().also { cache.put(it.id, it) } }
        }
    }
}

Po nagraniu CPU Profiler pokazuje Top-Down Tree — drzewo wywołań z czasem wykonania każdej metody. Zwracaj uwagę na kolumnę Self Time/Total: jeśli Self Time metody przekracza 16 ms i jest wywoływana z wątku UI — to gwarantowane pominięcie klatki. Rozwiązanie — przenieść ciężkie obliczenia do wątku tła przez Dispatchers.IO lub Default.

Tryby tracowania CPU

Sample Java Methods — zalecany tryb do codziennego profilowania z narzutem 3–5%. Trace Java Methods — pełne tracowanie każdego wywołania, narzut do 15%, używany do krótkich nagrań (5–10 sekund). Trace C/C++ Functions — tracowanie kodu NDK przez Linux Perf, niezbędny do analizy gier i bibliotek w C++. Przełączaj tryby w zależności od typu problemu.

Memory Profiler: praca z pamięcią i znajdowanie wycieków

Memory Profiler śledzi wszystkie kategorie pamięci aplikacji: Java Heap (obiekty JVM), Native Heap (alokacje C/C++ przez JNI), Stack (stosy wątków) i Graphics (tekstury, bufory GPU). Główna wizualizacja — wykres czasowy zużycia pamięci, gdzie każda kategoria jest oznaczona własnym kolorem. Jeśli wykres nie spada po czyszczeniu pamięci (GC) — podejrzewaj wyciek.

Do znajdowania wycieków używaj funkcji Capture Heap Dump. W momencie zrzutu Android Profiler zatrzymuje aplikację na ~100 ms i tworzy plik HPROF — pełny obraz wszystkich żywych obiektów Java Heap. Po otwarciu zrzutu możesz sortować obiekty według Retained Size (objętość pamięci, która zostanie zwolniona po usunięciu obiektu) i szukać instancji Activity, Fragment lub Bitmap, które powinny zostać zniszczone.

Według danych Google I/O 2022, Memory Profiler w połączeniu z LeakCanary pokrywa 95% scenariuszy wykrywania wycieków pamięci na Androidzie. LeakCanary działa automatycznie — wykrywa wyciek w tle. Memory Profiler jest potrzebny do ręcznej analizy: widzisz pełny obraz alokacji, a nie tylko wycieki.

Jak interpretować zrzut HPROF

Po przechwyceniu zrzutu sortuj obiekty według Retained Size — to objętość pamięci, która zostanie zwolniona po usunięciu obiektu. Szukaj instancji Activity, Fragment i Bitmap z dużym Retained Size, które nie powinny znajdować się w pamięci. Przejdź do zakładki Reference Tree, aby zobaczyć łańcuch referencji utrzymujących obiekt — najczęściej jest to statyczne pole singletona lub nieoczyszczony callback. Ważna metryka — Allocation rate (liczba alokacji na sekundę). Jeśli allocation rate przekracza 10 000 obiektów/s, aplikacja traci zbyt dużo czasu na tworzenie i usuwanie tymczasowych obiektów, co obciąża GC i powoduje mikroprzycięcia. W takim przypadku użyj narzędzia View Inspector i znajdź miejsca z częstym tworzeniem obiektów w pętlach.

Network Profiler: monitorowanie żądań sieciowych

Network Profiler wyświetla wszystkie żądania sieciowe aplikacji w czasie rzeczywistym na osi czasu. Każde żądanie jest pokazywane jako poziomy pasek — jego długość odpowiada czasowi wykonania, kolor — typowi żądania (GET, POST, PUT, DELETE). Przewijanie osi pozwala zobaczyć, jak żądania są rozłożone w czasie i czy się nie dublują.

Obsługiwane są wszystkie popularne biblioteki: OkHttp, Retrofit, Volley, Ktor. Dla Ktor i OkHttp profiler pokazuje pełny stos wywołań, w tym przechwytywacze (interceptory) i konwertery. Dla każdego żądania dostępne są Request Headers i Response Headers, treść odpowiedzi (do 1 MB), kod statusu i czas trwania.

Typowe problemy wykrywane przez Network Profiler: brak buforowania (ten sam URL jest żądany przy każdym otwarciu), dublujące się żądania (dwa komponenty jednocześnie ładują te same dane), nadmierny rozmiar odpowiedzi (serwer zwraca 5 MB, gdy potrzeba 50 KB). Network Profiler pomaga zobaczyć takie problemy dosłownie jednym spojrzeniem na oś czasu.

Do emulacji wolnych sieci używaj Network Conditioning w Android Studio — pozwala ograniczyć przepustowość do 3G/2G i dodać opóźnienie. Jest to kluczowe do testowania zachowania aplikacji w złych warunkach sieciowych, szczególnie dla aplikacji działających w regionach z niestabilnym internetem.

Energy Profiler: analiza zużycia energii

Energy Profiler ocenia wpływ aplikacji na poziom baterii na podstawie danych Perfetto. Narzędzie nie mierzy rzeczywistego poboru w miliamperach, ale klasyfikuje każdą operację do jednej z pięciu kategorii zużycia energii: Idle, Light, Medium, High i Overloaded. Oś czasu Energy Profiler jest podświetlana kolorem: zielony (lekkie obciążenie), żółty (średnie), czerwony (wysokie).

Główne przyczyny pojawiania się czerwonych stref: WakeLock (aplikacja utrzymuje procesor aktywnym), Location GPS (ciągłe żądania współrzędnych z wysoką dokładnością), połączenia Keep-Alive (częsta wymiana danych z serwerem), duże transmisje danych (wysyłanie plików, streaming). Energy Profiler dokładnie pokazuje, która operacja w którym momencie spowodowała szczyt zużycia energii.

Według danych Android Developers, typowa aplikacja powinna spędzać nie więcej niż 5% czasu w kategorii High. Jeśli Energy Profiler pokazuje czerwone strefy dłużej niż 10% czasu profilowania — aplikacja nie przejdzie przeglądu pod kątem kryterium Battery Drain. Zalecenie — używaj WorkManager do zadań w tle, ogranicz żądania Location do minimalnie wymaganej dokładności i agreguj żądania sieciowe w batche.

Jak używać Android Profiler: praktyczny przewodnik

Uruchomienie Android Profiler wykonuje się jednym kliknięciem: w Android Studio otwórz View → Tool Windows → Profiler lub kliknij dwukrotnie ikonę Profiler w prawym panelu. Po uruchomieniu aplikacji na podłączonym urządzeniu Android Studio automatycznie połączy się z procesem i zacznie zbierać dane. Na osi czasu natychmiast pojawią się wykresy CPU, Memory, Network i Energy.

Do szczegółowej analizy wybierz odpowiednią zakładkę (CPU, Memory, Network lub Energy) i rozpocznij nagrywanie. Dla CPU zalecam tryb Sample Java Methods z czasem nagrywania 30 sekund — to wystarczy dla typowego scenariusza. Dla Memory — zrzut sterty po wykonaniu scenariusza (Capture Heap Dump). Dla Network nagrywanie uruchamia się automatycznie, wystarczy nacisnąć przycisk Stop po zakończeniu scenariusza.

Po zatrzymaniu nagrywania wyeksportuj dane: File → Save As zapisuje całą sesję do pliku .perf. Jest to wygodne do porównywania metryk przed i po optymalizacji. Utwórz sesję baseline na pierwszej stabilnej wersji i porównuj z nią każdą nową sesję — to jedyny sposób obiektywnej oceny zmian wydajności.

Automatyzacja profilowania w CI

Android Profiler można uruchamiać z wiersza poleceń przez Android Studio CLI i Firebase Test Lab. Firebase Test Lab obsługuje profilowanie wydajności jako część testów UI: otrzymujesz metryki CPU, Memory i Network wraz z wynikiem testu. Skonfiguruj pipeline tak, aby przy spadku metryk o 10% względem baseline pipeline CI był blokowany do sprawdzenia przez programistę.