Network Inspector — mi ez, működési elv és hálózati kérések monitorozása

Mi az a Network Inspector?

Network Inspector egy hálózati tevékenység profilozó eszköz, amely az Android Studio-ba van beépítve. Lehetővé teszi a fejlesztők számára, hogy valós időben megtekintsék az alkalmazás által küldött összes HTTP- és HTTPS-kérést, beleértve a fejléceket, a kérés és válasz törzsét, a státuszkódokat és a végrehajtás időtartamát. Az Android Studio 3.0-tól kezdve érhető el az Android Profiler panelen keresztül.

Cél és alkalmazási terület

A Network Inspector fő feladata a mobilalkalmazás szerverrel való hálózati interakciójának hibakeresése. Az eszközt az átvitt adatok helyességének ellenőrzésére, a válaszidők elemzésére, API-hibák keresésére, valamint nem optimális hálózati minták — például több kérés egy képernyő betöltésekor — észlelésére használják. A Network Inspector bármely API Level 14-es eszközön működik.

Kompatibilitás és könyvtárak

Az eszköz támogatja az összes főbb Android HTTP klienst: OkHttp (2.x verziótól), Retrofit, Ktor (KMM), UrlConnection, Apache HttpClient (elavult) és WebView. Az OkHttp és Retrofit esetében az OkHttp Profiler könyvtár szükséges — automatikusan hozzáadódik az Android Studio 4.1+ használatakor. A Ktor esetében külön interceptor konfiguráció szükséges.

Hogyan működik a Network Inspector

A Network Inspector rendszerszinten fogja el a hálózati hívásokat a Profiler Agent mechanizmus segítségével, amely az Android Profilerrel együtt kerül beillesztésre. A megfelelő működéshez az alkalmazás debug buildje szükséges. Az eszköz nem módosítja az alkalmazás kódját, és nem igényel függőségek hozzáadását az alapvető funkciókhoz.

A forgalomelfogás mechanizmusa

A profilozás elindításakor a Network Inspector csatlakozik az alkalmazás Debug folyamatához, és figyeli az OkHttp Client, UrlConnection vagy más támogatott könyvtárakon áthaladó összes HTTP-hívást. Minden kérés időbélyegzővel kerül rögzítésre, ami lehetővé teszi a hálózati tevékenység idővonalának felépítését. A HTTPS esetében egy rendszer-köztes réteg kerül használatra, amely megőrzi a titkosítást az átvitel során, de lehetővé teszi a dekódolt tartalom megtekintését a Studio-n belül.

Az adatgyűjtés architektúrája

Az adatgyűjtés az Android Studio Profiler Service-én keresztül történik, amely a gazdagép külön folyamatában fut. Az eszközön egy könnyűsúlyú ügynök fut, amely a kérések metaadatait az ADB csatornán keresztül továbbítja. Ez minimalizálja az alkalmazás teljesítményére gyakorolt hatást — a többletterhelés a Google adatai szerint kevesebb mint 3%. Maguk a kérésadatok (törzs, fejlécek) csak a részletek aktív megtekintésekor kerülnek továbbításra.

// OkHttp csatlakoztatása a Network Inspector-ral való integrációhoz
val client = OkHttpClient.Builder()
    .addInterceptor(HttpLoggingInterceptor().apply {
        level = HttpLoggingInterceptor.Level.BASIC
    })
    .build()

// A Network Inspector automatikusan elfogja az összes hívást a client-en keresztül
client.newCall(Request.Builder()
    .url("https://api.example.com/data")
    .build()).execute()

A Network Inspector fő képességei

A Network Inspector eszközkészletet biztosít a hálózati forgalom átfogó elemzéséhez. Minden funkció egy adott hibakeresési feladat megoldására irányul — a fejlécek ellenőrzésétől az API-teljesítmény elemzéséig.

Kérések idővonala

A Network Inspector főképernyője az összes kérés kronológiáját idővonal formájában jeleníti meg. Minden kérést egy színes sáv képvisel: zöld — sikeres válasz (2xx), kék — átirányítás (3xx), sárga — kliens hiba (4xx), piros — szerver hiba (5xx). A sáv hossza megfelel a kérés végrehajtási idejének a kapcsolódástól a teljes válasz megérkezéséig. Ez lehetővé teszi a lassú vagy hibás kérések azonnali azonosítását.

Kérés részletes nézete

Egy adott kérés kiválasztásakor egy panel nyílik meg a részletekkel: Headers (a kérés és válasz összes fejléce), Request Body (a kérés törzse szöveges vagy bináris formátumban), Response Body (a válasz törzse JSON formázási lehetőséggel), Cookies (küldött és fogadott), Timing (az idő fázisokra bontása: DNS, Connection, TLS Handshake, Request, Response).

Szűrés és keresés

