Android Profiler : qu'est-ce que c'est, fonctionnalités CPU, Memory et Network

Qu'est-ce que l'Android Profiler ?

Android Profiler est un composant d'Android Studio qui a remplacé les anciens Android Monitor et DDMS. Il fournit une interface unifiée pour profiler tous les aspects de l'application : CPU Profiler pour l'analyse du processeur, Memory Profiler pour le travail avec la mémoire, Network Profiler pour les requêtes réseau et Energy Profiler pour la consommation d'énergie. Les données sont collectées automatiquement au lancement de l'application via Android Studio.

Le profileur fonctionne à la fois sur l'émulateur et sur un appareil physique connecté par USB. Selon Google I/O 2023, l'Android Profiler est utilisé dans plus de 70% des projets Android et est considéré comme l'outil standard de diagnostic des performances. Le principal avantage par rapport aux solutions tierces est l'intégration zéro : il n'est pas nécessaire d'ajouter des dépendances dans build.gradle ou de modifier le code de l'application.

L'architecture de l'Android Profiler est basée sur Perfetto — le traceur système d'Android qui collecte des données au niveau du noyau et de l'application. Perfetto garantit une surcharge minimale (moins de 1% de CPU) et prend en charge l'enregistrement longue durée jusqu'à 30 minutes. Cela permet de profiler non seulement les opérations rapides, mais aussi les scénarios longs — transitions entre écrans, synchronisation en arrière-plan, consommation mémoire pendant une heure d'utilisation.

Quelles données l'Android Profiler collecte-t-il ?

Le profileur collecte quatre types de données : CPU — charge de chaque cœur et thread, Memory — Java Heap, Native Heap, Stack, Graphics, Network — toutes les requêtes entrantes et sortantes, Energy — catégories de consommation d'énergie (Idle, Light, Medium, Heavy). Les données sont synchronisées sur la chronologie — vous pouvez voir simultanément comment le changement de CPU affecte la mémoire et la consommation d'énergie.

CPU Profiler : analyse du processeur et des threads

CPU Profiler affiche la charge du processeur en temps réel sur la chronologie, répartie par threads de l'application. Chaque thread est représenté par une ligne ou une zone colorée — plus la zone est large, plus le thread occupe de temps processeur. Les zones rouges signifient le travail de l'application, les bleues — les appels système, les grises — l'attente.

Pour une analyse détaillée, le CPU Profiler prend en charge trois modes d'enregistrement : Trace Java Methods (traçage de toutes les méthodes Java), Trace C/C++ Functions (traçage des fonctions natives NDK) et Sample Java Methods (échantillonnage, mode recommandé). L'échantillonnage offre la plus faible surcharge et convient au profilage quotidien, tandis que le traçage complet est utilisé pour rechercher des problèmes complexes.

// Exemple : l'analyse CPU Profiler montrera cette méthode comme goulot d'étranglement
class DataProcessor {
    suspend fun processLargeDataset(items: List<Item>): List<Result> {
        // CPU Profiler montrera une charge CPU élevée dans inBackgroundThread
        return withContext(Dispatchers.Default) {
            items.map { it.computeHeavyTransformation() }
        }
    }
}

// Recommandation après le profilage :
// computeHeavyTransformation prend 80% du temps — nous mettons en cache le résultat
class DataProcessorOptimized {
    private val cache = LruCache<String, Result>(100)

    suspend fun processLargeDataset(items: List<Item>): List<Result> {
        return withContext(Dispatchers.Default) {
            items.mapNotNull { cache.get(it.id) ?: it.computeHeavyTransformation().also { cache.put(it.id, it) } }
        }
    }
}

Après l'enregistrement, le CPU Profiler affiche l'Top-Down Tree — un arbre d'appels avec le temps d'exécution de chaque méthode. Faites attention à la colonne Self Time/Total : si le Self Time d'une méthode dépasse 16 ms et qu'elle est appelée depuis le thread UI — c'est une chute de trame garantie. La solution consiste à déplacer les calculs lourds vers un thread d'arrière-plan via Dispatchers.IO ou Default.

Modes de traçage CPU

Sample Java Methods — mode recommandé pour le profilage quotidien avec une surcharge de 3–5%. Trace Java Methods — traçage complet de chaque appel, surcharge jusqu'à 15%, utilisé pour les enregistrements courts (5–10 secondes). Trace C/C++ Functions — traçage du code NDK via Linux Perf, indispensable pour l'analyse des jeux et des bibliothèques C++. Alternez les modes selon le type de problème.

Memory Profiler : travail avec la mémoire et recherche de fuites

Memory Profiler surveille toutes les catégories de mémoire de l'application : Java Heap (objets JVM), Native Heap (allocations C/C++ via JNI), Stack (piles des threads) et Graphics (textures, tampons GPU). La visualisation principale est le graphique temporel de la consommation mémoire, où chaque catégorie est affichée dans sa propre couleur. Si le graphique ne diminue pas après le ramasse-miettes — suspectez une fuite.

