Windows Phone 7, Applications et Performances

J’ai lu une bonne cinquantaine d’articles / billets / forums concernant la performance des applications sur Windows Phone 7. Il y a tellement de choses à en dire que tout cela ne pourrait être traité dans un seul billet. Je vous propose toutefois d’en parler un peu et de faire une synthèse de tout ce que j’ai pu lire.

Les axes de performances

Jan Slodicka, un développeur de Resco, a écrit un excellent article ici et il dit quelque chose d’important, je cite :

Most users — when they see nothing changed for 2 seconds — assume something is broken and act correspondingly. You have two options how to handle this situation:
– Making your app acting faster, i.e. improve the real performance.
– Making your app appear faster, i.e. improve the perceived performance.
In fact, positive perceived performance is one of the central requirements when submitting apps to the WP7 market place. The app should never appear irresponsive, you need to entertain the user during lengthy computation, show some action, animations etc.

Les points qu’il cite représentent les 2 aspects des performances dans une application Windows Phone 7, performance perçue et performance réelle.

Avant de parler un peu de ces axes, il est indispensable de pouvoir mesurer les performances de son application.

Outils d’analyses de performances

Avant toute chose, il est utile de rappeler que les tests ne vous donneront généralement pas les mêmes résultats (même exécutés plusieurs fois de suite). Cependant, vous aurez une moyenne estimée selon les résultats obtenus.
Par ailleurs, n’utilisez pas seulement l’émulateur Windows Phone ! Il est indispensable de tester également sur un téléphone afin que vos tests soient plus proches de la réalité (l’émulateur hérite des performances de votre poste tandis que sur le périphérique vous aurez des performances beaucoup plus réelles).

Compteurs de performance par défaut

Les compteurs de performances sont ceux livrés par défaut, et qu’il est possible d’activer dans le fichier App.xaml.cs dans le constructeur

// Show graphics profiling information while debugging.
     if (System.Diagnostics.Debugger.IsAttached)
     {
        // Display the current frame rate counters.
        Application.Current.Host.Settings.EnableFrameRateCounter = true;

        // Show the areas of the app that are being redrawn in each frame.
        //Application.Current.Host.Settings.EnableRedrawRegions = true;

        // Enable non-production analysis visualization mode, 
        // which shows areas of a page that are being GPU accelerated with a colored overlay.
        //Application.Current.Host.Settings.EnableCacheVisualization = true;
    }

Sur le blog de Jaime Rodriguez, il y a une petite documentation très bien réalisée sur l’ensemble des indicateurs de performances. Vous pouvez la trouver en cliquant ici et il s’agit d’un document “cheat-sheet” (WindowsPhonePerfFireStarter_PDF.pdf).

Dans ce même document, il décrit et donne des conseils pour améliorer les performances sensibles du téléphone.

Compteurs de performances personnalisés

Toujours dans l’analyse des performances au niveau mémoire, il y a une classe proposée sur ce site, MemoryMonitor qui est vraiment pratique et qui propose d’analyser la mémoire totale du périphérique (DeviceTotalMemory), la mémoire qu’utilise l’application en cours (ApplicationCurrentMemoryUsage) ainsi que le pic de mémoire atteint (ApplicationPeakMemoryUsage).

Quand la mémoire atteint le seuil de validation, un message d’alerte apparait. Il faut garder à l’esprit que la mémoire d’une application ne doit pas excéder 90 Mb afin que cette dernière puisse être validée (l’idéal étant de pouvoir rester largement en dessous).

Compteurs de chargement

Jan, toujours dans son article propose un DebugWatch qui permet d’analyser le temps de chargement de contrôles ou de processus. Cette classe n’est pas automatique, et il faudra démarrer et arrêter aux bons endroits son instance.

Des profilers ?

Le seul que j’aie trouvé est EQATEC. C’est un profiler de code par contre, et pas de mémoire (c’est à dire qu’il va simplement analyser le code pour détecter le nombre d’appel des méthodes, leur temps d’exécution, etc…) afin de pouvoir détecter les axes d’amélioration. Il existe une version gratuite mais limitée.
Voilà un peu l’ensemble des outils à notre disposition pour analyser les performances. Pour ma part, j’ai choisi MemoryMonitor et DebugWatch (que j’ai un peu modifié pour pouvoir afficher les résultats en direct dans mon application).

Les performances réelles et les performances perçues ne sont pas forcément dépendantes les unes des autres mais en même temps ne peuvent aller l’une sans l’autre.
En effet, votre application peut sembler très rapide sans que pour autant ses performances réelles ne soient de la partie (Problème réseau, distant, mauvaise gestion de flux de données, etc…).
Par ailleurs, les performances réelles et performances perçues n’interviennent pas au même endroit ni même de la même façon. En tout cas, il est important que ces 2 axes puissent être positifs.

Les performances perçues

