Network Inspector : ce que c'est, principe de fonctionnement et surveillance des requêtes réseau

Qu'est-ce que Network Inspector ?

Network Inspector est un outil de profilage de l'activité réseau intégré à Android Studio. Il permet aux développeurs de visualiser en temps réel toutes les requêtes HTTP et HTTPS envoyées par l'application, y compris les en-têtes, le corps de la requête et de la réponse, les codes de statut et la durée d'exécution. Disponible via le panneau Android Profiler à partir d'Android Studio 3.0.

Objectif et domaine d'application

La tâche principale de Network Inspector est le débogage de l'interaction réseau entre l'application mobile et le serveur. L'outil est utilisé pour vérifier l'exactitude des données transmises, analyser le temps de réponse, rechercher les erreurs d'API et détecter les schémas réseau non optimaux, par exemple les requêtes multiples lors du chargement d'un seul écran. Network Inspector fonctionne sur n'importe quel appareil avec l'API Level 14.

Compatibilité et bibliothèques

L'outil prend en charge tous les principaux clients HTTP Android : OkHttp (à partir de la version 2.x), Retrofit, Ktor (KMM), UrlConnection, Apache HttpClient (obsolète) et WebView. Pour OkHttp et Retrofit, la bibliothèque OkHttp Profiler est requise ; elle se connecte automatiquement lors de l'utilisation d'Android Studio 4.1+. Pour Ktor, une configuration distincte de l'intercepteur est nécessaire.

Comment fonctionne Network Inspector

Network Inspector intercepte les appels réseau au niveau du système en utilisant le mécanisme Profiler Agent, injecté avec Android Profiler. Un build de débogage de l'application est requis pour un fonctionnement correct. L'outil ne modifie pas le code de l'application et ne nécessite pas l'ajout de dépendances pour les fonctionnalités de base.

Mécanisme d'interception du trafic

Au lancement du profilage, Network Inspector se connecte au processus de débogage de l'application et écoute tous les appels HTTP passant par OkHttp Client, UrlConnection ou d'autres bibliothèques prises en charge. Chaque requête est enregistrée avec un horodatage, ce qui permet de construire une chronologie de l'activité réseau. Pour HTTPS, une couche système est utilisée, qui préserve le chiffrement lors de la transmission tout en permettant d'afficher le contenu décodé dans Studio.

Architecture de collecte des données

La collecte des données s'effectue via le Profiler Service d'Android Studio, qui fonctionne dans un processus hôte distinct. Sur l'appareil, un agent léger transmet les métadonnées des requêtes via le canal ADB. Cela minimise l'impact sur les performances de l'application : la surcharge est inférieure à 3 % selon Google. Les données des requêtes elles-mêmes (corps, en-têtes) ne sont transmises que lors de l'affichage actif des détails.

// Configuration d'OkHttp pour l'intégration avec Network Inspector
val client = OkHttpClient.Builder()
    .addInterceptor(HttpLoggingInterceptor().apply {
        level = HttpLoggingInterceptor.Level.BASIC
    })
    .build()

// Network Inspector intercepte automatiquement tous les appels via client
client.newCall(Request.Builder()
    .url("https://api.example.com/data")
    .build()).execute()

Principales fonctionnalités de Network Inspector

Network Inspector fournit un ensemble d'outils pour une analyse complète du trafic réseau. Chaque fonction vise à résoudre une tâche de débogage spécifique, de la vérification des en-têtes à l'analyse des performances de l'API.

Chronologie des requêtes

L'écran principal de Network Inspector affiche la chronologie de toutes les requêtes sous forme de ligne de temps. Chaque requête est représentée par une barre colorée : vert – réponse réussie (2xx), bleu – redirection (3xx), jaune – erreur client (4xx), rouge – erreur serveur (5xx). La longueur de la barre correspond au temps d'exécution de la requête, de la connexion à la réception de la réponse complète. Cela permet d'identifier instantanément les requêtes lentes ou celles qui ont échoué avec une erreur.

Affichage détaillé de la requête

Lors de la sélection d'une requête spécifique, un panneau s'ouvre avec les détails : Headers (tous les en-têtes de la requête et de la réponse), Request Body (corps de la requête au format texte ou binaire), Response Body (corps de la réponse avec option de formatage JSON), Cookies (envoyés et reçus), Timing (répartition du temps par phases : DNS, Connection, TLS Handshake, Request, Response).

Filtrage et recherche

