Network Inspector — какво е, принцип на работа и мониторинг на мрежови заявки

Какво е Network Inspector?

Network Inspector е инструмент за профилиране на мрежова активност, вграден в Android Studio. Той позволява на разработчиците да преглеждат в реално време всички HTTP и HTTPS заявки, изпращани от приложението, включително хедъри, тяло на заявката и отговора, статус кодове и време за изпълнение. Достъпен е чрез панела Android Profiler от Android Studio 3.0.

Предназначение и обхват на приложение

Основната задача на Network Inspector е дебъгване на мрежовото взаимодействие на мобилното приложение със сървъра. Инструментът се използва за проверка на коректността на предаваните данни, анализ на времето за отговор, търсене на API грешки, както и за откриване на неоптимални мрежови модели — например множество заявки при зареждане на един екран. Network Inspector работи на всяко устройство с API Level 14.

Съвместимост и библиотеки

Инструментът поддържа всички основни Android HTTP клиенти: OkHttp (от версия 2.x), Retrofit, Ktor (KMM), UrlConnection, Apache HttpClient (остарял) и WebView. За OkHttp и Retrofit е необходима библиотеката OkHttp Profiler — добавя се автоматично при използване на Android Studio 4.1+. За Ktor е необходима отделна конфигурация на прихващач.

Как работи Network Inspector

Network Inspector прихваща мрежови повиквания на системно ниво, използвайки механизма Profiler Agent, който се инжектира заедно с Android Profiler. За коректна работа е необходима debug версия на приложението. Инструментът не променя кода на приложението и не изисква добавяне на зависимости за основната функционалност.

Механизъм за прихващане на трафик

При стартиране на профилиране, Network Inspector се свързва с Debug процеса на приложението и слуша всички HTTP повиквания, преминаващи през OkHttp Client, UrlConnection или други поддържани библиотеки. Всяка заявка се записва с времеви печат, което позволява изграждане на времева линия на мрежовата активност. За HTTPS се използва системен междинен слой, който запазва криптирането по време на предаване, но позволява преглед на декодираното съдържание в Studio.

Архитектура на събиране на данни

Събирането на данни става чрез Profiler Service на Android Studio, която работи в отделен процес на хоста. На устройството работи лек агент, който предава метаданните на заявките по ADB канал. Това минимизира влиянието върху производителността на приложението — допълнителното натоварване е под 3% според данни на Google. Самите данни на заявките (тяло, хедъри) се предават само при активно преглеждане на детайлите.

// Свързване на OkHttp за интеграция с Network Inspector
val client = OkHttpClient.Builder()
    .addInterceptor(HttpLoggingInterceptor().apply {
        level = HttpLoggingInterceptor.Level.BASIC
    })
    .build()

// Network Inspector автоматично прихваща всички повиквания чрез client
client.newCall(Request.Builder()
    .url("https://api.example.com/data")
    .build()).execute()

Основни възможности на Network Inspector

Network Inspector предоставя набор от инструменти за цялостен анализ на мрежовия трафик. Всяка функция е насочена към решаване на конкретна задача за дебъгване — от проверка на хедъри до анализ на производителност на API.

Времева линия на заявките

Основният екран на Network Inspector показва хронологията на всички заявки под формата на времева линия. Всяка заявка е представена с цветна лента: зелено — успешен отговор (2xx), синьо — пренасочване (3xx), жълто — клиентска грешка (4xx), червено — сървърна грешка (5xx). Дължината на лентата съответства на времето за изпълнение на заявката от свързване до получаване на пълния отговор. Това позволява незабавно откриване на бавни или заявки с грешка.

Детайлен преглед на заявка

При избор на конкретна заявка се отваря панел с детайли: Headers (всички хедъри на заявката и отговора), Request Body (тяло на заявката в текстов или двоичен формат), Response Body (тяло на отговора с възможност за форматиране на JSON), Cookies (изпратени и получени), Timing (разделение на времето по фази: DNS, Connection, TLS Handshake, Request, Response).

Филтриране и търсене

