Network Inspector — co to jest, zasada działania i monitorowanie żądań sieciowych

Czym jest Network Inspector?

Network Inspector to narzędzie do profilowania aktywności sieciowej wbudowane w Android Studio. Pozwala programistom przeglądać w czasie rzeczywistym wszystkie żądania HTTP i HTTPS wysyłane przez aplikację, w tym nagłówki, treść żądania i odpowiedzi, kody statusu oraz czas wykonania. Jest dostępny przez panel Android Profiler od wersji Android Studio 3.0.

Przeznaczenie i zakres zastosowania

Głównym zadaniem Network Inspector jest debugowanie interakcji sieciowej aplikacji mobilnej z serwerem. Narzędzie służy do sprawdzania poprawności przesyłanych danych, analizy czasu odpowiedzi, wyszukiwania błędów API oraz wykrywania nieoptymalnych wzorców sieciowych — na przykład wielokrotnych zapytań podczas ładowania jednego ekranu. Network Inspector działa na każdym urządzeniu z API Level 14.

Kompatybilność i biblioteki

Narzędzie obsługuje wszystkie główne klienty HTTP Androida: OkHttp (od wersji 2.x), Retrofit, Ktor (KMM), UrlConnection, Apache HttpClient (przestarzały) i WebView. Dla OkHttp i Retrofit wymagana jest biblioteka OkHttp Profiler — dodawana automatycznie przy użyciu Android Studio 4.1+. Dla Ktor wymagana jest osobna konfiguracja przechwytywacza.

Jak działa Network Inspector

Network Inspector przechwytuje wywołania sieciowe na poziomie systemu, wykorzystując mechanizm Profiler Agent, wdrażany wraz z Android Profiler. Do poprawnego działania wymagana jest kompilacja debug aplikacji. Narzędzie nie modyfikuje kodu aplikacji i nie wymaga dodawania zależności dla podstawowej funkcjonalności.

Mechanizm przechwytywania ruchu

Po uruchomieniu profilowania Network Inspector łączy się z procesem Debug aplikacji i nasłuchuje wszystkich wywołań HTTP przechodzących przez OkHttp Client, UrlConnection lub inne obsługiwane biblioteki. Każde żądanie jest rejestrowane ze znacznikiem czasu, co umożliwia zbudowanie osi czasu aktywności sieciowej. Dla HTTPS używana jest systemowa warstwa pośrednia, która zachowuje szyfrowanie podczas transmisji, ale pozwala przeglądać zdekodowaną zawartość w Studio.

Architektura zbierania danych

Zbieranie danych odbywa się przez Profiler Service Android Studio, który działa w osobnym procesie hosta. Na urządzeniu działa lekki agent przesyłający metadane żądań kanałem ADB. Minimalizuje to wpływ na wydajność aplikacji — narzut wynosi poniżej 3% według danych Google. Same dane żądań (treść, nagłówki) są przesyłane tylko podczas aktywnego przeglądania szczegółów.

// Podłączenie OkHttp do integracji z Network Inspector
val client = OkHttpClient.Builder()
    .addInterceptor(HttpLoggingInterceptor().apply {
        level = HttpLoggingInterceptor.Level.BASIC
    })
    .build()

// Network Inspector automatycznie przechwytuje wszystkie wywołania przez client
client.newCall(Request.Builder()
    .url("https://api.example.com/data")
    .build()).execute()

Główne możliwości Network Inspector

Network Inspector dostarcza zestaw narzędzi do wszechstronnej analizy ruchu sieciowego. Każda funkcja jest ukierunkowana na rozwiązanie konkretnego zadania debugowania — od sprawdzania nagłówków po analizę wydajności API.

Oś czasu żądań

Główny ekran Network Inspector wyświetla chronologię wszystkich żądań w postaci osi czasu. Każde żądanie jest reprezentowane przez kolorowy pasek: zielony — odpowiedź sukcesu (2xx), niebieski — przekierowanie (3xx), żółty — błąd klienta (4xx), czerwony — błąd serwera (5xx). Długość paska odpowiada czasowi wykonania żądania od połączenia do otrzymania pełnej odpowiedzi. Pozwala to natychmiast zidentyfikować wolne lub zakończone błędem żądania.

Szczegółowy podgląd żądania

Po wybraniu konkretnego żądania otwiera się panel ze szczegółami: Headers (wszystkie nagłówki żądania i odpowiedzi), Request Body (treść żądania w formacie tekstowym lub binarnym), Response Body (treść odpowiedzi z możliwością formatowania JSON), Cookies (wysłane i odebrane), Timing (podział czasu na fazy: DNS, Connection, TLS Handshake, Request, Response).

Filtrowanie i wyszukiwanie

