Instruments — qu'est-ce que c'est, fonctionnalités de Time Profiler et Allocations

Qu'est-ce que Instruments ?

Instruments — est un système de profilage et de traçage faisant partie de Xcode et basé sur la technologie DTrace développée par Sun Microsystems. Instruments combine des dizaines d'outils de profilage (modèles) dans une interface unifiée : il suffit de sélectionner un modèle, de lancer l'application via Xcode et de commencer la collecte de données.

L'architecture d'Instruments est basée sur un modèle client-serveur : un agent sur l'appareil collecte les données et les transmet au Mac via une connexion USB. Cela minimise l'impact du profileur sur les performances de l'application — Instruments fonctionne principalement côté hôte. Selon la WWDC 2022, le surcoût du Time Profiler à une fréquence d'échantillonnage de 1 ms est inférieur à 3 %.

Instruments prend en charge les modèles personnalisés — le développeur peut combiner plusieurs outils en une seule session de profilage. Par exemple, lancez simultanément Time Profiler + Allocations + Leaks et visualisez la corrélation entre les pics CPU et les allocations mémoire. Cela donne une image globale des performances, inaccessible lors d'une analyse isolée de chaque composant.

Quels modèles sont disponibles par défaut

Xcode est livré avec 16 modèles Instruments préinstallés : Time Profiler, Allocations, Leaks, Energy Log, Network, Core Animation, Metal System Trace, File Activity, System Trace et autres. Chaque modèle est optimisé pour une tâche spécifique et préconfiguré avec les bons paramètres de déclencheurs et de filtres.

Time Profiler : analyse des performances CPU

Time Profiler — est le modèle le plus utilisé d'Instruments. Il fonctionne par échantillonnage de la pile d'appels : toutes les 1 à 10 millisecondes, le système enregistre la pile d'appels de tous les threads de l'application. Après l'arrêt de la session, Instruments additionne les échantillons et montre quelles méthodes et fonctions ont pris le plus de temps. Le résultat est présenté sous forme d'arbre d'appels (Call Tree) trié par Self Weight.

La métrique clé du Time Profiler est le Self Weight (temps passé directement dans la méthode, sans tenir compte des appels aux méthodes filles). C'est le Self Weight qui montre quelles fonctions chargent réellement le processeur. Le Weight (temps total avec les méthodes filles) peut être trompeur : une méthode avec un Weight élevé peut simplement appeler une autre méthode lente, tout en étant elle-même rapide.

import UIKit

class ImageGalleryViewController: UIViewController {
    // Time Profiler montrera que cellForItemAt a Self Weight = 40 %
    // à l'intérieur, decodeImage occupe 35 % — c'est le goulot d'étranglement

    func collectionView(
        _ collectionView: UICollectionView,
        cellForItemAt indexPath: IndexPath
    ) -> UICollectionViewCell {
        let cell = collectionView.dequeueReusableCell(
            withReuseIdentifier: "ImageCell",
            for: indexPath
        ) as! ImageCell
        // ❌ decodeImage — goulot d'étranglement (Self Weight = 35 %)
        cell.imageView.image = UIImage(contentsOfFile: imagePath)
        return cell
    }
}

Lors de l'analyse du Time Profiler, faites attention aux méthodes s'exécutant dans com.apple.main-thread. Si le Self Weight sur le thread principal dépasse le seuil de 16 ms par image — l'UI va ralentir. La solution à ces problèmes est de déplacer le décodage d'images, les calculs de layout et le traitement des données du thread principal vers un thread d'arrière-plan via Grand Central Dispatch (GCD).

Comment lire l'arbre d'appels dans Time Profiler

Call Tree — est une représentation hiérarchique de tous les appels de méthodes, triée par Self Weight. La méthode la plus lourde dans l'arbre d'appels est la première ligne. En développant la ligne, vous voyez quelles méthodes filles cette méthode a appelées et combien de temps elles ont pris. Recherchez les méthodes où le Self Weight (temps propre) dépasse significativement le Weight (temps total) — ce sont des signes de blocages synchrones et d'attente.

Allocations : suivi mémoire en temps réel

Allocations — est un outil de surveillance de toutes les allocations mémoire de l'application. Il montre quels objets, en quelle quantité et avec quelle taille totale sont créés à chaque instant. Contrairement au Memory Profiler d'Android Studio, Allocations prend en charge Heapshot — un instantané des objets vivants avec possibilité de comparer deux instantanés.

L'interface d'Allocations se compose de deux sections principales : All Allocations (statistiques totales par type d'objet) et Call Trees (arbre d'appels avec répartition par méthodes créant des objets). Pour trouver les fuites, utilisez Heapshot Analysis : prenez un instantané avant d'exécuter un scénario, exécutez le scénario, prenez un instantané après — et comparez quels nouveaux objets sont restés en mémoire.

Selon la Apple Developer Documentation, le modèle de fuite le plus courant détecté par Allocations est la création excessive d'UIView et de CALayer lors du défilement de collections. Si à chaque défilement le nombre d'UIView vivantes augmente, mais que la collection réutilise les cellules — quelque part des vues supplémentaires sont créées sans libérer les anciennes. Allocations montre la pile d'appels exacte où ces vues sont créées.

Heapshot Analysis : comparaison d'instantanés mémoire

Heapshot — est un instantané des objets vivants dans Allocations. Prenez un Heapshot avant d'exécuter le scénario, exécutez le scénario et prenez un second Heapshot. La différence entre les instantanés montrera quels objets ont été créés et non libérés. Le résultat idéal — une augmentation uniquement des objets temporaires (Autorelease pool). Pour une analyse précise, utilisez la combinaison Allocations + Leaks dans une même session. Allocations montre quels objets ne sont pas libérés, et Leaks — pourquoi (quelle référence forte les retient). Lancez une session double à chaque suspicion de fuite.