Pour trouver des fuites, utilisez la fonction Capture Heap Dump. Au moment du dump, l'Android Profiler suspend l'application pendant ~100 ms et crée un fichier HPROF — un instantané complet de tous les objets vivants du Java Heap. Après avoir ouvert le dump, vous pouvez trier les objets par Retained Size (volume de mémoire libéré lors de la suppression de l'objet) et rechercher des instances d'Activity, Fragment ou Bitmap qui auraient dû être détruites.

Selon Google I/O 2022, le Memory Profiler associé à LeakCanary couvre 95% des scénarios de détection de fuites mémoire sur Android. LeakCanary fonctionne automatiquement — détecte les fuites en arrière-plan. Le Memory Profiler est nécessaire pour l'analyse manuelle : vous voyez l'image complète des allocations, pas seulement les fuites.

Comment interpréter un dump HPROF

Après avoir capturé le dump, triez les objets par Retained Size — c'est le volume de mémoire libéré lors de la suppression de l'objet. Recherchez les instances d'Activity, Fragment et Bitmap avec un grand Retained Size qui ne devraient pas être en mémoire. Allez dans l'onglet Reference Tree pour voir la chaîne de références qui maintient l'objet — il s'agit généralement d'un champ statique de singleton ou d'un callback non nettoyé. Une métrique importante est le taux d'allocation (nombre d'allocations par seconde). Si le taux d'allocation dépasse 10 000 objets/s, l'application passe trop de temps à créer et supprimer des objets temporaires, ce qui surcharge le GC et provoque des micro-freezes. Dans ce cas, utilisez l'outil View Inspector et trouvez les endroits avec une création fréquente d'objets dans les boucles.

Network Profiler : surveillance des requêtes réseau

Network Profiler affiche toutes les requêtes réseau de l'application en temps réel sur la chronologie. Chaque requête est affichée sous forme de barre horizontale — sa longueur correspond au temps d'exécution, la couleur — au type de requête (GET, POST, PUT, DELETE). Le défilement de l'échelle permet de voir comment les requêtes sont réparties dans le temps et si elles sont dupliquées.

Toutes les bibliothèques populaires sont prises en charge : OkHttp, Retrofit, Volley, Ktor. Pour Ktor et OkHttp, le profileur affiche la pile d'appels complète, y compris les intercepeurs et les convertisseurs. Pour chaque requête, les en-têtes de requête et les en-têtes de réponse, le corps de la réponse (jusqu'à 1 Mo), le code d'état et la durée sont disponibles.

Problèmes typiques identifiés par le Network Profiler : absence de cache (la même URL est demandée à chaque ouverture), requêtes dupliquées (deux composants chargent les mêmes données simultanément), taille excessive de la réponse (le serveur envoie 5 Mo quand 50 Ko sont nécessaires). Le Network Profiler permet de voir ces problèmes littéralement d'un coup d'œil sur la chronologie.

Pour simuler des réseaux lents, utilisez le Network Conditioning dans Android Studio — il permet de limiter la bande passante à 3G/2G et d'ajouter de la latence. Ceci est particulièrement important pour tester le comportement de l'application dans de mauvaises conditions réseau, surtout pour les applications opérant dans des régions à internet instable.

Energy Profiler : analyse de la consommation d'énergie

Energy Profiler évalue l'impact de l'application sur la batterie sur la base des données Perfetto. L'outil ne mesure pas la consommation réelle en milliampères, mais classe chaque opération dans l'une des cinq catégories de consommation d'énergie : Idle, Light, Medium, High et Overloaded. La chronologie de l'Energy Profiler est colorée : vert (charge légère), jaune (moyenne), rouge (élevée).

Principales causes des zones rouges : WakeLock (l'application maintient le processeur actif), Localisation GPS (demandes constantes de coordonnées avec une haute précision), connexions Keep-Alive (échanges fréquents de données avec le serveur), grands transferts de données (envoi de fichiers, streaming). L'Energy Profiler montre exactement quelle opération à quel moment a causé le pic de consommation d'énergie.

Selon Android Developers, une application typique ne devrait pas passer plus de 5% de son temps dans la catégorie High. Si l'Energy Profiler affiche des zones rouges pendant plus de 10% du temps de profilage — l'application ne passera pas la revue selon le critère d'épuisement de la batterie. Recommandation — utilisez WorkManager pour les tâches d'arrière-plan, limitez les demandes de localisation à la précision minimale nécessaire et regroupez les requêtes réseau par lots.

Comment utiliser l'Android Profiler : guide pratique

Lancez l'Android Profiler en un clic : dans Android Studio, ouvrez View → Tool Windows → Profiler ou double-cliquez sur l'icône Profiler dans le panneau droit. Après avoir lancé l'application sur l'appareil connecté, Android Studio se connectera automatiquement au processus et commencera la collecte de données. Sur la chronologie, les graphiques de CPU, Memory, Network et Energy apparaîtront immédiatement.

Pour une analyse détaillée, sélectionnez l'onglet souhaité (CPU, Memory, Network ou Energy) et commencez l'enregistrement. Pour le CPU, je recommande le mode Sample Java Methods avec une durée d'enregistrement de 30 secondes — c'est suffisant pour un scénario typique. Pour la mémoire — un dump du tas après l'exécution du scénario (Capture Heap Dump). Pour le réseau, l'enregistrement démarre automatiquement, il suffit d'appuyer sur le bouton Stop après avoir terminé le scénario.

Après avoir arrêté l'enregistrement, exportez les données : File → Save As enregistre toute la session dans un fichier .perf. C'est pratique pour comparer les métriques avant et après l'optimisation. Créez une session de référence sur la première version stable et comparez chaque nouvelle session avec elle — c'est la seule façon d'évaluer objectivement les changements de performance.

Automatisation du profilage dans le CI

L'Android Profiler peut être exécuté depuis la ligne de commande via Android Studio CLI et Firebase Test Lab. Firebase Test Lab prend en charge le profilage des performances dans le cadre des tests d'interface utilisateur : vous obtenez les métriques CPU, Memory et Network avec le résultat du test. Configurez le pipeline pour qu'en cas de baisse des métriques de 10% par rapport à la référence, le pipeline CI soit bloqué jusqu'à vérification par le développeur.