Planification des performances

Les utilisateurs s’attendent à ce que leurs applications restent réactives, à se sentir naturelles et à ne pas vider leur batterie. Techniquement, les performances sont une exigence non fonctionnelle, mais le traitement des performances en tant que fonctionnalité vous aidera à répondre aux attentes de vos utilisateurs. La spécification des objectifs et la mesure sont des facteurs clés. Déterminez quels sont vos scénarios critiques en matière de performances ; définissez ce que signifient les bonnes performances. Mesurez ensuite rapidement et souvent suffisamment longtemps tout au long du cycle de vie de votre projet pour vous assurer que vous atteindrez vos objectifs.

Spécification des objectifs

L’expérience utilisateur est un moyen de base de définir de bonnes performances. Le temps de démarrage d’une application peut influencer la perception de ses performances par l’utilisateur. Un utilisateur peut considérer un temps de lancement d'application de moins d'une seconde comme excellent, de moins de 5 secondes comme bon et de plus de 5 secondes comme médiocre.

D’autres métriques ont un impact moins évident sur l’expérience utilisateur, par exemple la mémoire. Les chances d’arrêt d’une application pendant qu’elles sont suspendues ou inactives augmentent avec la quantité de mémoire utilisée par l’application active. Il s’agit d’une règle générale selon laquelle l’utilisation élevée de la mémoire dégrade l’expérience pour toutes les applications sur le système, de sorte que l’objectif sur la consommation de mémoire est raisonnable. Prenez en compte la taille approximative de votre application telle qu’elle est perçue par les utilisateurs : petite, moyenne ou grande. Les attentes relatives aux performances sont corrélées à cette perception. Par exemple, vous pouvez souhaiter une petite application qui n'utilise pas beaucoup de ressources multimédias pour consommer moins de 100 Mo de mémoire.

Il est préférable de définir un objectif initial, puis de le réviser plus tard, que de ne pas avoir d’objectif du tout. Les objectifs de performances de votre application doivent être spécifiques et mesurables, et ils doivent se trouver dans trois catégories : combien de temps il faut aux utilisateurs ou à l’application pour effectuer des tâches (temps) ; le taux et la continuité avec lesquels l’application se redessine en réponse à l’interaction utilisateur (fluidité) ; et comment l’application conserve les ressources système, y compris l’alimentation de la batterie (efficacité).

Heure

Considérez les plages acceptables de temps écoulé (classes d’interaction) qu'il faut aux utilisateurs pour terminer leurs tâches dans votre application. Pour chaque classe d’interaction, affectez une étiquette, un sentiment utilisateur perçu et des durées idéales et maximales. Voici quelques suggestions.

Vous pouvez maintenant affecter des classes d’interaction aux scénarios de performances de votre application. Vous pouvez affecter la référence point-in-time de l’application, une partie de l’expérience utilisateur et une classe d’interaction à chaque scénario. Voici quelques suggestions pour un exemple d’application de restauration et de nourriture.

Si vous affichez du contenu en direct, tenez également compte des objectifs de fraîcheur du contenu. L’objectif est-il d’actualiser le contenu toutes les quelques secondes ? Ou est-ce que l’actualisation du contenu toutes les quelques minutes, toutes les quelques heures, ou même une fois par jour, une expérience utilisateur acceptable ?

Avec vos objectifs spécifiés, vous pouvez désormais mieux tester, analyser et optimiser votre application.

Fluidité

Des objectifs de fluidité mesurables spécifiques pour votre application peuvent inclure :

• Pas d’interruptions ou de saccades lors du rafraîchissement d’écran.
• Les animations s’affichent à 60 images par seconde (FPS).
• Lorsqu’un utilisateur effectue un panoramique/défilement, l’application présente 3 à 6 pages de contenu par seconde.

Efficacité

Des objectifs d’efficacité mesurables spécifiques pour votre application peuvent inclure :

