Les développeurs disent souvent que l'un de leurs objectifs est d'être "rapide". Pourtant, lorsqu'ils délivrent, leurs clients se plaignent souvent que c'est lent et pas assez réactif. D'après une étude interne de Microsoft, la première cause principale de ceci est le manque de planification. Rendre une application "rapide" n'est pas un objectif en lui-même car il ne peut pas être mesuré. De fait, lorsque les performances commencent à se dégrader, les développeurs ne le remarquent souvent pas. Ou pire, la performance n'est pas testée sur la bonne sorte d'infrastructure ou dans les bons environnements.
Les piliers de la performance sont la Rapidité, la Fluidité et l'Efficacité. Mais plutôt que de réfléchir sur ces concepts abstraits, vous pouvez le faire en termes qui conduisent à une réelle planification avec des objectifs spécifiques comme "charger 30 images dans la vue principale en 1 seconde ou moins". Ce type de planification de la performance permet des tests ciblés ainsi qu'une détection au plus tôt des problèmes de performance.
Rapide
Une manière de déterminer si une application est "rapide" ou non est de la voir en termes de "classes d'interaction". Une classe d'interaction est utilisée pour décrire un type d'interaction et un temps acceptable pour l'exécution de celui-ci. Voici quelques exemples utilisés par Microsoft sur leurs projets :
- Rapide : 100 à 200 ms - Cliquer sur un bouton, ouvrir un menu, faire apparaître une barre d'application
- Standard : 300 à 500 ms - Redimensionner, Zoom Sémantique
- Réactif : 500 ms à 1 sec - Naviguer vers une autre page
- Démarrer : 1 à 3 s - Démarrer une application
- Continue : 500 ms à 5 sec - Télécharger des fichiers
- Captif : 500 ms à 10 secondes - Opérations longues. L'utilisateur peut changer d'application en attendant
Les interactions complexes peuvent être détaillées en plages de temps différentes. Par exemple, naviguer vers une page de résultats de recherche peut nécessiter trois plages :
- Premier retour (Rapide) : L'utilisateur voit que quelque chose a démarré de telle sorte qu'il n'essaye pas de recliquer le bouton de recherche
- Réactif : L'information textuelle des résultats de recherche est visible et l'UI est utilisable.
- Visibilité entière (Continue) : Tout le contenu est chargé, y compris les images.
Fluide
La fluidité peut être mesurée en images par seconde. Pour la plupart des applications, l'objectif recommandé est connu comme "Buttery Smooth" ("lisse comme du beurre") ou 60 ips. Les applications qui ne peuvent maintenir ce niveau de fluidité devraient penser à simplifier leur écran.
Efficace
L'efficacité doit être réfléchie d'un point de vue de l'utilisateur. Ceux-ci se moquent généralement de savoir si la CPU ou le réseau pédalent lorsque l'application est en train de faire quelque chose qu'ils ont demandé. Mais si l'utilisateur ne fait rien, l'application devrait aussi ne rien faire. De fait, le but de toute application est une consommation de ressources nulle par défaut.
Les applications qui consomment plus de mémoire ont plus de chance d'être victimes de swap disque ou de mourir, de fait qu'un autre objectif devrait être une consommation mémoire faible. Il n'y a pas de recommandation spécifique à ce sujet, car ce qui est considéré comme acceptable varie grandement d'un type d'application à un autre.
La durée de vie de la batterie, et l'utilisation de services de données pour les appareils mobiles, sont aussi d'une importance capitale pour l'utilisateur final. Une étude que Microsoft a commandé révèle que 50% des utilisateurs citent l'utilisation importante de la batterie comme raison de désinstallation d'applications. Heureusement, la plupart des outils modernes de performance peuvent non seulement mesurer le trafic d'E/S, mais également approximer l'énergie consommée pendant l'exécution de l'application.
Instrumentation
La planification et la mise en place d'une instrumentation riche est nécessaire pour comprendre réellement le comportement des performances de l'application. L'utilisation de frameworks de journalisation sophistiqués comme Semantic Logging peut être utilisée pour corréler le début et la fin d'opérations spécifiques.
Testing
Un système silencieux est essentiel pour les tests ; un système qui effectue des opérations en tâches de fond peut conduire à des résultats de test erronés. A cet effet, Will Sergeant de Microsoft recommande :
- De désactivez les applications en tâches de fond. Si vous utilisez Windows 8, cela implique fermer les "Application de Verrouillage d'Ecran"
- Pour le code géré, de générer l'image de code natif. Pour cela, exécutez l'application 30 secondes ou plus, puis lancer les tâches de Maintenance Système de Windows 8
- De capturer toujours plusieurs exécutions successives
Matériel
Testez toujours sur différents types de matériel et différentes topologies réseau. Un réseau poussif peut avoir un effet désastreux sur les performances d'une application, spécifiquement lorsque cette dernière tente de télécharger des données sur le processus dédié à l'UI. La taille des écrans peut également avoir une influence significative sur les performances, car les écrans plus grands ont besoin d'afficher plus de données à un instant t.
Ces informations ont été présentées pour la première fois à la session Build 2013 du même nom.