Network Inspector obsługuje filtrowanie żądań według URL, metody HTTP, kodu statusu i typu treści. Można wykluczyć żądania do określonych domen, aby skupić się tylko na potrzebnym API. Wyszukiwanie działa we wszystkich polach żądania, w tym treści i nagłówkach, co jest wygodne podczas debugowania konkretnej funkcji aplikacji. Filtry kombinowane pozwalają utworzyć zestaw reguł, które są automatycznie stosowane przy każdym uruchomieniu profilowania.

Grupowanie i porównywanie żądań

Oś czasu obsługuje grupowanie żądań według wzorców URL. Na przykład wszystkie żądania postaci /api/v2/users/* można zwinąć w jedną grupę. Upraszcza to analizę, gdy aplikacja wykonuje setki żądań w krótkim czasie. Funkcja porównywania sąsiednich żądań pomaga wykryć zmiany w odpowiedziach serwera przy ponownych wywołaniach.

Debugowanie żądań sieciowych za pomocą Network Inspector

Praktyczne użycie Network Inspector obejmuje typowe scenariusze debugowania: sprawdzanie formatu danych, wykrywanie wolnych endpointów, znajdowanie wycieków pamięci spowodowanych niezamkniętymi połączeniami oraz analizę buforowania.

Sprawdzanie struktury odpowiedzi JSON

Częste zadanie — upewnienie się, że serwer zwraca dane w oczekiwanym formacie. Network Inspector pokazuje treść odpowiedzi z formatowaniem JSON, w tym podświetlaniem składni. Jeśli odpowiedź nie parsuje się po stronie klienta, w inspektorze od razu widać przyczynę: brak pola, nieprawidłowy typ danych (ciąg znaków zamiast liczby) lub nadmiarowe zagnieżdżenie. Jeśli serwer zwraca błąd, inspektor pokazuje strukturę błędu z kodem i komunikatem. Dla formatów binarnych (Protocol Buffers, obrazy) wyświetlany jest rozmiar i content-type.

Analiza czasu wykonania

Zakładka Timing dzieli wykonanie żądania na fazy: DNS Resolution, TCP Connection, TLS Handshake, Request Send, Response Receive. Jeśli całkowity czas przekracza 1–2 sekundy, na podstawie podziału fazowego można określić przyczynę. Na przykład długi DNS wskazuje na problemy z resolverem, długi TLS Handshake — na przestarzałą wersję protokołu na serwerze, długi Response — na wolny kod serwera lub nieefektywne żądanie z nadmiarowymi danymi. Analiza Timing pomaga zidentyfikować wąskie gardła jeszcze przed rozpoczęciem optymalizacji części serwerowej.

Znajdowanie duplikujących się żądań

Network Inspector pomaga wykryć nadmiarowe żądania — na przykład gdy przy każdym obrocie ekranu Activity ponownie ładuje dane. Na osi czasu seria identycznych żądań pod rząd wyraźnie wskazuje problem. Rozwiązaniem może być buforowanie, użycie ViewModel z zachowaniem stanu lub SingleLiveEvent dla jednorazowego ładowania.

// Buforowanie żądań z OkHttp w celu eliminacji duplikacji
val cache = Cache(
    File(context.cacheDir, "http_cache"),
    cacheSize = 10L * 1024 * 1024 // 10 MB
)

val cachedClient = OkHttpClient.Builder()
    .cache(cache)
    .addNetworkInterceptor(CacheInterceptor())
    .build()

Ograniczenia Network Inspector i alternatywy

Mimo szerokich możliwości Network Inspector ma szereg ograniczeń, które należy wziąć pod uwagę. W niektórych scenariuszach — takich jak przechwytywanie HTTPS z certyfikatami samopodpisanymi lub analiza ruchu bibliotek stron trzecich — mogą być potrzebne alternatywne narzędzia.

Ograniczenia platform i bibliotek

Network Inspector działa tylko z aplikacjami Android i nie obsługuje iOS. W przypadku Kotlin Multiplatform (KMM) część żądań może nie być wyświetlana, jeśli są wykonywane w części native. Niektóre biblioteki — na przykład gRPC, WebSocket (nie HTTP), GraphQL przez Apollo (do wersji 3.x) — mogą być przechwytywane częściowo lub wcale bez dodatkowej konfiguracji przechwytywaczy.

Alternatywne narzędzia

Do głębszej analizy ruchu sieciowego istnieją rozwiązania zewnętrzne: Charles Proxy (pełnoprawny serwer proxy z przechwytywaniem HTTPS), Proxyman (odpowiednik dla macOS), Wireshark (analiza na poziomie pakietów), Stetho by Facebook (integracja z Chrome DevTools), Chucker (biblioteka do inspekcji żądań wewnątrz aplikacji). Każde narzędzie ma swoją niszę: Charles i Proxyman są niezastąpione podczas debugowania interakcji z serwerem na wczesnych etapach rozwoju, a Chucker — do zbierania informacji w kompilacjach testowych.