• Pour le processus de votre application, le pourcentage d’UC est à ou en-dessous de N et l’utilisation de la mémoire en Mo est à ou en-dessous de M à tout moment.
• Lorsque l’application est inactive, N et M sont zéro pour le processus de votre application.
• Votre application peut être utilisée activement pendant X heures sur batterie ; quand votre application est inactive, l’appareil conserve sa charge pendant Y heures.

Concevoir votre application pour les performances

Vous pouvez maintenant utiliser vos objectifs de performances pour influencer la conception de votre application. À l’aide de l’exemple d’application de restauration et de nourriture, une fois que l’utilisateur accède à la page recette, vous pouvez choisir de mettre à jour les éléments de manière incrémentielle afin que le nom de la recette soit rendu en premier, que l’affichage des ingrédients soit différé et que l’affichage des images soit encore plus différé. Cela maintient la réactivité et une interface utilisateur fluide lors du panoramique/défilement, avec le rendu complet et fidèle qui a lieu après que l'interaction ralentit jusqu'à un rythme permettant au thread d'interface utilisateur de rattraper son retard. Voici quelques autres aspects à prendre en compte.

Interface Utilisateur (UI)

• Optimisez l'efficacité de l'analyse, du temps de chargement et de l'utilisation de la mémoire pour chaque page de l'interface utilisateur de votre application (notamment la page initiale) en perfectionnant le balisage XAML. En un mot, reportez le chargement de l’interface utilisateur et du code jusqu’à ce qu’il soit nécessaire.
• Pour ListViewet GridView, faites en sorte que tous les éléments soient de la même taille et utilisez autant de techniques d’optimisation ListView et GridView que possible.
• Déclarez l’interface utilisateur sous la forme de balisage, que l’infrastructure peut charger et réutiliser en blocs, plutôt que de la construire impérativement dans le code.
• Retardez la création d’éléments d’interface utilisateur jusqu’à ce que l’utilisateur en a besoin. Consultez l’attribut x :Load.
• Préférez les transitions et animations de thème aux animations storyboardées. Pour plus d’informations, consultez vue d’ensemble des animations. N’oubliez pas que les animations storyboardées nécessitent des mises à jour constantes de l’écran et gardent le processeur et le pipeline graphique actifs. Pour conserver la batterie, n’avez pas d’animations en cours d’exécution si l’utilisateur n’interagit pas avec l’application.
• Les images que vous chargez doivent être chargées à une taille appropriée pour la vue dans laquelle vous la présentez, à l’aide de la méthode GetThumbnailAsync.

processeur, mémoire et énergie

• Planifiez un travail de priorité inférieure pour qu’il s’exécute sur des threads et/ou des cœurs de priorité inférieure. Consultez la programmation asynchrone , la propriété Dispatcher et la classe CoreDispatcher.
• Réduisez l’empreinte mémoire de votre application en libérant des ressources coûteuses (telles que des supports) en suspension.
• Réduisez l'empreinte mémoire de votre code.
• Évitez les fuites de mémoire en annulant l’inscription des gestionnaires d’événements et en déreferencant les éléments d’interface utilisateur dans la mesure du possible.
• Pour préserver la batterie, soyez économe avec la fréquence à laquelle vous obtenez des données, interrogez un capteur ou planifiez le travail sur le processeur quand il est au repos.

Accès aux données

• Si possible, prérécupérer le contenu. Pour la prérécupération automatique, consultez la classe nommée "ContentPrefetcher" . Pour une prérécupération manuelle, consultez l’espace de noms Windows.ApplicationModel.Background et la classe MaintenanceTrigger.
• Si possible, mettre en cache du contenu coûteux à accéder. Consultez les propriétés LocalFolder et LocalSettings.
• Pour les défauts de cache, affichez une interface de chargement aussi rapidement que possible pour indiquer que l'application charge toujours du contenu. Passer du contenu provisoire au contenu en direct de manière à ne pas perturber l'utilisateur. Par exemple, ne modifiez pas la position du contenu sous le doigt ou le pointeur de la souris de l’utilisateur lorsque l’application charge du contenu en direct.

Lancement de l'application et reprise de l'application

