Traceview : ce que c’est, outil de traçage et de profilage Android

Qu’est-ce que Traceview dans Android

Traceview est un profileur graphique intégré à Android Studio qui affiche les traces d’exécution des méthodes d’applications Android sous forme de chronologie et de tableau d’appels. Il fait partie du SDK Android et est disponible via Android Profiler à partir d’Android Studio 3.0, ainsi que via l’utilitaire de ligne de commande dmtracedump.

Objectif de l’outil

La tâche principale de Traceview est d’aider les développeurs à trouver les méthodes qui consomment le plus de temps CPU. Contrairement à la journalisation simple, Traceview enregistre l’heure exacte d’entrée et de sortie de chaque méthode, construit un Call Chart et un arbre Top-Down, permettant une détection visuelle des anomalies de performance. L’outil est particulièrement utile lors du profilage du thread UI, où un retard de 16 ms entraîne une perte d’image.

Histoire et évolution

Traceview est apparu pour la première fois dans les premières versions du SDK Android en tant qu’utilitaire autonome pour visualiser les fichiers .trace. Avec la sortie d’Android Studio 3.0 (2017), il est devenu partie intégrante d’Android Profiler, gagnant une intégration avec les chronologies en direct du CPU, de la mémoire et du réseau. Selon Google I/O 2018, l’équipe d’Android Studio continue de développer le profileur, ajoutant la prise en charge du code natif via systrace et perfetto. Dans les versions actuelles d’Android Studio, Traceview fonctionne sur le format Perfetto mais conserve la compatibilité ascendante avec le format .trace classique.

Comment fonctionne Traceview

Traceview reçoit les données du mécanisme System Tracing dans Android Runtime (ART). Lorsqu’une application est lancée avec le traçage activé, ART enregistre les horodatages de début et de fin de chaque méthode exécutée, y compris le nom de la classe, le nom de la méthode et l’ID du thread.

// Lancement de la trace dans le code de l'application
Debug.startMethodTracing("app_trace")

// Section critique du code à profiler
loadHeavyData()

// Arrêt de la trace — le fichier est enregistré sur l'appareil
Debug.stopMethodTracing()

System Tracing fonctionne au niveau de la machine virtuelle ART et enregistre chaque appel de méthode avec une précision de l’ordre de la microseconde. Les données sont écrites dans un tampon circulaire pour minimiser l’impact sur les performances de l’application. Après l’arrêt du traçage, le tampon est vidé dans un fichier .trace sur le stockage interne de l’appareil.

Format du fichier .trace

Un fichier .trace contient un en-tête avec la version du format et l’heure de début, suivi d’enregistrements pour chaque appel : ID du thread, ID de la méthode, horodatage d’entrée et horodatage de sortie. Android Studio charge automatiquement le fichier .trace et crée deux vues principales : le panneau Chronologie pour la chronologie et le panneau Profil pour la hiérarchie des appels. Par défaut, la taille maximale du tampon est de 8 Mo, mais elle peut être augmentée via Debug.startMethodTracing(filename, maxSize).

Fonctionnalités clés de Traceview

Traceview propose plusieurs vues de données complémentaires, chacune répondant à une tâche spécifique dans l’analyse des performances.

Call Chart (graphique d’appels)

Call Chart est une chronologie horizontale où chaque thread est affiché sous forme de voie séparée. Les méthodes sont représentées par des rectangles colorés : la largeur du rectangle est proportionnelle au temps d’exécution et l’imbrication reflète la hiérarchie des appels. Si une méthode appelle une autre méthode, le rectangle enfant est dessiné à l’intérieur du rectangle parent. Cette visualisation permet d’identifier instantanément les opérations qui ont bloqué le thread.

Arbres Top-Down et Bottom-Up