Leaks : recherche automatique de fuites mémoire

Leaks — est un outil spécialisé pour la détection de fuites mémoire dans les applications iOS et macOS. Contrairement à Allocations, qui se contente d'afficher les allocations, Leaks scanne activement le heap à la recherche de retain cycles — des situations où deux ou plusieurs objets se retiennent mutuellement avec des références fortes.

Leaks fonctionne de concert avec Cycles & Roots — un visualiseur du graphe de rétention d'objets. Lorsqu'une fuite est détectée, Leaks montre tous les objets dans le cycle, leur retain count et les champs exacts par lesquels les références sont passées. Le développeur n'a qu'à regarder le graphe et comprendre quelle référence doit être remplacée par weak.

L'outil surligne automatiquement les fuites avec un marqueur rouge sur la chronologie. Leaks fonctionne en temps réel : dès que le système détecte une fuite, il signale immédiatement le développeur. Cela permet de corriger les problèmes «sur place», sans attendre le vidage et la post-analyse.

Selon la WWDC 2022, Leaks est capable de détecter même les retain cycles complexes à plusieurs niveaux — par exemple, lorsque trois objets ou plus forment une chaîne fermée de références fortes. Pour diagnostiquer de tels cycles, le graphe Cycles & Roots est indispensable : il montre visuellement comment les objets se referment les uns sur les autres.

Comment lire le graphe Cycles & Roots

Chaque nœud du graphe est un objet, chaque flèche est une référence forte. Un cycle est une boucle fermée de flèches. La couleur du nœud indique le statut : rouge — objet fuyant, vert — racine (GC Root), gris — objet intermédiaire. Pour corriger la fuite, trouvez une flèche qui peut être rendue weak sans casser la logique — et changez le type de référence dans le code.

Energy Log : analyse de la consommation d'énergie

Energy Log — est un modèle Instruments pour mesurer la consommation d'énergie de l'application. Il collecte les données des capteurs matériels de l'appareil : charge CPU, état du Wi-Fi et de la radio cellulaire, utilisation GPS, écran et Bluetooth. Energy Log montre quelles opérations dans l'application causent la plus grande consommation de batterie et les superpose sur un graphique de consommation d'énergie dans le temps.

L'outil classe les opérations par niveau de consommation d'énergie : faible (fonctionnement normal du processeur), moyen (transmission Wi-Fi), élevé (GPS, réseau mobile, GPU). Si Energy Log affiche des indicateurs rouges de niveau élevé pendant une période prolongée — l'application décharge la batterie en arrière-plan et sera supprimée par l'utilisateur.

Problèmes typiques identifiés par Energy Log : WakeLock sans limitation de temps (l'application maintient le processeur actif après avoir terminé une tâche), Location Updates avec haute précision en arrière-plan (demande de coordonnées toutes les quelques secondes), anomalies de sessions réseau (reconnexions fréquentes au serveur). Energy Log recommande d'enregistrer chaque incident de ce type et d'ajouter une condition pour désactiver l'opération énergivore.

Pour tester la consommation d'énergie, utilisez un appareil réel sur batterie — sur l'émulateur, les indicateurs de consommation d'énergie sont incorrects. Exécutez Energy Log avec les tests UI pour automatiser la vérification de la consommation de batterie dans le CI.

Comment lancer et interpréter les résultats d'Instruments

Le lancement d'Instruments se fait depuis Xcode de deux manières : via le menu Product → Profile (⌘I) ou en ouvrant Instruments comme une application séparée dans Launchpad. La première méthode est plus pratique : Xcode compile automatiquement l'application en mode profilage et la lance sur l'appareil connecté avec le modèle sélectionné. Après l'arrêt de la session, Instruments enregistre le trace dans un fichier avec l'extension .trace.

L'interprétation des résultats dépend du modèle. Pour Time Profiler, regardez l'arbre d'appels trié par Self Weight — les méthodes en haut sont vos principaux goulots d'étranglement. Pour Allocations — regardez # Living après un scénario cyclique : si le nombre d'objets a augmenté, cherchez une fuite. Pour Leaks — regardez les marqueurs rouges et le graphe Cycles & Roots. Comparez les résultats avant et après l'optimisation — c'est la seule façon de confirmer l'efficacité des changements.

// Ligne de commande pour Instruments dans le CI
// Intégration d'Instruments dans le pipeline CI/CD
import XCTest

class PerformanceTests: XCTestCase {
    func testScrollPerformance() {
        // Mesure du temps de défilement de la collection
        measure(metrics: [XCTCPUMetric(), XCTMemoryMetric()]) {
            app.scrollToBottom()
        }
    }
}

Dans le CI, on peut exécuter Instruments en ligne de commande via xcodebuild -showBuildSettings et xcrun xctrace. Cela permet d'automatiser le profilage à chaque commit et de ne pas manquer de régression. Pour l'analyse, utilisez une comparaison avec la baseline : si la métrique s'est dégradée de 5 % par rapport au commit précédent — le pipeline doit s'arrêter.

Principales erreurs lors du travail avec Instruments : profilage sur simulateur au lieu de l'appareil (données CPU et GPU incorrectes), collecte de données sans scénario (résultats aléatoires), ignorer l'arbre d'appels (regarder uniquement le graphique, pas les méthodes spécifiques). Corriger ces erreurs donne 80 % de la qualité du profilage.