Network Inspector prend en charge le filtrage des requêtes par URL, méthode HTTP, code de statut et type de contenu. Il est possible d'exclure les requêtes vers certains domaines pour se concentrer uniquement sur l'API souhaitée. La recherche fonctionne sur tous les champs de la requête, y compris le corps et les en-têtes, ce qui est pratique lors du débogage d'une fonction spécifique de l'application. Les filtres combinés permettent de créer un ensemble de règles appliquées automatiquement à chaque lancement du profilage.

Regroupement et comparaison des requêtes

La chronologie prend en charge le regroupement des requêtes par modèles d'URL. Par exemple, toutes les requêtes du type /api/v2/users/* peuvent être réduites en un seul groupe. Cela simplifie l'analyse lorsque l'application effectue des centaines de requêtes en peu de temps. La fonction de comparaison des requêtes adjacentes permet de détecter les changements dans les réponses du serveur lors d'appels répétés.

Débogage des requêtes réseau avec Network Inspector

L'utilisation pratique de Network Inspector couvre les scénarios de débogage typiques : vérification du format des données, détection des points de terminaison lents, découverte de fuites de mémoire dues à des connexions non fermées et analyse de la mise en cache.

Vérification de la structure de la réponse JSON

Une tâche courante consiste à s'assurer que le serveur renvoie les données au format attendu. Network Inspector affiche le corps de la réponse avec un formatage JSON, y compris la coloration syntaxique. Si la réponse ne peut pas être analysée côté client, la cause est immédiatement visible dans l'inspecteur : champ manquant, type de données incorrect (chaîne au lieu d'un nombre) ou imbrication excessive. Si le serveur renvoie une erreur, l'inspecteur affiche la structure de l'erreur avec le code et le message. Pour les formats binaires (Protocol Buffers, images), la taille et le content-type sont affichés.

Analyse du temps d'exécution

L'onglet Timing décompose l'exécution de la requête en phases : DNS Resolution, TCP Connection, TLS Handshake, Request Send, Response Receive. Si le temps total dépasse 1 à 2 secondes, la répartition par phases permet d'en déterminer la cause. Par exemple, un DNS lent indique des problèmes de résolveur, un TLS Handshake lent indique une version obsolète du protocole sur le serveur et un Response lent indique un code serveur lent ou une requête inefficace avec des données excessives. L'analyse Timing permet d'identifier les goulots d'étranglement avant même de commencer l'optimisation côté serveur.

Recherche de requêtes en double

Network Inspector aide à détecter les requêtes redondantes, par exemple lorsque l'Activity recrée le chargement des données à chaque rotation de l'écran. Dans la chronologie, une série de requêtes identiques successives indique clairement le problème. La solution peut être la mise en cache, l'utilisation d'un ViewModel avec conservation de l'état ou SingleLiveEvent pour un chargement unique.

// Mise en cache des requêtes avec OkHttp pour éliminer les doublons
val cache = Cache(
    File(context.cacheDir, "http_cache"),
    cacheSize = 10L * 1024 * 1024 // 10 MB
)

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

Limites de Network Inspector et alternatives

Malgré ses nombreuses fonctionnalités, Network Inspector présente certaines limites qu'il est important de prendre en compte. Pour certains scénarios, tels que l'interception de HTTPS avec des certificats auto-signés ou l'analyse du trafic de bibliothèques tierces, des outils alternatifs peuvent être nécessaires.

Limites concernant les plateformes et les bibliothèques

Network Inspector ne fonctionne qu'avec les applications Android et ne prend pas en charge iOS. Pour Kotlin Multiplatform (KMM), une partie des requêtes peut ne pas s'afficher si elles sont exécutées dans la partie native. Certaines bibliothèques, par exemple gRPC, WebSocket (non-HTTP), GraphQL via Apollo (jusqu'à la version 3.x), peuvent être interceptées partiellement ou pas du tout tant que des intercepteurs supplémentaires ne sont pas configurés.

Outils alternatifs

Pour une analyse plus approfondie du trafic réseau, il existe des solutions tierces : Charles Proxy (serveur proxy complet avec interception HTTPS), Proxyman (équivalent pour macOS), Wireshark (analyse au niveau des paquets), Stetho by Facebook (intégration avec Chrome DevTools), Chucker (bibliothèque pour l'inspection des requêtes au sein de l'application). Chaque outil a sa niche : Charles et Proxyman sont indispensables lors du débogage de l'interaction avec le serveur aux premiers stades du développement, et Chucker pour la collecte d'informations dans les builds de test.