Network Inspector — ce este, principiul de funcționare și monitorizarea cererilor de rețea

Ce este Network Inspector?

Network Inspector este un instrument de profilare a activității de rețea încorporat în Android Studio. Permite dezvoltatorilor să vizualizeze în timp real toate cererile HTTP și HTTPS trimise de aplicație, inclusiv anteturi, corpul cererii și răspunsului, coduri de status și durata de execuție. Este disponibil prin panoul Android Profiler începând cu Android Studio 3.0.

Scop și domeniu de aplicare

Sarcina principală a Network Inspector este depanarea interacțiunii de rețea a aplicației mobile cu serverul. Instrumentul este utilizat pentru verificarea corectitudinii datelor transmise, analiza timpului de răspuns, căutarea erorilor API, precum și pentru detectarea模式lor de rețea neoptimale — de exemplu, cereri multiple la încărcarea unui ecran. Network Inspector funcționează pe orice dispozitiv cu API Level 14.

Compatibilitate și biblioteci

Instrumentul suportă toți clienții HTTP principali Android: OkHttp (începând cu versiunea 2.x), Retrofit, Ktor (KMM), UrlConnection, Apache HttpClient (învechit) și WebView. Pentru OkHttp și Retrofit este necesară biblioteca OkHttp Profiler — se adaugă automat când se utilizează Android Studio 4.1+. Pentru Ktor este necesară o configurare separată a interceptoarelor.

Cum funcționează Network Inspector

Network Inspector interceptează apelurile de rețea la nivel de sistem, utilizând mecanismul Profiler Agent, implementat împreună cu Android Profiler. Pentru funcționarea corectă este necesară o compilare debug a aplicației. Instrumentul nu modifică codul aplicației și nu necesită adăugarea de dependențe pentru funcționalitatea de bază.

Mecanismul de interceptare a traficului

La pornirea profilării, Network Inspector se conectează la procesul Debug al aplicației și ascultă toate apelurile HTTP care trec prin OkHttp Client, UrlConnection sau alte biblioteci suportate. Fiecare cerere este înregistrată cu un marcaj temporal, ceea ce permite construirea unei linii temporale a activității de rețea. Pentru HTTPS se utilizează un strat intermediar de sistem, care păstrează criptarea în timpul transmiterii, dar permite vizualizarea conținutului decodat în Studio.

Arhitectura de colectare a datelor

Colectarea datelor are loc prin Profiler Service al Android Studio, care rulează într-un proces separat pe gazdă. Pe dispozitiv rulează un agent ușor care transmite metadatele cererilor prin canalul ADB. Acest lucru minimizează impactul asupra performanței aplicației — suprasarcina este sub 3% conform datelor Google. Datele cererilor în sine (corp, anteturi) sunt transmise doar în timpul vizualizării active a detaliilor.

// Conectarea OkHttp pentru integrarea cu Network Inspector
val client = OkHttpClient.Builder()
    .addInterceptor(HttpLoggingInterceptor().apply {
        level = HttpLoggingInterceptor.Level.BASIC
    })
    .build()

// Network Inspector interceptează automat toate apelurile prin client
client.newCall(Request.Builder()
    .url("https://api.example.com/data")
    .build()).execute()

Principalele capacități ale Network Inspector

Network Inspector oferă un set de instrumente pentru analiza cuprinzătoare a traficului de rețea. Fiecare funcție este orientată spre rezolvarea unei sarcini specifice de depanare — de la verificarea anteturilor până la analiza performanței API.

Linia temporală a cererilor

Ecranul principal al Network Inspector afișează cronologia tuturor cererilor sub formă de linie temporală. Fiecare cerere este reprezentată printr-o bară colorată: verde — răspuns de succes (2xx), albastru — redirecționare (3xx), galben — eroare client (4xx), roșu — eroare server (5xx). Lungimea barei corespunde timpului de execuție a cererii de la conectare până la primirea răspunsului complet. Acest lucru permite identificarea imediată a cererilor lente sau cu erori.

Vizualizarea detaliată a cererii

La selectarea unei cereri specifice, se deschide un panou cu detalii: Headers (toate anteturile cererii și răspunsului), Request Body (corpul cererii în format text sau binar), Response Body (corpul răspunsului cu posibilitatea formatării JSON), Cookies (trimise și primite), Timing (împărțirea timpului pe faze: DNS, Connection, TLS Handshake, Request, Response).