Network Inspector поддържа филтриране на заявки по URL, HTTP метод, статус код и тип на съдържанието. Могат да се изключат заявки към определени домейни, за да се фокусирате само върху необходимото API. Търсенето работи във всички полета на заявката, включително тяло и хедъри, което е удобно при дебъгване на конкретна функция на приложението. Комбинираните филтри позволяват създаване на набор от правила, които се прилагат автоматично при всяко стартиране на профилиране.

Групиране и сравняване на заявки

Времевата линия поддържа групиране на заявки по URL модели. Например, всички заявки от вида /api/v2/users/* могат да бъдат свити в една група. Това опростява анализа, когато приложението прави стотици заявки за кратко време. Функцията за сравняване на съседни заявки помага за откриване на промени в отговорите на сървъра при повторни повиквания.

Дебъгване на мрежови заявки с Network Inspector

Практическото използване на Network Inspector обхваща типични сценарии за дебъгване: проверка на формата на данните, откриване на бавни крайни точки, намиране на изтичане на памет поради незатворени връзки и анализ на кеширане.

Проверка на структурата на JSON отговор

Честа задача — да се уверите, че сървърът връща данни в очаквания формат. Network Inspector показва тялото на отговора с JSON форматиране, включително подчертаване на синтаксиса. Ако отговорът не се парсва от клиента, в инспектора веднага се вижда причината: липсващо поле, грешен тип данни (низ вместо число) или прекомерно влагане. Ако сървърът връща грешка, инспекторът показва структурата на грешката с код и съобщение. За двоични формати (Protocol Buffers, изображения) се показва размер и content-type.

Анализ на времето за изпълнение

Разделът Timing разделя изпълнението на заявката на фази: DNS Resolution, TCP Connection, TLS Handshake, Request Send, Response Receive. Ако общото време надвишава 1–2 секунди, на базата на фазовото разделение може да се определи причината. Например, дълъг DNS показва проблеми с резолвера, дълъг TLS Handshake — остаряла версия на протокола на сървъра, дълъг Response — бавен сървърен код или неефективна заявка с излишни данни. Анализът Timing помага да се идентифицират тесните места още преди започване на оптимизацията на сървърната част.

Търсене на дублиращи се заявки

Network Inspector помага за откриване на излишни заявки — например, когато при всяко завъртане на екрана Activity презарежда данни. На времевата линия поредица от идентични заявки една след друга ясно показва проблема. Решението може да бъде кеширане, използване на ViewModel със запазване на състоянието или SingleLiveEvent за еднократно зареждане.

// Кеширане на заявки с OkHttp за премахване на дублиране
val cache = Cache(
    File(context.cacheDir, "http_cache"),
    cacheSize = 10L * 1024 * 1024 // 10 MB
)

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

Ограничения на Network Inspector и алтернативи

Въпреки широките възможности, Network Inspector има редица ограничения, които е важно да се вземат предвид. За някои сценарии — като прихващане на HTTPS със самоподписани сертификати или анализ на трафик от библиотеки на трети страни — може да са необходими алтернативни инструменти.

Ограничения на платформата и библиотеките

Network Inspector работи само с Android приложения и не поддържа iOS. За Kotlin Multiplatform (KMM) някои заявки може да не се показват, ако се изпълняват в native частта. Някои библиотеки — например gRPC, WebSocket (не HTTP), GraphQL чрез Apollo (до версия 3.x) — могат да бъдат прихващани частично или изобщо да не бъдат прихващани без конфигуриране на допълнителни прихващачи.

Алтернативни инструменти

За по-задълбочен анализ на мрежовия трафик съществуват решения на трети страни: Charles Proxy (пълнофункционален прокси сървър с прихващане на HTTPS), Proxyman (аналог за macOS), Wireshark (анализ на пакетно ниво), Stetho by Facebook (интеграция с Chrome DevTools), Chucker (библиотека за инспекция на заявки вътре в приложението). Всеки инструмент има своя ниша: Charles и Proxyman са незаменими при дебъгване на взаимодействието със сървъра в ранните етапи на разработка, а Chucker — за събиране на информация в тестови версии.