Les performances perçues sont celles que l’utilisateur peut ressentir directement en navigant au sein de l’application, celles qui lui donnent l’impression que son application n’est pas figée, qu’elle a reçu des commandes et qu’elle travaille ou quand suite à une erreur (bien souvent de chargement), il y a rapidement des infos en retour. En 2 mots : Réactivité Interface.
Mesurer les temps de réaction de l’interface est aisé avec DebugWatch et est un très bon point. Il faut également de temps en temps surveiller l’arbre visuel de vos contrôles (à l’aide de TreeHelper).
Que faire pour rendre une interface réactive ?

Epurer l’interface

Cela se fait à plusieurs niveaux :
– Eviter de multiplier le nombre de contrôles sur une page / vue. Privilégier des informations, claires, précises sur une page (ou alors, un item d’un pivot ou d’un panorama), et n’hésitez pas à en utiliser d’autres.
Ensuite, vous pourrez trouver davantage d’informations ici : http://www.codeproject.com/KB/showcase/WP7-Performance.aspx.
Où Jan parle de l’amélioration des performances perçues.

Informer l’utilisateur sur l’état des communications

En utilisant par exemple le contrôle ProgressBar avec la propriété IsIndeterminate=True (utiliser la “Performance ProgressBar de Jeff Wilcox).

Attention! Il est possible d’améliorer les performances visuelles davantage en réduisant le nombre de points de l’animation (passer de 5 à 3 par exemple).

Moins de Binding …

… dans le Xaml. Mais, là, on parle plutôt de l’utilisation des converteurs qui peuvent être coûteux en performances. La logique pour laquelle il était utilisée doit plutôt être créée dans le code source.

Et bien d’autres points encore. A la fin de cet article, j’ai mis quelques liens qui étoffent davantage ces aspects de performance.

Les performances réelles (ou effectives)

Les performances réelles sont en plus de tout ce que vous mettrez en oeuvre pour que votre application soit perçue performante, tout ce que vous mettrez en œuvre pour qu’elle réagisse très vite.
Cela interviendra cette fois-ci à différents niveaux qui sont lecture des données, lecture de flux, affichage données (sérialisation, tombstoning (gestion de l’état de l’application)).

Prochainement, je vous proposerai de voir en détail, un des aspects d’une de mes applications WP7 (optimisation de la lecture de données larges).

Quelques liens en vracs avec des solutions intéressantes :

Performances
Windows Phone 7 Developer Tips and Tricks chez Tim Heuer
LowProfileImageLoader et DefferedLoadListBox de David Anson

Performances des ListBox

Serialisation
Un premier comparatif de sérialisation sous Windows phone 7

Un second comparatif avec et la présentation du Serializer binaire très performant pour Windows Phone 7

Tombstoning
Shawn Wildermuth en parle .
Joost Van Schaik aussi

Pour finir

En ayant lu tous ces articles (et bien d’autres encores), j’ai remarqué que souvent, il nous est proposé de créer des contrôles dans le code plutôt que dans le xaml, de binder certaines propriétés dans le code. Ma première réaction avait été de me demander si l’on travaille ainsi, qu’advient-il de MVVM ?
Voici un extrait de la réponse qui m’a été portée par le développeur de Resco :

Hi David,
you are right. These optimizations do not play very well with MVVM.
As far I am concerned – cleanly structured code is of utmost importance for me, but I am no big friend of strict methodologies. I see MVVM as a usefull guidance, nothing more.
On the other hand, MVVM is not that strict either:
– It does not need converters.
– Bindings are just one of the possibilities. Preferred, of course, but if they are costly, you can equip the View with the cs code as long as the separation of concerns between the View and ViewModel takes place.
etc.
Don’t forget that the subject of optimization – MonthCalendar – was an extremally complex control. Bindings etc. add some overhead, but in most cases the performance loss is hardly measurable.

Bon courage et bonne optimisation.

Nombre de vue : 68

COMMENTAIRES 2 commentaires

  1. Benjamin Baumann dit :

    Tout n’est que compromis entre facilité de code et performance. Le problème de la sérialisation est le même en .NET classique : le binaire est plus rapide que du JSON qui est lui meme plus rapide que du SOAP xml. Le xml est très (trop!) verbeux mais facilement compréhensible par des êtres humains et soap est bien intégré dans l’univers microsoft.

    Pour ce qui est des contrôles, je demande à voir un comparatif de perfs entre un controle instancié depuis le code (compilé en IL) et le même instancié depuis le XAML (compilé en BAML). A mon avis la différence de perf est minime si les deux contrôles sont bien codés.

    Bref, on en revient toujours au même problème, il faut trouver un compromis entre performance et maintenance/développement en essayant de ne pas tomber dans les travers de l’un (que celui qui n’a jamais codé un solitaire qui prend plus de 10Mo de RAM me lance le premier valgrind) ou de l’autre (coder une interface en XAML est quand même plus appréciable qu’en assembleur).

    Sinon très bon article avec de très bons liens.

  2. […] d’en parler un peu et de faire une synthèse de tout ce que j’ai pu lire… Lire la suite chez Soat. Windows Phone ← C# – Un FtpHelper allégé [Techdays 2011] : Bilan d’une journée […]

AJOUTER UN COMMENTAIRE