Lancez plus rapidement vos applications Windows Phone sur le marché

Windows Phone SDK 7.1 comprend certains outils excellents pour évaluer la conformité aux instructions de certification et améliorer les performances des applications qui ciblent Windows Phone 7.5, avant leur lancement sur le marché. Dans cet article, j'expliquerai l'utilisation du Marketplace Test Kit et de l'outil Performance Analysis sur un exemple d'application et je montrerai comment utiliser ces outils pour évaluer le niveau de préparation de votre application pour le marché. Je montrerai comment utiliser les données de ces outils afin d'appliquer des améliorations qui vous aideront à faire accepter votre application sur le marché dès la première tentative. Pour plus d'informations sur les conditions de certification pour le marché, consultez l'article de la bibliothèque MSDN « Conditions de Certification d'Application Windows Phone » (wpdev.ms/certreq).

Tous les outils utilisés dans cet article sont inclus dans Windows Phone SDK 7.1, que vous pouvez télécharger sur wpdev.ms/wpsdk71rtw.

Exemple d'application et outils de test

Pour mettre en pratique le Marketplace Test Kit et l'outil Performance Analysis, j'ai créé un exemple d'application nommé Examiner l'étamine. Il s'agit d'une application simple d'identification des fleurs. Je l'ai créée en pensant à ma mère ; elle peut l'utiliser pour améliorer ses compétences en matière d'identification de fleurs. L'application affiche plusieurs petites images de fleurs sur l'écran de démarrage. Un utilisateur tape sur la fleur et l'application accède à une autre page dans laquelle elle affiche une image plus grande de la fleur sélectionnée. S'il tape à nouveau sur cette image, le nom de la fleur s'affiche dans une boîte de message. La figure 1 montre les images affichées au fur et à mesure que je parcours l'application. Il convient de mentionner ici que j'ai utilisé le nouvel outil de capture d'écran disponible dans Windows Phone Emulator. Pour plus d'informations, consultez l'article de la bibliothèque MSDN « How to: Create Screenshots for Windows Phone Marketplace » (wpdev.ms/rYoZKP).

Figure 1 Images affichées dans le programme Examiner l'étamine

Bien que cette application ne soit pas complètement adaptée à la réalité, elle constitue un modèle de navigation acceptable pour une application de téléphone. Je vais évaluer cette application à l'aide du Marketplace Test Kit dans Visual Studio, puis l'examiner plus en détail avec l'outil Windows Phone Performance Analysis. Lorsque j'aurai identifié des problèmes éventuels, j'utiliserai les ressources de documentation disponibles pour déterminer comment résoudre ces problèmes, puis je testerai à nouveau avec les outils.

Mettons-nous au travail.

Utilisation du Marketplace Test Kit

J'ai créé une interface utilisateur relativement jolie pour Examiner l'étamine, ainsi qu'un modèle de navigation acceptable. J'ai l'intention d'ajouter d'autres fleurs à l'avenir, mais je souhaite lancer mon application sur le marché dès maintenant. L'étape suivante pour moi consiste à utiliser le Marketplace Test Kit pour évaluer le niveau de préparation de mon application pour le marché grâce à une suite de tests automatisés, contrôlés et manuels.

Pour exécuter les tests, j'ouvre mon projet d'application dans Visual Studio et je sélectionne « Marketplace Test Kit » dans le menu Projet.

Un nouvel onglet s'ouvre dans Visual Studio. Il affiche les suites de tests du Marketplace Test Kit. La figure 2 présente la première page du kit de test.

Figure 2 La première page du Marketplace Test Kit dans Visual Studio

Les suites de tests disponibles sont indiquées dans les onglets situés à gauche. L'onglet des détails de l'application vous permet de spécifier les images de l'application pour les tests automatisés. Les tests automatisés évaluent la conformité aux conditions de certification de la taille XAP, de l'iconographie et des captures d'écran de l'application et déterminent les fonctionnalités utilisées par l'application. Les tests manuels fournissent des étapes à suivre afin d'utiliser votre application et de vous assurer qu'elle est conforme à des instructions de certification complémentaires.

