Network Inspector: cos'è, principio di funzionamento e monitoraggio delle richieste di rete

Cos'è Network Inspector?

Network Inspector è uno strumento di profilazione dell'attività di rete integrato in Android Studio. Consente agli sviluppatori di visualizzare in tempo reale tutte le richieste HTTP e HTTPS inviate dall'applicazione, incluse intestazioni, corpo della richiesta e della risposta, codici di stato e durata di esecuzione. Disponibile tramite il pannello Android Profiler a partire da Android Studio 3.0.

Scopo e ambito di applicazione

Il compito principale di Network Inspector è il debug dell'interazione di rete tra l'applicazione mobile e il server. Lo strumento viene utilizzato per verificare la correttezza dei dati trasmessi, analizzare il tempo di risposta, cercare errori API e individuare modelli di rete non ottimali, ad esempio richieste multiple durante il caricamento di una singola schermata. Network Inspector funziona su qualsiasi dispositivo con API Level 14.

Compatibilità e librerie

Lo strumento supporta tutti i principali client HTTP di Android: OkHttp (dalla versione 2.x), Retrofit, Ktor (KMM), UrlConnection, Apache HttpClient (obsoleto) e WebView. Per OkHttp e Retrofit è necessaria la libreria OkHttp Profiler, che si collega automaticamente quando si utilizza Android Studio 4.1+. Per Ktor è necessaria una configurazione separata dell'interceptor.

Come funziona Network Inspector

Network Inspector intercetta le chiamate di rete a livello di sistema utilizzando il meccanismo Profiler Agent, iniettato insieme ad Android Profiler. Per un funzionamento corretto è richiesta una build di debug dell'applicazione. Lo strumento non modifica il codice dell'applicazione e non richiede l'aggiunta di dipendenze per le funzionalità di base.

Meccanismo di intercettazione del traffico

All'avvio della profilazione, Network Inspector si collega al processo di debug dell'applicazione e ascolta tutte le chiamate HTTP che passano attraverso OkHttp Client, UrlConnection o altre librerie supportate. Ogni richiesta viene registrata con un timestamp, il che consente di costruire una timeline dell'attività di rete. Per HTTPS viene utilizzato un livello di sistema, che preserva la crittografia durante la trasmissione ma consente di visualizzare il contenuto decodificato all'interno di Studio.

Architettura di raccolta dei dati

La raccolta dei dati avviene tramite il Profiler Service di Android Studio, che opera in un processo host separato. Sul dispositivo opera un agente leggero che trasmette i metadati delle richieste attraverso il canale ADB. Ciò minimizza l'impatto sulle prestazioni dell'applicazione: l'overhead è inferiore al 3% secondo i dati di Google. I dati delle richieste stessi (corpo, intestazioni) vengono trasmessi solo durante la visualizzazione attiva dei dettagli.

// Configurazione di OkHttp per l'integrazione con Network Inspector
val client = OkHttpClient.Builder()
    .addInterceptor(HttpLoggingInterceptor().apply {
        level = HttpLoggingInterceptor.Level.BASIC
    })
    .build()

// Network Inspector intercetta automaticamente tutte le chiamate tramite client
client.newCall(Request.Builder()
    .url("https://api.example.com/data")
    .build()).execute()

Funzionalità principali di Network Inspector

Network Inspector fornisce un set di strumenti per un'analisi completa del traffico di rete. Ogni funzionalità è finalizzata a risolvere un compito specifico di debug, dalla verifica delle intestazioni all'analisi delle prestazioni dell'API.

Timeline delle richieste

La schermata principale di Network Inspector mostra la cronologia di tutte le richieste sotto forma di timeline. Ogni richiesta è rappresentata da una barra colorata: verde — risposta riuscita (2xx), blu — reindirizzamento (3xx), giallo — errore del client (4xx), rosso — errore del server (5xx). La lunghezza della barra corrisponde al tempo di esecuzione della richiesta, dalla connessione alla ricezione della risposta completa. Ciò consente di individuare immediatamente le richieste lente o quelle fallite con errore.

Visualizzazione dettagliata della richiesta

Quando si seleziona una richiesta specifica, si apre un pannello con i dettagli: Headers (tutte le intestazioni della richiesta e della risposta), Request Body (corpo della richiesta in formato testo o binario), Response Body (corpo della risposta con opzione di formattazione JSON), Cookies (inviati e ricevuti), Timing (ripartizione del tempo per fasi: DNS, Connection, TLS Handshake, Request, Response).

Filtraggio e ricerca

