Network Inspector: qué es, principio de funcionamiento y monitoreo de solicitudes de red

¿Qué es Network Inspector?

Network Inspector es una herramienta de perfilado de la actividad de red integrada en Android Studio. Permite a los desarrolladores ver en tiempo real todas las solicitudes HTTP y HTTPS enviadas por la aplicación, incluidas las cabeceras, el cuerpo de la solicitud y de la respuesta, los códigos de estado y la duración de la ejecución. Está disponible a través del panel Android Profiler desde Android Studio 3.0.

Propósito y ámbito de aplicación

La tarea principal de Network Inspector es depurar la interacción de red de la aplicación móvil con el servidor. La herramienta se utiliza para verificar la corrección de los datos transmitidos, analizar el tiempo de respuesta, buscar errores de API y detectar patrones de red no óptimos, por ejemplo, múltiples solicitudes al cargar una sola pantalla. Network Inspector funciona en cualquier dispositivo con API Level 14.

Compatibilidad y bibliotecas

La herramienta admite todos los principales clientes HTTP de Android: OkHttp (a partir de la versión 2.x), Retrofit, Ktor (KMM), UrlConnection, Apache HttpClient (obsoleto) y WebView. Para OkHttp y Retrofit se requiere la biblioteca OkHttp Profiler, que se conecta automáticamente al usar Android Studio 4.1+. Para Ktor se necesita una configuración separada del interceptor.

Cómo funciona Network Inspector

Network Inspector intercepta las llamadas de red a nivel del sistema mediante el mecanismo Profiler Agent, que se inyecta junto con Android Profiler. Para un funcionamiento correcto se requiere una compilación de depuración de la aplicación. La herramienta no modifica el código de la aplicación ni requiere agregar dependencias para la funcionalidad básica.

Mecanismo de interceptación del tráfico

Al iniciar el perfilado, Network Inspector se conecta al proceso de depuración de la aplicación y escucha todas las llamadas HTTP que pasan a través de OkHttp Client, UrlConnection u otras bibliotecas compatibles. Cada solicitud se registra con una marca de tiempo, lo que permite construir una línea de tiempo de la actividad de red. Para HTTPS se utiliza una capa del sistema, que conserva el cifrado durante la transmisión pero permite ver el contenido decodificado dentro de Studio.

Arquitectura de recopilación de datos

La recopilación de datos se realiza a través de Profiler Service de Android Studio, que se ejecuta en un proceso separado del host. En el dispositivo se ejecuta un agente ligero que envía los metadatos de las solicitudes por el canal ADB. Esto minimiza el impacto en el rendimiento de la aplicación: la sobrecarga es inferior al 3% según los datos de Google. Los propios datos de las solicitudes (cuerpo, cabeceras) se transfieren solo cuando se visualizan los detalles activamente.

// Configuración de OkHttp para la integración con Network Inspector
val client = OkHttpClient.Builder()
    .addInterceptor(HttpLoggingInterceptor().apply {
        level = HttpLoggingInterceptor.Level.BASIC
    })
    .build()

// Network Inspector intercepta automáticamente todas las llamadas a través de client
client.newCall(Request.Builder()
    .url("https://api.example.com/data")
    .build()).execute()

Principales funciones de Network Inspector

Network Inspector ofrece un conjunto de herramientas para un análisis integral del tráfico de red. Cada función está orientada a resolver una tarea específica de depuración, desde la verificación de las cabeceras hasta el análisis del rendimiento de la API.

Línea de tiempo de solicitudes

La pantalla principal de Network Inspector muestra la cronología de todas las solicitudes en forma de línea de tiempo. Cada solicitud se representa con una franja de color: verde, una respuesta correcta (2xx); azul, una redirección (3xx); amarillo, un error de cliente (4xx); rojo, un error de servidor (5xx). La longitud de la franja corresponde al tiempo de ejecución de la solicitud desde la conexión hasta la recepción de la respuesta completa. Esto permite detectar al instante las solicitudes lentas o las que fallan con error.

Vista detallada de la solicitud

Al seleccionar una solicitud concreta se abre un panel con los detalles: Headers (todas las cabeceras de la solicitud y de la respuesta), Request Body (cuerpo de la solicitud en formato de texto o binario), Response Body (cuerpo de la respuesta con la opción de formatear JSON), Cookies (enviadas y recibidas), Timing (desglose del tiempo por fases: DNS, Connection, TLS Handshake, Request, Response).

Filtrado y búsqueda