Filtrare și căutare

Network Inspector suportă filtrarea cererilor după URL, metodă HTTP, cod de status și tip de conținut. Se pot exclude cererile către domenii specifice pentru a se concentra doar pe API-ul necesar. Căutarea funcționează în toate câmpurile cererii, inclusiv corp și anteturi, ceea ce este convenabil la depanarea unei funcții specifice a aplicației. Filtrele combinate permit crearea unui set de reguli care se aplică automat la fiecare pornire a profilării.

Gruparea și compararea cererilor

Linia temporală suportă gruparea cererilor după șabloane URL. De exemplu, toate cererile de forma /api/v2/users/* pot fi grupate împreună. Acest lucru simplifică analiza atunci când aplicația efectuează sute de cereri într-un timp scurt. Funcția de comparare a cererilor adiacente ajută la identificarea modificărilor în răspunsurile serverului la apeluri repetate.

Depanarea cererilor de rețea cu Network Inspector

Utilizarea practică a Network Inspector acoperă scenarii tipice de depanare: verificarea formatului datelor, detectarea endpointurilor lente, găsirea scurgerilor de memorie cauzate de conexiuni neînchise și analiza cache-ului.

Verificarea structurii răspunsului JSON

O sarcină frecventă — să vă asigurați că serverul returnează datele în formatul așteptat. Network Inspector afișează corpul răspunsului cu formatare JSON, inclusiv evidențierea sintaxei. Dacă răspunsul nu se parsează pe client, în inspector se vede imediat cauza: absența unui câmp, tip de date incorect (șir în loc de număr) sau înglobare excesivă. Dacă serverul returnează o eroare, inspectorul arată structura erorii cu cod și mesaj. Pentru formate binare (Protocol Buffers, imagini) se afișează dimensiunea și content-type.

Analiza timpului de execuție

Fila Timing împarte execuția cererii în faze: DNS Resolution, TCP Connection, TLS Handshake, Request Send, Response Receive. Dacă timpul total depășește 1–2 secunde, pe baza împărțirii pe faze se poate determina cauza. De exemplu, un DNS lung indică probleme cu rezolvatorul, un TLS Handshake lung — o versiune învechită a protocolului pe server, un Response lung — cod de server lent sau o cerere ineficientă cu date redundante. Analiza Timing ajută la identificarea blocajelor chiar înainte de începerea optimizării părții de server.

Căutarea cererilor duplicate

Network Inspector ajută la detectarea cererilor redundante — de exemplu, când la fiecare rotire a ecranului Activity reîncarică datele. Pe linia temporală, o serie de cereri identice una după alta indică clar problema. Soluția poate fi cache-ul, utilizarea ViewModel cu păstrarea stării sau SingleLiveEvent pentru încărcare unică.

// Stocarea în cache a cererilor cu OkHttp pentru eliminarea duplicării
val cache = Cache(
    File(context.cacheDir, "http_cache"),
    cacheSize = 10L * 1024 * 1024 // 10 MB
)

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

Limitările Network Inspector și alternative

În ciuda capacităților largi, Network Inspector are o serie de limitări care trebuie luate în considerare. Pentru unele scenarii — cum ar fi interceptarea HTTPS cu certificate auto-semnate sau analiza traficului bibliotecilor terțe — pot fi necesare instrumente alternative.

Limitări de platformă și biblioteci

Network Inspector funcționează doar cu aplicații Android și nu suportă iOS. Pentru Kotlin Multiplatform (KMM) o parte din cereri pot să nu se afișeze dacă sunt executate în partea native. Unele biblioteci — de exemplu, gRPC, WebSocket (nu HTTP), GraphQL prin Apollo (până la versiunea 3.x) — pot fi interceptate parțial sau deloc fără configurarea interceptoarelor suplimentare.

Instrumente alternative

Pentru o analiză mai profundă a traficului de rețea există soluții terțe: Charles Proxy (server proxy complet cu interceptare HTTPS), Proxyman (analog pentru macOS), Wireshark (analiză la nivel de pachete), Stetho by Facebook (integrare cu Chrome DevTools), Chucker (bibliotecă pentru inspecția cererilor în interiorul aplicației). Fiecare instrument are nișa sa: Charles și Proxyman sunt indispensabile la depanarea interacțiunii cu serverul în etapele incipiente de dezvoltare, iar Chucker — pentru colectarea informațiilor în compilările de test.