Network Inspector supporta il filtraggio delle richieste per URL, metodo HTTP, codice di stato e tipo di contenuto. È possibile escludere le richieste verso determinati domini per concentrarsi solo sull'API desiderata. La ricerca funziona su tutti i campi della richiesta, inclusi corpo e intestazioni, il che è comodo durante il debug di una specifica funzione dell'applicazione. I filtri combinati consentono di creare un insieme di regole che viene applicato automaticamente a ogni avvio della profilazione.

Raggruppamento e confronto delle richieste

La timeline supporta il raggruppamento delle richieste per modelli URL. Ad esempio, tutte le richieste del tipo /api/v2/users/* possono essere compresse in un unico gruppo. Ciò semplifica l'analisi quando l'applicazione esegue centinaia di richieste in breve tempo. La funzione di confronto delle richieste adiacenti aiuta a rilevare i cambiamenti nelle risposte del server in chiamate ripetute.

Debug delle richieste di rete con Network Inspector

L'uso pratico di Network Inspector comprende scenari tipici di debug: verifica del formato dei dati, individuazione di endpoint lenti, rilevamento di perdite di memoria dovute a connessioni non chiuse e analisi della memorizzazione nella cache.

Verifica della struttura della risposta JSON

Un compito frequente è assicurarsi che il server restituisca i dati nel formato atteso. Network Inspector mostra il corpo della risposta con formattazione JSON, inclusa l'evidenziazione della sintassi. Se la risposta non viene analizzata sul client, nell'ispettore si vede subito la causa: campo mancante, tipo di dati errato (stringa invece di numero) o annidamento eccessivo. Se il server restituisce un errore, l'ispettore mostra la struttura dell'errore con codice e messaggio. Per i formati binari (Protocol Buffers, immagini) vengono mostrati dimensione e content-type.

Analisi del tempo di esecuzione

La scheda Timing suddivide l'esecuzione della richiesta in fasi: DNS Resolution, TCP Connection, TLS Handshake, Request Send, Response Receive. Se il tempo totale supera 1-2 secondi, dalla ripartizione per fasi si può determinare la causa. Ad esempio, un DNS lento indica problemi con il resolver, un TLS Handshake lento indica una versione obsoleta del protocollo sul server, un Response lento indica codice server lento o una richiesta inefficiente con dati eccessivi. L'analisi Timing aiuta a individuare i colli di bottiglia ancor prima di iniziare l'ottimizzazione della parte server.

Ricerca di richieste duplicate

Network Inspector aiuta a individuare richieste ridondanti, ad esempio quando l'Activity ricrea il caricamento dei dati a ogni rotazione dello schermo. Nella timeline, una serie di richieste identiche consecutive indica chiaramente il problema. La soluzione può essere la memorizzazione nella cache, l'uso di un ViewModel con conservazione dello stato o SingleLiveEvent per un caricamento unico.

// Memorizzazione nella cache delle richieste con OkHttp per eliminare i duplicati
val cache = Cache(
    File(context.cacheDir, "http_cache"),
    cacheSize = 10L * 1024 * 1024 // 10 MB
)

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

Limiti di Network Inspector e alternative

Nonostante le ampie funzionalità, Network Inspector presenta una serie di limiti che è importante considerare. Per alcuni scenari, come l'intercettazione di HTTPS con certificati autofirmati o l'analisi del traffico di librerie di terze parti, possono essere necessari strumenti alternativi.

Limiti per piattaforme e librerie

Network Inspector funziona solo con applicazioni Android e non supporta iOS. Per Kotlin Multiplatform (KMM), parte delle richieste potrebbe non essere visualizzata se eseguita nella parte nativa. Alcune librerie, ad esempio gRPC, WebSocket (non HTTP), GraphQL tramite Apollo (fino alla versione 3.x), possono essere intercettate parzialmente o per niente finché non vengono configurati interceptor aggiuntivi.

Strumenti alternativi

Per un'analisi più approfondita del traffico di rete esistono soluzioni di terze parti: Charles Proxy (proxy completo con intercettazione HTTPS), Proxyman (analogo per macOS), Wireshark (analisi a livello di pacchetti), Stetho by Facebook (integrazione con Chrome DevTools), Chucker (libreria per l'ispezione delle richieste all'interno dell'app). Ogni strumento ha la sua nicchia: Charles e Proxyman sono indispensabili durante il debug dell'interazione con il server nelle prime fasi di sviluppo, mentre Chucker per la raccolta di informazioni nelle build di test.