Créer un contrôle de régression énergétique iOS avec xctrace

Une logique de rafraîchissement de liste en apparence anodine peut maintenir le CPU actif en continu. Des minuteurs trop fréquents, des requêtes réseau répétées ou des tâches en arrière-plan peuvent également multiplier les réveils. Les tests fonctionnels ne signalent généralement aucune erreur, et la couverture de code ne révèle pas davantage le problème. Pour détecter ces changements avant la fusion, il est possible de stabiliser l’environnement de test sur un Mac cloud OVPS, d’enregistrer la même séquence d’actions utilisateur avec xctrace, puis de comparer les résultats à une référence validée.

Définir d’abord ce que mesure le contrôle énergétique

La consommation d’énergie n’est pas une valeur unique indépendante du contexte. Une page d’accueil inactive, un défilement continu, le décodage d’images et une synchronisation en arrière-plan présentent des profils de ressources très différents et ne doivent pas partager la même référence. Commencez par choisir un parcours essentiel, reproductible de manière stable et d’une durée de 60 à 120 secondes, par exemple : lancer l’application, ouvrir la liste des messages, faire défiler trois écrans, afficher une fiche détaillée, puis revenir en arrière.

Pour chaque scénario, consignez au minimum les conditions suivantes :

• la version de soumission de l’app et la configuration de build ;
• le modèle de l’appareil, la version du système et la plage de charge de la batterie ;
• la luminosité de l’écran, le type de réseau et l’état du mode économie d’énergie ;
• le volume de données du compte de test ;
• la durée d’échantillonnage, le nombre de préchauffages et le nombre d’exécutions de mesure.

Le simulateur convient pour vérifier la stabilité des scripts d’automatisation et des actions, mais il ne représente pas la consommation énergétique d’un appareil réel. Le contrôle officiel doit être associé à un appareil physique fixe ; les résultats du simulateur ne peuvent servir que d’indice complémentaire sur l’activité des processus.

N’utilisez pas directement la première exécution. Le premier lancement peut inclure une migration de base de données, la préparation des shaders ou le remplissage des caches. Effectuez d’abord un préchauffage, puis au moins trois enregistrements de mesure, et utilisez la médiane afin de réduire le bruit provoqué par des tâches système occasionnelles.

Stabiliser le Mac cloud et l’état de l’appareil de test

Le nœud d’exécution doit utiliser une version majeure fixe de Xcode et sélectionner explicitement le répertoire des outils de développement. Ne dépendez pas de variables d’environnement actives par hasard dans un Shell interactif.

set -euo pipefail

export DEVELOPER_DIR="/Applications/Xcode.app/Contents/Developer"
xcodebuild -version
xcrun xctrace version
xcrun xctrace list devices
xcrun xctrace list templates

Les deux dernières commandes servent également de contrôle de compatibilité. Les modèles disponibles et la structure des exports peuvent varier selon la version de Xcode. Le script ne doit donc pas supposer que Energy Log existe toujours. Si le modèle est introuvable, il doit s’arrêter immédiatement tout en conservant les informations de version, plutôt que de poursuivre avec un échantillonnage vide et dépourvu de sens.

Avant le test, l’appareil physique doit retrouver un état constant : fermez les applications sans rapport avec le scénario, conservez une plage de charge similaire, vérifiez que la température est revenue à la normale, désactivez les mises à jour automatiques et stabilisez les conditions réseau. Pendant la mesure, n’exécutez pas simultanément d’archivage, de téléchargement de dépendances ou de nettoyage du disque. Une charge supplémentaire sur un nœud partagé fausserait les mesures du CPU et des E/S.

Mettre en place une vérification préalable

Enregistrez l’UDID de l’appareil, le Bundle ID, le nom du scénario et l’identifiant du commit dans un même répertoire d’exécution. Le nom du répertoire doit être unique, sans inclure de jetons ni de données de signature dans le chemin ou les journaux.

RUN_ID="$(date -u +%Y%m%dT%H%M%SZ)-${GIT_COMMIT:-local}"
OUT_DIR="artifacts/energy/${RUN_ID}"
mkdir -p "$OUT_DIR"

xcrun simctl list devices > "$OUT_DIR/devices.txt"
xcrun xctrace list templates > "$OUT_DIR/templates.txt"
git rev-parse HEAD > "$OUT_DIR/commit.txt"

Lorsqu’un appareil physique est connecté, la première commande peut être remplacée par la commande de détection utilisée par votre équipe. La forme de la commande importe peu : l’essentiel est d’arrêter la mesure en cas d’échec afin de ne pas interpréter « appareil non connecté » comme une « baisse de la consommation énergétique ».

Enregistrer des traces xctrace reproductibles

Lancez d’abord le processus à tester et terminez le préchauffage, puis attachez-vous au nom du processus. Le script ci-dessous exige que l’appareil, le processus et le modèle soient tous fournis explicitement par les paramètres de la CI :