• Différer l’écran de démarrage de l’application et ne pas étendre l’écran de démarrage de l’application, sauf si nécessaire. Pour plus d’informations, consultez Créer une expérience de lancement d'application rapide et fluide et afficher un écran de démarrage pendant plus longtemps.
• Désactivez les animations qui se produisent immédiatement après la fermeture de l’écran de démarrage, car cela donne uniquement l’impression d’un retard dans le lancement de l'application.

Interface utilisateur adaptative, et orientation

• Utilisez la classe VisualStateManager.
• Effectuez uniquement le travail nécessaire immédiatement, en reportant le travail intensif de l’application jusqu’à plus tard , votre application a entre 200 et 800 millisecondes pour terminer le travail avant que l’utilisateur ne voit l’interface utilisateur de votre application dans un état rogné.

Avec vos conceptions liées aux performances en place, vous pouvez commencer à coder votre application.

Instrument de performance

À mesure que vous codez, ajoutez du code qui journalise les messages et les événements à certains points pendant l’exécution de votre application. Plus tard, lorsque vous testez votre application, vous pouvez utiliser des outils de profilage tels que l’enregistreur de performances Windows et l’analyseur de performances Windows (les deux sont inclus dans le Windows Performance Toolkit) pour créer et afficher un rapport sur les performances de votre application. Dans ce rapport, vous pouvez rechercher ces messages et événements pour vous aider à analyser plus facilement les résultats du rapport.

La plateforme Windows universelle (UWP) fournit des API de journalisation, soutenues par suivi d’événements pour Windows (ETW), qui offrent ensemble une solution de journalisation et de suivi d’événements enrichies. Les API qui font partie de l’espace de noms Windows.Foundation.Diagnostics, incluent les classesFileLoggingSession , LoggingActivity, LoggingChannelet LoggingSession.

Pour consigner un message dans le rapport à un moment spécifique pendant l’exécution de l’application, créez un objet LoggingChannel, puis appelez la méthode LogMessage de l’objet, comme suit.

// using Windows.Foundation.Diagnostics;
// ...

LoggingChannel myLoggingChannel = new LoggingChannel("MyLoggingChannel");

myLoggingChannel.LogMessage(LoggingLevel.Information, "Here' s my logged message.");

// ...

Pour journaliser les événements de démarrage et d’arrêt dans le rapport sur une période pendant l’exécution de l’application, créez un objet LoggingActivity, puis appelez le constructeur LoggingActivity de l’objet, comme suit.

// using Windows.Foundation.Diagnostics;
// ...

LoggingActivity myLoggingActivity;

// myLoggingChannel is defined and initialized in the previous code example.
using (myLoggingActivity = new LoggingActivity("MyLoggingActivity"), myLoggingChannel))
{   // After this logging activity starts, a start event is logged.
    
    // Add code here to do something of interest.
    
}   // After this logging activity ends, an end event is logged.

// ...

Consultez également l’exemple de journalisation .

Avec votre application instrumentée, vous pouvez tester et mesurer les performances de votre application.

Tester et mesurer par rapport aux objectifs de performances

Une partie de votre plan de performances consiste à définir les points pendant le développement où vous mesurerez les performances. Cela sert à différents objectifs selon que vous mesurez pendant le prototypage, le développement ou le déploiement. La mesure des performances au cours des premières phases du prototypage peut être extrêmement utile. Nous vous recommandons donc de le faire dès que vous avez du code qui effectue un travail significatif. Les premières mesures vous donnent une bonne idée de l'endroit où se situent les coûts importants dans votre application et aident à orienter les décisions de conception. Cela entraîne une mise à l’échelle et des applications performantes. Il est généralement plus coûteux de modifier les conceptions plus tard que précédemment. La mesure des performances tardives dans le cycle de produit peut entraîner des piratages de dernière minute et des performances médiocres.

Utilisez ces techniques et outils pour tester la façon dont votre application s’empile sur vos objectifs de performances d’origine.

