Network Inspector — ano ito, prinsipyo ng paggana at pagsubaybay ng mga kahilingan sa network

Ano ang Network Inspector?

Network Inspector ay isang profiling tool para sa network activity na naka-embed sa Android Studio. Pinapayagan nito ang mga developer na tingnan sa real-time ang lahat ng HTTP at HTTPS request na ipinapadala ng app, kabilang ang mga header, body ng request at tugon, status code, at tagal ng pagpapatupad. Magagamit sa pamamagitan ng Android Profiler panel mula sa Android Studio 3.0.

Layunin at sakop ng aplikasyon

Ang pangunahing gawain ng Network Inspector ay pag-debug ng network interaction ng mobile app sa server. Ang tool ay ginagamit para sa pagsuri ng kawastuhan ng ipinadalang data, pagsusuri ng oras ng tugon, paghahanap ng mga error sa API, pati na rin para sa pagtuklas ng mga hindi optimal na pattern ng network — halimbawa, maraming request kapag naglo-load ng isang screen. Gumagana ang Network Inspector sa anumang device na may API Level 14.

Pagkatugma at mga library

Sinusuportahan ng tool ang lahat ng pangunahing Android HTTP client: OkHttp (mula sa bersyon 2.x), Retrofit, Ktor (KMM), UrlConnection, Apache HttpClient (luma na) at WebView. Para sa OkHttp at Retrofit kailangan ang OkHttp Profiler library — awtomatikong idinaragdag kapag gumagamit ng Android Studio 4.1+. Para sa Ktor kailangan ng hiwalay na configuration ng interceptor.

Paano gumagana ang Network Inspector

Hinaharang ng Network Inspector ang mga tawag sa network sa antas ng system gamit ang mekanismo ng Profiler Agent, na ini-inject kasama ng Android Profiler. Para sa tamang paggana, kinakailangan ang debug build ng app. Hindi binabago ng tool ang code ng app at hindi nangangailangan ng pagdaragdag ng mga dependency para sa pangunahing functionality.

Mekanismo ng pagharang ng trapiko

Kapag nagsimula ang profiling, kumokonekta ang Network Inspector sa Debug process ng app at nakikinig sa lahat ng HTTP tawag na dumadaan sa OkHttp Client, UrlConnection o iba pang suportadong library. Ang bawat request ay nai-record na may timestamp, na nagpapahintulot na bumuo ng timeline ng network activity. Para sa HTTPS, ginagamit ang system intermediary layer na nagpapanatili ng encryption sa panahon ng transmission, ngunit pinapayagan na tingnan ang decoded na nilalaman sa loob ng Studio.

Arkitektura ng pangongolekta ng data

Ang pangongolekta ng data ay nangyayari sa pamamagitan ng Profiler Service ng Android Studio, na tumatakbo sa isang hiwalay na proseso ng host. Sa device, tumatakbo ang isang light agent na nagpapadala ng metadata ng request sa pamamagitan ng ADB channel. Ito ay nagmi-minimize ng epekto sa performance ng app — ang overhead ay mas mababa sa 3% ayon sa data ng Google. Ang aktwal na data ng request (body, headers) ay ipinapadala lamang sa panahon ng aktibong pagtingin ng mga detalye.

// Pagkonekta ng OkHttp para sa pagsasama sa Network Inspector
val client = OkHttpClient.Builder()
    .addInterceptor(HttpLoggingInterceptor().apply {
        level = HttpLoggingInterceptor.Level.BASIC
    })
    .build()

// Awtomatikong hinaharang ng Network Inspector ang lahat ng tawag sa pamamagitan ng client
client.newCall(Request.Builder()
    .url("https://api.example.com/data")
    .build()).execute()

Mga pangunahing kakayahan ng Network Inspector

Nagbibigay ang Network Inspector ng isang set ng mga tool para sa komprehensibong pagsusuri ng network traffic. Ang bawat function ay nakatuon sa paglutas ng isang partikular na debug task — mula sa pagsuri ng mga header hanggang sa pagsusuri ng performance ng API.

Timeline ng mga request

Ang pangunahing screen ng Network Inspector ay nagpapakita ng kronolohiya ng lahat ng request sa anyo ng timeline. Ang bawat request ay kinakatawan ng may kulay na bar: berde — matagumpay na tugon (2xx), asul — pag-redirect (3xx), dilaw — error ng client (4xx), pula — error ng server (5xx). Ang haba ng bar ay tumutugma sa oras ng pagpapatupad ng request mula sa koneksyon hanggang sa pagtanggap ng buong tugon. Ito ay nagpapahintulot ng agarang pagtuklas ng mabagal o may error na mga request.

Detalyadong pagtingin ng request

Kapag pumili ng isang partikular na request, magbubukas ang isang panel na may mga detalye: Headers(lahat ng header ng request at tugon), Request Body(body ng request sa text o binary format), Response Body(body ng tugon na may kakayahang mag-format ng JSON), Cookies(ipinadala at natanggap), Timing(paghahati ng oras ayon sa yugto: DNS, Connection, TLS Handshake, Request, Response).

Pag-filter at paghahanap