Network Inspector admite el filtrado de solicitudes por URL, método HTTP, código de estado y tipo de contenido. Se pueden excluir las solicitudes a determinados dominios para centrarse solo en la API deseada. La búsqueda funciona en todos los campos de la solicitud, incluidos el cuerpo y las cabeceras, lo que resulta útil al depurar una función concreta de la aplicación. Los filtros combinados permiten crear un conjunto de reglas que se aplica automáticamente en cada inicio del perfilado.

Agrupación y comparación de solicitudes

La línea de tiempo admite la agrupación de solicitudes por patrones de URL. Por ejemplo, todas las solicitudes del tipo /api/v2/users/* se pueden plegar en un solo grupo. Esto simplifica el análisis cuando la aplicación realiza cientos de solicitudes en poco tiempo. La función de comparación de solicitudes adyacentes ayuda a detectar cambios en las respuestas del servidor en llamadas repetidas.

Depuración de solicitudes de red con Network Inspector

El uso práctico de Network Inspector abarca escenarios típicos de depuración: verificación del formato de los datos, detección de endpoints lentos, descubrimiento de fugas de memoria por conexiones sin cerrar y análisis del almacenamiento en caché.

Verificación de la estructura de la respuesta JSON

Una tarea frecuente es asegurarse de que el servidor devuelve los datos en el formato esperado. Network Inspector muestra el cuerpo de la respuesta con formato JSON, incluido el resaltado de sintaxis. Si la respuesta no se analiza en el cliente, en el inspector se ve al instante la causa: falta de un campo, tipo de dato incorrecto (cadena en lugar de número) o anidación excesiva. Si el servidor devuelve un error, el inspector muestra la estructura del error con el código y el mensaje. Para formatos binarios (Protocol Buffers, imágenes) se muestra el tamaño y el content-type.

Análisis del tiempo de ejecución

La pestaña Timing divide la ejecución de la solicitud en fases: DNS Resolution, TCP Connection, TLS Handshake, Request Send, Response Receive. Si el tiempo total supera 1 o 2 segundos, el desglose por fases permite determinar la causa. Por ejemplo, un DNS lento indica problemas con el resolutor, un TLS Handshake lento indica una versión obsoleta del protocolo en el servidor, y un Response lento indica código de servidor lento o una solicitud ineficiente con datos excesivos. El análisis de Timing ayuda a detectar cuellos de botella antes de comenzar la optimización de la parte del servidor.

Búsqueda de solicitudes duplicadas

Network Inspector ayuda a detectar solicitudes redundantes, por ejemplo, cuando cada rotación de pantalla hace que la Activity vuelva a crear la carga de datos. En la línea de tiempo, una serie de solicitudes idénticas consecutivas indica claramente el problema. La solución puede ser el almacenamiento en caché, el uso de ViewModel con conservación de estado o SingleLiveEvent para una carga única.

// Almacenamiento en caché de solicitudes con OkHttp para eliminar duplicaciones
val cache = Cache(
    File(context.cacheDir, "http_cache"),
    cacheSize = 10L * 1024 * 1024 // 10 MB
)

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

Limitaciones de Network Inspector y alternativas

A pesar de sus amplias capacidades, Network Inspector tiene una serie de limitaciones que es importante tener en cuenta. Para algunos escenarios, como la interceptación de HTTPS con certificados autofirmados o el análisis del tráfico de bibliotecas de terceros, pueden ser necesarias herramientas alternativas.

Limitaciones por plataformas y bibliotecas

Network Inspector solo funciona con aplicaciones Android y no admite iOS. Para Kotlin Multiplatform (KMM), parte de las solicitudes puede no mostrarse si se ejecutan en la parte nativa. Algunas bibliotecas, como gRPC, WebSocket (no HTTP) o GraphQL a través de Apollo (hasta la versión 3.x), pueden interceptarse parcialmente o no interceptarse en absoluto hasta que se configuren interceptores adicionales.

Herramientas alternativas

Para un análisis más profundo del tráfico de red existen soluciones de terceros: Charles Proxy (un proxy completo con interceptación de HTTPS), Proxyman (análogo para macOS), Wireshark (análisis a nivel de paquetes), Stetho by Facebook (integración con Chrome DevTools), Chucker (biblioteca para inspeccionar solicitudes dentro de la aplicación). Cada herramienta tiene su nicho: Charles y Proxyman son imprescindibles al depurar la interacción con el servidor en las primeras etapas del desarrollo, y Chucker para recopilar información en compilaciones de prueba.