A Network Inspector támogatja a kérések szűrését URL, HTTP metódus, státuszkód és tartalomtípus szerint. Bizonyos domainekre irányuló kérések kizárhatók, hogy csak a szükséges API-ra lehessen összpontosítani. A keresés a kérés összes mezőjében működik, beleértve a törzset és a fejléceket is, ami kényelmes az alkalmazás egy adott funkciójának hibakeresésekor. A kombinált szűrők lehetővé teszik olyan szabálykészlet létrehozását, amely automatikusan alkalmazásra kerül minden profilozás indításakor.

Kérések csoportosítása és összehasonlítása

Az idővonal támogatja a kérések csoportosítását URL-minták szerint. Például az összes /api/v2/users/* formájú kérés egy csoportba vonható össze. Ez leegyszerűsíti az elemzést, amikor az alkalmazás rövid idő alatt több száz kérést hajt végre. A szomszédos kérések összehasonlítására szolgáló funkció segít észlelni a szerver válaszaiban bekövetkező változásokat ismételt hívások esetén.

Hálózati kérések hibakeresése a Network Inspector segítségével

A Network Inspector gyakorlati használata tipikus hibakeresési forgatókönyveket fed le: az adatformátum ellenőrzése, lassú végpontok észlelése, a le nem zárt kapcsolatok miatti memóriaszivárgások megtalálása és a gyorsítótárazás elemzése.

JSON válasz szerkezetének ellenőrzése

Gyakori feladat — meggyőződni arról, hogy a szerver a várt formátumban adja vissza az adatokat. A Network Inspector a válasz törzsét JSON formázással, szintaxiskiemeléssel jeleníti meg. Ha a válasz nem értelmezhető a kliens oldalon, az inspektorban azonnal látható az ok: hiányzó mező, helytelen adattípus (szám helyett karakterlánc) vagy túlzott beágyazottság. Ha a szerver hibát ad vissza, az inspektor megjeleníti a hiba szerkezetét kóddal és üzenettel. Bináris formátumok (Protocol Buffers, képek) esetén a méret és a content-type jelenik meg.

Végrehajtási idő elemzése

A Timing fül a kérés végrehajtását fázisokra bontja: DNS Resolution, TCP Connection, TLS Handshake, Request Send, Response Receive. Ha a teljes idő meghaladja az 1-2 másodpercet, a fázisbontás alapján meghatározható az ok. Például a hosszú DNS a resolver problémáira, a hosszú TLS Handshake a szerver elavult protokollverziójára, a hosszú Response pedig lassú szerverkódra vagy hatékonytalan, felesleges adatokat tartalmazó kérésre utal. A Timing elemzés segít a szűk keresztmetszetek azonosításában még a szerveroldal optimalizálásának megkezdése előtt.

Duplikált kérések keresése

A Network Inspector segít a felesleges kérések észlelésében — például amikor a képernyő minden elforgatásakor az Activity újratölti az adatokat. Az idővonalon egymás utáni azonos kérések sorozata egyértelműen jelzi a problémát. A megoldás lehet gyorsítótárazás, állapotmegőrző ViewModel vagy SingleLiveEvent használata egyszeri betöltéshez.

// Kérések gyorsítótárazása OkHttp-val a duplikáció megszüntetéséhez
val cache = Cache(
    File(context.cacheDir, "http_cache"),
    cacheSize = 10L * 1024 * 1024 // 10 MB
)

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

A Network Inspector korlátai és alternatívák

A széles körű lehetőségek ellenére a Network Inspector-nak vannak korlátai, amelyeket fontos figyelembe venni. Bizonyos forgatókönyvekhez — például a HTTPS elfogásához önaláírt tanúsítványokkal vagy harmadik fél könyvtárai forgalmának elemzéséhez — alternatív eszközökre lehet szükség.

Platform- és könyvtárkorlátok

A Network Inspector csak Android-alkalmazásokkal működik, és nem támogatja az iOS-t. A Kotlin Multiplatform (KMM) esetében előfordulhat, hogy egyes kérések nem jelennek meg, ha a natív részben hajtódnak végre. Egyes könyvtárak — például a gRPC, a WebSocket (nem HTTP), a GraphQL az Apollo-n keresztül (3.x verzióig) — részlegesen vagy egyáltalán nem foghatók el további elfogók konfigurálása nélkül.

Alternatív eszközök

A hálózati forgalom mélyebb elemzéséhez harmadik féltől származó megoldások léteznek: Charles Proxy (teljes proxy szerver HTTPS-elfogással), Proxyman (megfelelője macOS-re), Wireshark (csomagszintű elemzés), Stetho by Facebook (integráció a Chrome DevTools-szal), Chucker (könyvtár a kérések alkalmazáson belüli vizsgálatához). Minden eszköznek megvan a maga területe: a Charles és a Proxyman nélkülözhetetlen a szerverrel való interakció hibakeresésében a fejlesztés korai szakaszában, a Chucker pedig a tesztbuildekben történő információgyűjtéshez.