DEVICE_UDID="${DEVICE_UDID:?missing DEVICE_UDID}"
PROCESS_NAME="${PROCESS_NAME:?missing PROCESS_NAME}"
TRACE="$OUT_DIR/energy.trace"

xcrun xctrace record \
  --template "Energy Log" \
  --device "$DEVICE_UDID" \
  --attach "$PROCESS_NAME" \
  --time-limit 90s \
  --output "$TRACE"

Une fois l’enregistrement lancé, l’automatisation de l’interface utilisateur doit exécuter la séquence d’actions définie. Le script doit utiliser des identifiants d’accessibilité plutôt que des coordonnées d’écran. Les données de test doivent être chargées au préalable, et les requêtes réseau doivent de préférence cibler un environnement de test stable. Si une exécution rencontre un échec de connexion, une fenêtre qui masque l’interface ou une page qui n’est jamais atteinte, elle doit être déclarée invalide et ne pas être incluse dans le calcul de la médiane.

Un retour réussi de xctrace signifie uniquement que la trace a été générée, et non que le scénario s’est correctement déroulé. Pour chaque enregistrement, conservez également les résultats du test d’interface, les heures de début et de fin, un résumé des journaux de l’application et un indicateur confirmant l’achèvement du scénario. Si l’un de ces éléments manque, le contrôle doit signaler une « mesure invalide » plutôt qu’une réussite du test de performance.

Exporter les métriques et les comparer à la référence

Commencez par exporter la table des matières de la trace pour vérifier quelles tables sont disponibles dans la version actuelle de Xcode, puis maintenez des règles d’analyse adaptées à cette version :

xcrun xctrace export \
  --input "$TRACE" \
  --toc \
  --output "$OUT_DIR/toc.xml"

N’utilisez pas une unique expression régulière fragile pour analyser directement une trace binaire. Une méthode plus fiable consiste à conserver des expressions XPath ou un analyseur XML pour chaque version majeure de Xcode, tout en archivant également la trace d’origine. Le contrôle peut surveiller quatre catégories de variations : l’activité CPU continue, les réveils de threads, la fréquence de déclenchement des minuteurs et le volume des transferts réseau. Ce sont des indices de diagnostic qui ne doivent pas être agrégés de manière simpliste en un unique « score énergétique ».

La référence doit provenir de plusieurs exécutions normales effectuées avec le même appareil, le même scénario et le même type de build. Il est recommandé de conserver la médiane de la dernière version validée ainsi que chaque valeur brute. La comparaison doit combiner une variation relative et un seuil absolu minimal : le doublement d’une valeur extrêmement faible n’a pas nécessairement de conséquence significative sur le plan technique.

Traiter les anomalies par niveaux

Un léger écart doit d’abord produire un avertissement sans bloquer la fusion. Le contrôle ne doit échouer qu’après plusieurs dépassements consécutifs du seuil, ou lorsque l’utilisation du CPU et le nombre de réveils se dégradent simultanément. Les seuils doivent être déterminés à partir des échantillons historiques de l’équipe, et non copiés depuis un pourcentage générique.

Le rapport d’échec doit contenir au minimum l’identifiant du commit, l’appareil et la version du système, les trois valeurs mesurées, la médiane, la référence, le taux de variation, le chemin de la trace et le résultat du scénario d’interface. Les développeurs peuvent ainsi ouvrir directement les éléments de preuve au lieu de devoir interpréter un simple message indiquant que « la consommation énergétique est trop élevée ».

Remonter d’une trace anormale jusqu’au code

Lorsque l’activité du CPU reste trop élevée, vérifiez d’abord les interrogations répétées sur le thread principal, le traitement des images, les recalculs de mise en page et les files d’attente en arrière-plan qui ne se terminent pas. Si le nombre de réveils augmente, examinez en priorité les minuteurs à intervalle court, les écritures fréquentes sur le disque, les notifications répétées et les nouvelles tentatives réseau qui ne sont pas regroupées. En cas d’activité réseau anormale, contrôlez les requêtes de pagination, les accès au cache, les lots de télémétrie et la stratégie de reconnexion.

Les causes courantes de faux positifs doivent également être écartées séparément : changement de température après la recharge de l’appareil, cache encore en cours de construction lors de la première exécution, variation du volume de données du compte de test, interruption du scénario par une fenêtre système ou exécution simultanée d’autres tâches lourdes sur le Mac cloud. Après la correction, les trois exécutions complètes doivent être relancées dans les mêmes conditions. Un seul résultat favorable ne doit jamais remplacer l’historique d’un échec.

En définitive, la valeur d’un contrôle de régression énergétique ne réside pas dans la production d’un score séduisant, mais dans l’association du scénario de test, des conditions de l’appareil, des traces brutes et du commit de code. Ce n’est que si ces preuves peuvent être recueillies de manière reproductible que les anomalies peuvent être attribuées clairement et que le contrôle évite de devenir une source de bruit régulièrement contournée.

Questions fréquentes