Network Inspector — wat het is, werkingsprincipe en monitoring van netwerkverzoeken

Wat is Network Inspector?

Network Inspector is een profileringsinstrument voor netwerkactiviteit dat is ingebouwd in Android Studio. Het stelt ontwikkelaars in staat om in realtime alle HTTP- en HTTPS-verzoeken van de app te bekijken, inclusief headers, verzoek- en antwoordbody, statuscodes en uitvoeringstijd. Beschikbaar via het Android Profiler-paneel vanaf Android Studio 3.0.

Doel en toepassingsgebied

De hoofdtaak van Network Inspector is het debuggen van de netwerkinteractie van de mobiele app met de server. Het instrument wordt gebruikt voor het controleren van de juistheid van verzonden gegevens, analyse van responstijd, zoeken naar API-fouten en het detecteren van suboptimale netwerkpatronen — zoals meerdere verzoeken bij het laden van één scherm. Network Inspector werkt op elk apparaat met API Level 14.

Compatibiliteit en bibliotheken

Het instrument ondersteunt alle belangrijke Android HTTP-cliënten: OkHttp (vanaf versie 2.x), Retrofit, Ktor (KMM), UrlConnection, Apache HttpClient (verouderd) en WebView. Voor OkHttp en Retrofit is de OkHttp Profiler-bibliotheek vereist — deze wordt automatisch toegevoegd bij gebruik van Android Studio 4.1+. Voor Ktor is een aparte interceptors-configuratie nodig.

Hoe werkt Network Inspector

Network Inspector onderschept netwerkoproepen op systeemniveau via het Profiler Agent-mechanisme, dat samen met Android Profiler wordt geïnjecteerd. Voor correcte werking is een debug-build van de app vereist. Het instrument wijzigt de app-code niet en vereist geen toevoeging van afhankelijkheden voor basisfunctionaliteit.

Mechanisme van verkeersonderschepping

Bij het starten van profilering verbindt Network Inspector zich met het Debug-proces van de app en luistert naar alle HTTP-aanroepen die via OkHttp Client, UrlConnection of andere ondersteunde bibliotheken gaan. Elk verzoek wordt geregistreerd met een tijdstempel, wat het mogelijk maakt een tijdlijn van netwerkactiviteit op te bouwen. Voor HTTPS wordt een systeemtussenlaag gebruikt die de codering tijdens verzending behoudt, maar het mogelijk maakt de gedecodeerde inhoud in Studio te bekijken.

Architectuur van gegevensverzameling

Gegevensverzameling vindt plaats via de Profiler Service van Android Studio, die in een apart hostproces draait. Op het apparaat draait een lichte agent die metadata van verzoeken via het ADB-kanaal verzendt. Dit minimaliseert de impact op de app-prestaties — de overhead is minder dan 3% volgens Google-gegevens. De eigenlijke verzoekgegevens (body, headers) worden alleen verzonden tijdens actieve weergave van details.

// OkHttp aansluiten voor integratie met Network Inspector
val client = OkHttpClient.Builder()
    .addInterceptor(HttpLoggingInterceptor().apply {
        level = HttpLoggingInterceptor.Level.BASIC
    })
    .build()

// Network Inspector onderschept automatisch alle aanroepen via client
client.newCall(Request.Builder()
    .url("https://api.example.com/data")
    .build()).execute()

Belangrijkste mogelijkheden van Network Inspector

Network Inspector biedt een set instrumenten voor uitgebreide analyse van netwerkverkeer. Elke functie is gericht op het oplossen van een specifieke debugtaak — van het controleren van headers tot het analyseren van API-prestaties.

Tijdlijn van verzoeken

Het hoofdscherm van Network Inspector toont de chronologie van alle verzoeken als een tijdlijn. Elk verzoek wordt weergegeven als een gekleurde balk: groen — succesvol antwoord (2xx), blauw — doorverwijzing (3xx), geel — clientfout (4xx), rood — serverfout (5xx). De lengte van de balk komt overeen met de uitvoeringstijd van het verzoek van verbinding tot ontvangst van het volledige antwoord. Dit maakt het mogelijk direct trage of foutieve verzoeken te identificeren.

Gedetailleerde weergave van een verzoek

Bij het selecteren van een specifiek verzoek opent een paneel met details: Headers (alle headers van verzoek en antwoord), Request Body (verzoekbody in tekst- of binair formaat), Response Body (antwoordbody met JSON-opmaakmogelijkheid), Cookies (verzonden en ontvangen), Timing (tijdsverdeling per fase: DNS, Connection, TLS Handshake, Request, Response).

Filteren en zoeken