Sinusuportahan ng Network Inspector ang pag-filter ng mga request ayon sa URL, HTTP method, status code, at uri ng nilalaman. Maaaring ibukod ang mga request sa partikular na domain upang tumuon lamang sa kinakailangang API. Gumagana ang paghahanap sa lahat ng field ng request, kabilang ang body at headers, na maginhawa kapag nagde-debug ng isang partikular na function ng app. Ang pinagsamang mga filter ay nagpapahintulot na lumikha ng isang set ng mga panuntunan na awtomatikong inilalapat sa bawat pagsisimula ng profiling.

Pag-grupo at paghahambing ng mga request

Sinusuportahan ng timeline ang pag-grupo ng mga request ayon sa URL pattern. Halimbawa, lahat ng request na may anyong /api/v2/users/* ay maaaring pagsama-samahin sa isang grupo. Pinapasimple nito ang pagsusuri kapag ang app ay gumagawa ng daan-daang request sa maikling panahon. Ang function ng paghahambing ng magkatabing request ay tumutulong na matukoy ang mga pagbabago sa mga tugon ng server sa paulit-ulit na tawag.

Pag-debug ng mga network request gamit ang Network Inspector

Sinasaklaw ng praktikal na paggamit ng Network Inspector ang mga tipikal na debug scenario: pagsuri ng format ng data, pagtuklas ng mabagal na endpoint, paghahanap ng memory leak dahil sa hindi saradong koneksyon, at pagsusuri ng caching.

Pagsuri ng istraktura ng JSON response

Isang karaniwang gawain — tiyakin na ang server ay nagbabalik ng data sa inaasahang format. Ipinapakita ng Network Inspector ang body ng tugon na may JSON formatting, kabilang ang syntax highlighting. Kung ang tugon ay hindi na-parse sa client, sa inspector ay makikita agad ang dahilan: nawawalang field, maling uri ng data (string sa halip na numero), o labis na nesting. Kung ang server ay nagbabalik ng error, ipinapakita ng inspector ang istraktura ng error na may code at mensahe. Para sa binary format (Protocol Buffers, mga larawan), ipinapakita ang laki at content-type.

Pagsusuri ng oras ng pagpapatupad

Ang tab na Timing ay hinahati ang pagpapatupad ng request sa mga yugto: DNS Resolution, TCP Connection, TLS Handshake, Request Send, Response Receive. Kung ang kabuuang oras ay lumampas sa 1-2 segundo, batay sa paghahati ng yugto ay matutukoy ang dahilan. Halimbawa, ang mahabang DNS ay nagpapahiwatig ng problema sa resolver, mahabang TLS Handshake — lumang bersyon ng protocol sa server, mahabang Response — mabagal na server code o hindi epektibong request na may labis na data. Ang pagsusuri ng Timing ay tumutulong na matukoy ang mga bottleneck bago pa man magsimula ang pag-optimize ng bahagi ng server.

Paghahanap ng mga duplicate na request

Tumutulong ang Network Inspector na matukoy ang mga redundante na request — halimbawa, kapag sa bawat pag-ikot ng screen ay muling nilo-load ng Activity ang data. Sa timeline, ang serye ng magkakasunod na magkaparehong request ay malinaw na nagpapahiwatig ng problema. Ang solusyon ay maaaring caching, paggamit ng ViewModel na may pagpapanatili ng estado, o SingleLiveEvent para sa isang beses na pag-load.

// Pag-cache ng mga request gamit ang OkHttp para alisin ang pagdodoble
val cache = Cache(
    File(context.cacheDir, "http_cache"),
    cacheSize = 10L * 1024 * 1024 // 10 MB
)

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

Mga limitasyon ng Network Inspector at mga alternatibo

Sa kabila ng malawak na kakayahan, ang Network Inspector ay may ilang mga limitasyon na mahalagang isaalang-alang. Para sa ilang scenario — tulad ng pagharang ng HTTPS na may self-signed na certificate o pagsusuri ng trapiko ng third-party library — maaaring kailanganin ang mga alternatibong tool.

Mga limitasyon sa platform at library

Ang Network Inspector ay gumagana lamang sa mga Android app at hindi sumusuporta sa iOS. Para sa Kotlin Multiplatform (KMM) ang ilang request ay maaaring hindi maipakita kung isinasagawa sa native na bahagi. Ang ilang library — halimbawa, gRPC, WebSocket (hindi HTTP), GraphQL sa pamamagitan ng Apollo (hanggang bersyon 3.x) — ay maaaring maharang nang bahagya o hindi talaga kung walang configuration ng karagdagang interceptor.

Mga alternatibong tool

Para sa mas malalim na pagsusuri ng network traffic, mayroong mga third-party na solusyon: Charles Proxy (ganap na proxy server na may HTTPS interception), Proxyman (katumbas para sa macOS), Wireshark (pagsusuri sa antas ng packet), Stetho by Facebook (pagsasama sa Chrome DevTools), Chucker (library para sa inspeksyon ng request sa loob ng app). Ang bawat tool ay may kanya-kanyang niche: Charles at Proxyman ay kailangang-kailangan sa pag-debug ng interaction sa server sa mga unang yugto ng development, at Chucker — para sa pangongolekta ng impormasyon sa test build.