Dans cet article, je vais me concentrer sur les tests contrôlés. Pour plus d'informations sur les quatre suites de tests, consultez la page « Windows Phone Marketplace Test Kit » de la bibliothèque MSDN (wpdev.ms/toHcRb).

La suite de tests contrôlés évalue la conformité des applications à des instructions de certification importantes, telles que les suivantes :

• Durée du démarrage
• Utilisation maximale de la mémoire de l'application
• Gestion du bouton Précédent
• Sorties brusques de l'application en raison d'exceptions non gérées

Exécution des tests contrôlés

Pour exécuter les tests contrôlés, vous devez démarrer une version Release de l'application, la déployer sur un téléphone (les tests ne fonctionnent pas sur l'émulateur), puis la parcourir. Les options permettant de configurer ces opérations se trouvent dans la barre d'outils Standard de Visual Studio. Lors de l'exécution des tests contrôlés, l'objectif est de parcourir l'application comme le ferait un utilisateur, de tester tous les chemins de navigation possibles. Pendant que vous effectuez ces navigations, le kit de test contrôle l'application et collecte les données la concernant.

Lorsque vous testez votre application avec des tests contrôlés, vérifiez également son comportement lorsque vous la quittez, puis que vous la réactivez rapidement. Ce processus de fin et de réactivation est qualifié de « tombstoning ». Dans Windows Phone 7.5, votre application passera à l'état dormant automatiquement avant d'être éteinte, puis rallumée. 

Pour obliger votre application à se rallumer immédiatement à des fins de débogage et de test, sélectionnez l'option « Tombstone upon deactivation while debugging » dans l'onglet Debug de Project properties. Ouvrez les propriétés du projet en sélectionnant Properties dans le menu Project. La figure 3 présente cette case à cocher activée. Pour plus d'informations sur le tombstoning, consultez la page « Execution Model Overview for Windows Phone » de la bibliothèque MSDN (wpdev.ms/ExMod).

Figure 3 Sélection de l'option permettant de tester le tombstoning dans les propriétés du projet

Après avoir configuré ces options, je reviens à l'onglet Marketplace Test Kit. J'attache mon appareil enregistré à des fins de développement, puis je clique sur Start Application dans la page Monitored Tests du kit de test.

Lorsque l'application démarre, je passe d'une page à l'autre, je sélectionne des fleurs, je tape pour obtenir le nom et j'appuie sur le bouton Back pour revenir à la page de démarrage de l'application. Je tape sur le bouton Start, puis sur le bouton Back pour obliger l'application à se désactiver, puis à se réactiver.

Lorsque je pense avoir parcouru l'application comme un utilisateur type l'aurait fait, et que j'ai désactivé, puis réactivé l'application, je peux arrêter cette dernière ainsi que la session de test. Afin d'obtenir des résultats optimaux, je quitte l'application en cliquant sur le bouton Précédent depuis la page Start de l'application afin de terminer la session de test. Je pourrais cliquer sur le bouton Close Application de la page Monitored Tests du kit de test, mais afin d'obtenir des résultats de test optimaux, je choisis de quitter l'application à l'aide du bouton Back. Une fois que vous avez quitté l'application, la session de contrôle s'arrête.

Une fois la session de test terminée, la barre d'état des résultats du kit de test m'indique que la suite analyse les résultats. Une fois qu'elle a terminé, le tableau des résultats est mis à jour.

Les résultats obtenus pour mon application, illustrés à la figure 4, me choquent.

Figure 4 Résultats du test indiquant deux échecs

Mon application à échoué à deux des quatre tests de cette suite de tests. Le délai de démarrage est trop lent et il utilise trop de mémoire. Je décide d'approfondir.

Utilisation de l'outil Performance Analysis

En règle générale, pour qu'une application soit populaire sur le marché, elle doit être performante et réactive. Vous devez au minimum examiner les problèmes de performances identifiés par le kit de test et les résoudre. Pour l'un ou l'autre de ces scénarios, vous pouvez utiliser l'outil Windows Phone Performance Analysis , également connu sous le nom de profileur.