L’arbre Top-Down affiche le temps d’exécution d’une méthode incluant tous ses appels imbriqués — Inclusive Time. L’arbre Bottom-Up, quant à lui, montre quelles méthodes parentes ont appelé une méthode donnée — utile pour trouver la source d’une opération lourde. La différence entre Inclusive et Exclusive Time est cruciale : une méthode peut s’exécuter rapidement mais appeler une méthode enfant lente, et cela n’est visible que dans le Inclusive Time.

Recherche et filtrage

Traceview prend en charge la recherche par nom de méthode, paquet ou classe. Les résultats sont mis en évidence sur la chronologie et le panneau Profil affiche les statistiques uniquement pour les méthodes trouvées. Le filtrage par threads est également disponible — vous pouvez masquer les threads d’arrière-plan et vous concentrer sur le thread principal (UI), où les retards sont les plus critiques.

Exportation des données

Traceview permet d’exporter les traces au format CSV pour une analyse plus poussée dans des tableurs ou des graphiques. Dans Android Studio, vous pouvez également copier un fragment sélectionné de la chronologie sous forme d’image — pour l’insérer dans des rapports de bogues ou de la documentation. Pour le CI/CD, l’export au format Perfetto est disponible via l’utilitaire cmdline-tools.

Comment utiliser Traceview dans Android Studio

Le profilage via Traceview est disponible de deux manières : via Android Profiler avec capture en direct et via des appels programmatiques à l’API Debug. La première méthode est pratique pour l’analyse ad-hoc, la seconde pour des tests de performance reproductibles.

Capture via Android Profiler

Dans Android Studio, ouvrez l’onglet Profiler (View → Tool Windows → Profiler), sélectionnez votre appareil et le processus de l’application. Cliquez sur le segment CPU, puis sélectionnez le mode « Trace Java Methods » et cliquez sur Record. Après avoir interagi avec l’application, cliquez sur Stop — Traceview ouvrira automatiquement la trace enregistrée. La durée d’enregistrement par défaut est limitée à 30 secondes, mais la limite peut être modifiée dans les paramètres du profileur.

Démarrage programmatique du traçage

Pour un profilage précis d’une section de code spécifique, utilisez Debug.startMethodTracing et Debug.stopMethodTracing. Le fichier est enregistré dans le stockage externe de l’application au chemin retourné par context.getExternalFilesDir(null). Après la fin, transférez le fichier .trace vers votre ordinateur via Android Studio Device Explorer, puis ouvrez-le via File → Open dans Android Studio.

Debug.startMethodTracing(
    "heavy_computation",
    Debug.TRACE_COUNT_ALLOCS
)

processLargeDataset()

Debug.stopMethodTracing()

Configuration des paramètres de traçage

Debug.startMethodTracing prend trois paramètres : le nom du fichier (sans extension), la taille maximale du tampon (par défaut 8 Mo) et des indicateurs. L’indicateur TRACE_COUNT_ALLOCS ajoute le comptage des allocations d’objets — utile pour trouver les fuites de mémoire. Traceview n’est pas adapté au profilage de code natif — utilisez SimplePerf ou Perfetto. Pour les tests longs (plus de 30 secondes), il est recommandé d’augmenter le tampon à 64–128 Mo via le paramètre maxSize.

Lecture de la chronologie Traceview

La chronologie Traceview se compose de deux panneaux : le panneau Chronologie supérieur avec des rectangles d’appels colorés et le panneau Profil inférieur avec un tableau de statistiques. Le panneau Chronologie montre l’exécution des threads de gauche à droite, où chaque rectangle est un seul appel de méthode. Les couleurs des rectangles sont codées par type de méthode : appels système Android (vert), méthodes d’application (bleu), appels de bibliothèques (orange).

Comment lire le panneau Profil

Dans le panneau Profil, chaque ligne est une méthode avec des colonnes pour Inclusive Time, Exclusive Time, Calls + Recur et CPU Time. Triez le tableau par Inclusive Time (décroissant) pour voir d’abord les méthodes qui ont pris le plus de temps total. Si une méthode avec un Inclusive Time élevé a un Exclusive Time faible — le problème vient de ses appels enfants, et vous devez développer l’arbre. Par exemple, ListView.getView peut avoir un Inclusive Time élevé en raison d’appels de chargement d’images.