• Testez sur une grande variété de configurations matérielles, notamment les PC tout-en-un et les PC de bureau, les ordinateurs portables, les ultrabooks et les tablettes et autres appareils mobiles.
• Testez sur une grande variété de tailles d’écran. Bien que les tailles d’écran plus larges puissent afficher beaucoup plus de contenu, l’apport de tout ce contenu supplémentaire peut avoir un impact négatif sur les performances.
• Éliminez autant de variables de test que possible.
  • Désactivez les applications en arrière-plan sur l’appareil de test. Pour ce faire, dans Windows, sélectionnez Paramètres dans le menu Démarrer >Personnalisation>écran de verrouillage. Sélectionnez chaque application active et sélectionnez Aucun.
  • Compilez votre application en code natif en la générant dans la configuration de mise en production avant de la déployer sur l’appareil de test.
  • Pour vous assurer que la maintenance automatique n’affecte pas les performances de l’appareil de test, déclenchez-la manuellement et attendez qu’elle se termine. Dans Windows, dans le menu Démarrer, recherchez sécurité et maintenance. Dans la zone de maintenance, sous Maintenance automatique, sélectionnez Démarrer la maintenance et attendez que l’état passe de Maintenance en cours.
  • Exécutez l’application plusieurs fois pour éliminer les variables de test aléatoire et garantir des mesures cohérentes.
• Testez la disponibilité réduite de l’alimentation. L’appareil de vos utilisateurs peut avoir beaucoup moins de puissance que votre ordinateur de développement. Windows a été conçu avec des appareils à faible alimentation, tels que les appareils mobiles, à l’esprit. Les applications qui s’exécutent sur la plateforme doivent s’assurer qu’elles fonctionnent correctement sur ces appareils. En tant qu’heuristique, attendez-vous à ce qu’un appareil à faible alimentation s’exécute à environ un quart de la vitesse d’un ordinateur de bureau et définissez vos objectifs en conséquence.
• Utilisez une combinaison d’outils tels que Microsoft Visual Studio et Windows Performance Analyzer pour mesurer les performances des applications. Visual Studio est conçu pour fournir une analyse axée sur l’application, comme la liaison de code source. Windows Performance Analyzer est conçu pour fournir une analyse axée sur le système, comme fournir des informations système, des informations sur les événements de manipulation tactile et des informations sur les E/S de disque et les coûts d’unité de traitement graphique (GPU). Les deux outils fournissent la capture de trace et l’exportation, et peuvent rouvrir les traces partagées et post-mortem.
• Avant de soumettre votre application au Windows Store pour certification, veillez à intégrer dans vos plans de test les cas de test liés aux performances, comme décrit dans la section « Tests de performances » des tests de Kit de certification des applications Windows et dans la section « Performances et stabilité » de cas de test d’application UWP.

Pour plus d’informations, consultez ces ressources et outils de profilage.

• Analyseur de performances Windows
• Windows Performance Toolkit
• Analyser les performances à l’aide des outils de diagnostic Visual Studio
• Performances XAML de la session //build
• Nouveaux outils XAML dans la session //build/ de Visual Studio 2015

Répondre aux résultats des tests de performances

Après avoir analysé les résultats de vos tests de performances, déterminez si des modifications sont nécessaires, par exemple :

• Devez-vous modifier l’une de vos décisions de conception d’application ou optimiser votre code ?
• Devez-vous ajouter, supprimer ou modifier l’instrumentation dans le code ?
• Devez-vous réviser vos objectifs de performance ?

Si des modifications sont nécessaires, faites-les, puis revenez à l’instrumentage ou au test et répétez.

Optimisation

Optimisez uniquement les chemins de code critiques pour les performances de votre application : ceux où la plupart du temps est passé. Le profilage vous indiquera lequel. Souvent, il existe un compromis entre la création de logiciels qui suit les bonnes pratiques de conception et l’écriture de code qui effectue au plus haut niveau d’optimisation. Il est généralement préférable de hiérarchiser la productivité des développeurs et une bonne conception logicielle dans les domaines où les performances ne sont pas un problème.