Je ferme le kit de test pour l'instant et décide d'utiliser le profileur afin d'examiner les problèmes de délai de démarrage et de mémoire. Il s'agit d'un excellent outil car il indique les problèmes potentiels de mon application, ainsi que les actions susceptibles d'être mises en place pour les corriger.

Le profileur propose deux options :

• Profilage d'exécution : le profileur d'exécution évalue la fréquence des images de votre application, l'utilisation de l'UC et l'utilisation générale de la mémoire. Vous pouvez l'utiliser pour explorer le taux de remplissage et voir combien de visuels sont créés, ainsi que d'autres détails d'exécution susceptibles d'avoir un impact sur les performances de votre application.
• Profilage de mémoire : le profileur de mémoire montre l'utilisation de la mémoire, les chargements d'image et les événements de nettoyage de la mémoire. Vous pouvez utiliser le profileur de mémoire pour rechercher les tendances d'utilisation de la mémoire, ce qui peut indiquer une fuite de mémoire.

Choisissez le profileur d'exécution, sauf si vous savez que le seul problème de votre application est un problème de mémoire. Je sais que j'ai un problème de mémoire, mais je suis intrigué par le problème de délai de démarrage et je décide d'examiner mon application avec le profileur d'exécution en premier lieu.

J'ouvre mon projet d'application dans Visual Studio, puis je vais dans le menu Debug et je choisis Start Windows Phone Performance Analysis. Remarque : si vous utilisez Visual Studio Premium ou Ultimate, ne choisissez pas Start Performance Analysis qui ne s'applique pas aux projets de téléphone.

Si vous ouvrez l'outil Performance Analysis, un nouvel onglet s'ouvre dans Visual Studio avec le nom de la session de profilage en cours. Ce nom inclut le nom du projet, ainsi que les date/heure de la session de profilage, suivies du suffixe .sap utilisé pour les fichiers de résultats du profilage. Ces fichiers sont toujours enregistrés dans le projet. Vous pouvez donc les consulter plusieurs fois. La figure 5 montre l'onglet Performance Analysis avant l'exécution des tests.

Figure 5 L'onglet Performance Analysis avant l'exécution des tests

Dans l'onglet du profileur, je choisis l'option Execution. Afin d'obtenir des résultats optimaux, je m'assure que les options Windows Phone Device et Release sont activées dans les cases d'options de déploiement et de débogage de la barre d'outils Visual Studio et je vérifie que le téléphone est attaché et déverrouillé. Remarque : vous pouvez déployer une application sur l'émulateur lors de l'utilisation du profileur, mais il est possible que les résultats ne soient pas représentatifs des performances sur un appareil.

Je clique sur Launch Application pour démarrer la session de profilage. Comme avec le Marketplace Test Kit, j'utilise mon application comme le ferait un utilisateur et je veille à désactiver, puis réactiver l'application au moins une fois. Je quitte l'application avec le bouton Back, qui est la méthode à privilégier pour obtenir les résultats les plus précis, bien que vous puissiez également terminer la session de profilage à l'aide de l'option Stop Profiling de l'outil Performance Analysis. Le profileur passe du temps à analyser les résultats et les affiche sur la page dans un graphique (illustré à la figure 6). Mes résultats sont très intéressants.

Figure 6 Résultats d'un test d'analyse des performances

La partie verte correspondant à la représentation de l'utilisation de l'UC indique des mises à jour d'écran et des entrées tactiles. Je vois une utilisation de l'UC élevée au départ, ce qui n'est pas surprenant si l'on considère la lenteur du délai de démarrage. Je vois également de grands pics dans l'utilisation de l'UC en relation avec des images chargées, ainsi qu'une utilisation de la mémoire qui grimpe de plus en plus haut. La simple consultation de ces résultats, sans autre examen approfondi, m'indique que le problème d'utilisation de la mémoire est probablement lié à la façon dont je gère les images dans mon application. Bien que la mémoire utilisée par mon application soit libérée lorsque je quitte celle-ci, je suis préoccupé par le fait que mon application risque de bloquer un téléphone si elle est exécutée pendant une durée supérieure aux quelques secondes passées à la tester, comme semble l'indiquer ce graphique.