Identification des goulots d’étranglement

Recherchez les méthodes avec un Real Time anormalement élevé mais un CPU Time faible — cela indique un blocage (attente E/S, opération réseau, contention de verrou). Les méthodes avec un CPU Time élevé nécessitent une optimisation de l’algorithme. Pour le thread UI, chaque méthode doit se terminer dans les 16 ms — si un appel dépasse ce seuil, l’application perd une image et l’utilisateur voit des à-coups. Selon les recommandations de Google, le temps total de tous les appels dans le thread UI par image ne doit pas dépasser 8–10 ms, laissant une marge pour les opérations système.

Traceview vs Systrace : comparaison des outils

Bien que Traceview et Systrace soient tous deux des outils de traçage Android, ils résolvent des tâches différentes et sont utilisés à différentes étapes du profilage. La principale différence est le niveau de détail : Traceview opère au niveau des méthodes Java/Kotlin, Systrace au niveau des processus système (CPU, GPU, Binder, SurfaceFlinger).

En pratique, les deux outils se complètent : d’abord Systrace aide à identifier quel composant système cause le problème (par exemple, GC fréquent ou verrous Binder), puis Traceview permet d’approfondir une méthode spécifique dans l’application. Dans Android Studio, les deux outils sont combinés dans Android Profiler — CPU Profiler sélectionne automatiquement le mode d’enregistrement optimal. Sur les appareils avec Android 12+, Systrace et Traceview fonctionnent sur Perfetto, offrant un format de données unifié pour tous les types de profilage.

Exemples de code avec Traceview

Un profilage efficace nécessite plus que le simple démarrage du traçage — vous devez placer correctement les points de capture et interpréter les résultats. Voici deux exemples pratiques : le profilage du chargement du RecyclerView et la comparaison de deux algorithmes dans un test de performance.

Profilage du chargement du RecyclerView

Le premier exemple est le traçage du chemin critique lors du défilement de la liste. RecyclerView appelle onBindViewHolder pour chaque élément visible, et si cette méthode prend plus de 16 ms, le défilement devient saccadé. Le traçage autour d’onBindViewHolder montrera quelles opérations spécifiques à l’intérieur prennent du temps.

class MyAdapter : RecyclerView.Adapter<ViewHolder>() {
    override fun onBindViewHolder(
        holder: ViewHolder,
        position: Int
    ) {
        Debug.startMethodTracing("bind_card_$position")

        holder.bind(items[position])

        Debug.stopMethodTracing()
    }
}

Comparaison de deux algorithmes

Le deuxième exemple est un test de vitesse A/B de deux implémentations : chargement d’images via Glide contre BitmapFactory manuel. Cette trace permet une comparaison objective du Inclusive Time des deux stratégies et la sélection de la plus optimale. Il est important d’exécuter chaque test sur un appareil préchauffé (après 3–5 cycles) dans des conditions identiques (charge d’arrière-plan, température).

fun compareImageLoadingStrategies() {
    // Test A : Glide
    Debug.startMethodTracing("glide_test")
    loadWithGlide()
    Debug.stopMethodTracing()

    // Test B : BitmapFactory
    Debug.startMethodTracing("bitmap_test")
    loadWithBitmapFactory()
    Debug.stopMethodTracing()
}

Après l’exécution, ouvrez les deux fichiers .trace dans Android Studio et comparez le Inclusive Time dans le panneau Profil. Si Glide montre 3x moins de Inclusive Time pour la même tâche — c’est une base objective pour choisir la bibliothèque. Selon Tony John (développeur de Glide, 2023), la bibliothèque utilise la mise en cache et un pool de threads, offrant un gain allant jusqu’à 40% sur les chargements répétés.