Network Inspector ondersteunt filteren van verzoeken op URL, HTTP-methode, statuscode en inhoudstype. Verzoeken naar bepaalde domeinen kunnen worden uitgesloten om zich alleen op de benodigde API te concentreren. Zoeken werkt in alle velden van het verzoek, inclusief body en headers, wat handig is bij het debuggen van een specifieke app-functie. Gecombineerde filters maken het mogelijk een set regels te maken die automatisch worden toegepast bij elke profileringstart.

Groeperen en vergelijken van verzoeken

De tijdlijn ondersteunt groeperen van verzoeken op URL-patronen. Bijvoorbeeld, alle verzoeken van de vorm /api/v2/users/* kunnen in één groep worden samengevoegd. Dit vereenvoudigt de analyse wanneer de app honderden verzoeken in korte tijd uitvoert. De functie voor het vergelijken van aangrenzende verzoeken helpt bij het detecteren van veranderingen in serverantwoorden bij herhaalde aanroepen.

Netwerkverzoeken debuggen met Network Inspector

Praktisch gebruik van Network Inspector omvat typische debugscenario's: controleren van gegevensformaat, detecteren van trage endpoints, vinden van geheugenlekken door niet-gesloten verbindingen en analyseren van caching.

Controleren van JSON-antwoordstructuur

Een veelvoorkomende taak — controleren of de server gegevens in het verwachte formaat retourneert. Network Inspector toont de antwoordbody met JSON-opmaak, inclusief syntaxishighlighting. Als het antwoord niet aan clientzijde kan worden geparseerd, is in de inspector direct de oorzaak zichtbaar: ontbrekend veld, verkeerd gegevenstype (string in plaats van getal) of overmatige nesting. Als de server een fout retourneert, toont de inspector de foutstructuur met code en bericht. Voor binaire formaten (Protocol Buffers, afbeeldingen) worden grootte en content-type weergegeven.

Analyseren van uitvoeringstijd

Het tabblad Timing verdeelt de uitvoering van het verzoek in fasen: DNS Resolution, TCP Connection, TLS Handshake, Request Send, Response Receive. Als de totale tijd 1-2 seconden overschrijdt, kan op basis van de faseverdeling de oorzaak worden bepaald. Bijvoorbeeld, lange DNS wijst op problemen met de resolver, lange TLS Handshake op een verouderde protocolversie op de server, lange Response op trage servercode of een inefficiënt verzoek met overbodige gegevens. Timing-analyse helpt knelpunten te identificeren nog voordat optimalisatie van de serverkant begint.

Vinden van dubbele verzoeken

Network Inspector helpt bij het detecteren van overbodige verzoeken — bijvoorbeeld wanneer Activity bij elke schermrotatie het laden van gegevens opnieuw start. Op de tijdlijn wijst een reeks identieke verzoeken achter elkaar duidelijk op het probleem. De oplossing kan caching zijn, gebruik van ViewModel met toestandsbehoud of SingleLiveEvent voor eenmalig laden.

// Cachen van verzoeken met OkHttp om duplicatie te voorkomen
val cache = Cache(
    File(context.cacheDir, "http_cache"),
    cacheSize = 10L * 1024 * 1024 // 10 MB
)

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

Beperkingen van Network Inspector en alternatieven

Ondanks de uitgebreide mogelijkheden heeft Network Inspector een aantal beperkingen die in overweging moeten worden genomen. Voor sommige scenario's — zoals HTTPS-onderschepping met zelfondertekende certificaten of analyse van verkeer van bibliotheken van derden — kunnen alternatieve instrumenten nodig zijn.

Platform- en bibliotheekbeperkingen

Network Inspector werkt alleen met Android-apps en ondersteunt iOS niet. Voor Kotlin Multiplatform (KMM) kunnen sommige verzoeken niet worden weergegeven als ze in het native deel worden uitgevoerd. Sommige bibliotheken — zoals gRPC, WebSocket (niet HTTP), GraphQL via Apollo (tot versie 3.x) — kunnen gedeeltelijk of helemaal niet worden onderschept zonder configuratie van extra interceptors.

Alternatieve instrumenten

Voor diepgaandere analyse van netwerkverkeer bestaan oplossingen van derden: Charles Proxy (volledige proxyserver met HTTPS-onderschepping), Proxyman (equivalent voor macOS), Wireshark (analyse op pakketniveau), Stetho by Facebook (integratie met Chrome DevTools), Chucker (bibliotheek voor inspectie van verzoeken in de app). Elk instrument heeft zijn niche: Charles en Proxyman zijn onmisbaar bij het debuggen van serverinteractie in vroege ontwikkelingsfasen, en Chucker voor het verzamelen van informatie in test-builds.