Maintenant, j'exécute à nouveau l'outil d'analyse des performances en sélectionnant l'option de mémoire et cela confirme mon problème d'utilisation croissante de la mémoire.

Recherche et résolution du problème

Pour rechercher les problèmes à l'aide de l'outil de profilage, sélectionnez les zones de problème dans le graphique, puis consultez les instructions dans la section Observation Summary.

Dans les résultats du profileur d'exécution, je clique et je fais glisser avec la souris pour sélectionner une partie du graphique qui montre un pic d'utilisation de l'UC. La section Performance Warning se met immédiatement à jour et affiche un problème à examiner (voir la figure 7).

Figure 7 Avertissement de performance au sujet de l'utilisation élevée de l'UC sur le thread d'interface utilisateur

D'après la section de synthèse des observations, l'application utilise beaucoup d'UC pour exécuter des fonctions sur le thread d'interface utilisateur. Cela mènerait certainement à un délai de démarrage lent et à de faibles performances en général, mais je ne suis pas sûr que cela contribuerait au problème de mémoire. Le profileur présente l'avantage de donner quelques instructions à suivre, ce que je fais. Je sélectionne CPU Usage, puis Functions. Le tableau de résultats est mis à jour et je trie les résultats avec la colonne Inclusive Samples (%). Les appels de fonction de mon application s'affichent en bleu avec des noms complets qui comprennent l'espace de noms (étrangement, MemoryLeak dans le cas présent), la classe et la méthode. En outre, les appels de fonction sont des liens actifs vers les méthodes de mon code. La figure 8 affiche ces résultats.

Figure 8 L'outil Performance Analysis montre les méthodes susceptibles de provoquer les problèmes

En regardant ces résultats, je peux déduire que les méthodes exécutées lors du chargement de la deuxième page utilisent beaucoup d'UC. Cela ne résoudra probablement pas mon problème de délai de démarrage, mais pourrait sans aucun doute contribuer au problème de mémoire.

Je clique sur le lien pour afficher la méthode FlowerPage.OnNavigatedTo. Cette méthode crée une liste d'objets Flower et charge un bitmap pour chaque fleur à l'aide de la méthode LoadBitmap. Voici un appel type de la méthode LoadBitmap :

bitmap = LoadBitmap("/MemoryLeak;component/Images/tulip.jpg");

Et la méthode LoadBitmap qui charge la ressource :

private BitmapImage LoadBitmap(string urlString)
{
  var streaminfo = App.GetResourceStream(new Uri(urlString, UriKind.Relative)); 
  BitmapImage bitmap = new BitmapImage();
  bitmap.SetSource(streaminfo.Stream);
  return bitmap;
}

Lorsqu'un utilisateur accède à la page, j'extrais le nom de la fleur sur laquelle il a cliqué sur la page principale depuis l'URI de navigation et je charge la même image de fleur dans la FlowerPage.

Il est évident que le chargement des images entraîne un problème de mémoire, mais je ne suis pas sûr de ce que je dois faire maintenant.

Si la section de synthèse des observations ne vous donne pas suffisamment d'informations pour résoudre les problèmes de performances de votre application, cherchez des conseils en matière de performances sur MSDN et le Web. Voici quelques ressources très utiles :

• « Performance Considerations in Applications for Windows Phone » (dans la section « Media ») (wpdev.ms/utCq6h)
• « Performance Techniques for Windows Phone » (wpdev.ms/perfTech)
• Blog de l'équipe Silverlight pour les performances Windows Phone (wpdev.ms/slmperf)
• Vidéo sur l'analyse et l'amélioration des performances d'une application Windows Phone (MIX11) (wpdev.ms/mixwpperf)
• Leçons avancées : vidéo sur les meilleurs conseils en matière de création d'une application Windows Phone réussie (MIX11) (wpdev.ms/mixwptoptips)

Je commence à faire des recherches sur les performances et à charger des ressources sur des applications téléphoniques, et je découvre quelque chose d'important. D'après la section multimédia de l'article « Performance Considerations in Applications for Windows Phone » de la bibliothèque MSDN, je dois spécifier mes fichiers d'images comme contenu plutôt que comme ressources car le téléphone est optimisé pour utiliser des fichiers. Lorsqu'un fichier multimédia est compilé comme ressource, le contenu est copié dans un fichier avant d'être utilisé, ce qui réduit les performances.

Je remplace l'action de génération des fichiers d'images par le contenu et j'apporte une légère modification au code pour qu'il s'adapte à ce changement.

Dans la méthode LoadBitmap, je spécifie une UriSource pour BitmapImage au lieu d'appeler SetSource :

private BitmapImage LoadBitmap(string urlString)
{
  BitmapImage bitmap = new BitmapImage();
  bitmap.UriSource = new Uri(urlString, UriKind.Relative);
  return bitmap;
}

Et lorsque j'appelle LoadBitmap, je passe l'URL relative à chaque bitmap :

bitmap = LoadBitmap("/Images/tulip.jpg");

Nouvelle exécution du kit de test et de l'analyse des performances

Une fois que vous pensez avoir résolu les problèmes soulevés dans le Marketplace Test Kit et l'outil Performance Analysis, vous pouvez exécuter ces outils à nouveau.

Je recompile mon application et j'exécute à nouveau le Marketplace Test Kit. Je n'arrive pas à croire la différence de résultats (voir la figure 9). L'application réussit maintenant les quatre tests. Le délai de démarrage n'est pas exceptionnel, mais atteint au moins les conditions requises.

Figure 9 La modification de la gestion des images entraîne la réussite des quatre tests de préparation au lancement sur le marché

En dernier lieu, je lance le profileur d'exécution une dernière fois. Je vois une grande différence dans les résultats (voir la figure 10).

Figure 10 Les modifications apportées à la gestion des images entraînent une amélioration de l'analyse des performances de l'UC et de la mémoire

Maintenant, au lieu d'avoir de grands pics d'utilisation de l'UC et des images chargées encore et encore à mesure que l'utilisateur parcourt les pages, les images sont chargées une fois, lors du démarrage de l'application. Ce graphique m'indique également que l'utilisation de la mémoire par mon application reste constante et relativement faible comparée à la version précédente de mon application. Je sélectionne ensuite certains des pics d'UC les plus petits et je vois les résultats illustrés à la figure 11.

Figure 11 L'examen d'un pic d'UC n'affiche aucun avertissement de performance

Je suis soulagé de voir que le profileur ne constate aucun problème de performances et j'ai l'intention de soumettre mon application sur le marché. J'ai suis confiant et je pense qu'elle sera acceptée, en sachant que je peux continuer à l'améliorer et à soumettre des mises à jour si je le souhaite.

Suivez ce modèle

Dans cet article, j'ai décrit comment identifier et résoudre les problèmes d'un exemple d'application Windows Phone à l'aide du Marketplace Test Kit et de l'outil Performance Analysis. Ces outils sont intégrés à Visual Studio et sont installés dans le cadre du Windows Phone SDK. Le Marketplace Test Kit vous permet de déterminer si votre application répond aux conditions de certification. L'outil Performance Analysis vous permet d'identifier les problèmes de performances de la mémoire et de l'UC. Avant de lancer vos applications sur le marché, je vous recommande de suivre un modèle similaire à celui présenté dans cet article :

1. Utilisez les outils que j'ai présentés, dont toutes les suites de test du Marketplace Test Kit.
2. Identifiez et résolvez les problèmes potentiels.
3. Testez à nouveau pour vérifier si les problèmes sont résolus.

Si vous suivez ce modèle, vous détecterez les problèmes plus tôt et créerez de meilleures applications plus rapidement. En outre, cela vous permettra de vous assurer que vos applications seront acceptées sur le marché dès la première tentative.

Cheryl Simmons est rédactrice en programmation senior dans l'équipe de contenu destiné aux développeurs Windows chez Microsoft

Merci aux experts techniques suivants d'avoir relu cet article : Pratap Lakshman, Raghuram Lanka et Nitin Madnikar