Dot.Blog

C#, XAML, WinUI, WPF, Android, MAUI, IoT, IA, ChatGPT, Prompt Engineering

Xamarin.Forms, les astuces à connaître avec l’émulateur

Pour développer des apps les émulateurs sont une aide précieuse mais il y a quelques astuces à connaître…

Emuler n’est pas exécuter

La première des choses à bien comprendre c’est qu’aussi pratique que soit un émulateur cela n’est jamais équivalent à une exécution sur une vraie machine. C’est pratique, on peut tester plein de configurations différentes (taille d’écran, version de l’OS, type de device…) mais gardez vous de croire que cela vous vite de tester en réel.

Emulateur Microsoft Android

Depuis un moment maintenant Microsoft offre un émulateur Android intégré à l’installation de Visual Studio. Mais cette dernière, au moins pour VS2017, installe par défaut l’émulateur Android et HAXM l’accélérateur Intel pour ce dernier (Hardware Accelerated Execution Manager). Erreur fatale, toute machine de développement supportant VS 2017 est au minimum un Windows 10 Pro ou Entreprise qui intègre donc Hyper-V. Et l’émulateur Android de Google tourne très lentement dans cette configuration car HAXM est incompatible avec Hyper-V…

La première chose à faire donc lors de l’installation de VS2017 et après avoir sélectionné les grands ‘blocs’ de fonctionnalités est d’aller dans les composants individuels et de décocher l’émulateur Google et HAXM pour préférer l’émulateur Microsoft.

Ce dernier a été conçu pour tourner sous Hyper-V, vite et bien, et s’avère être la meilleure solution sous Windows 10 / VS2017.

Si vous faites tourner Visual Studio lui-même dans une machine virtuelle (VM) vous pouvez tout de même faire marcher l’émulateur car les VM imbriquées de la virtualisation Windows Server est possible à partir de Windows 10 Anniversary Update. Mais je ne vous conseille pas cette stratégie de développement à moins qu’elle ne se justifie vraiment. Si vous voulez en savoir plus sur ce “montage” de VM imbriquées voici un article Microsoft à lire : https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/user-guide/nested-virtualization.

Je ne parle pas ici du cas de iOS car il n’existe pas d’émulateur iOS. Apple n’en propose pas qui tourne sur PC. C’est comme ça, c’est Apple. Donc il faut casquer pour un Mac. Microsoft essaye vraiment de vous aider pour rendre le truc moins pénible notamment grâce à un pseudo-émulateur qui déporte l’image de l’émulateur qui tourne sur le Mac vers votre PC. On peut tout faire depuis le PC mais il faut un Mac sur le réseau pour faire tourner l’émulateur. C’est pénible et couteux, mais c’est ça développer pour Apple.

Hyper-V quelles conséquences ?

La première chose à dire est plus un constat qu’une conséquence : vous n’avez pas vraiment le choix… faire tourner l’émulateur Google est super lent et comme Windows embarque Hyper-V de base et que HAXM n’est pas compatible… Certes certaines versions de Windows n’ont pas Hyper-V (avant Windows 8) mais ces version là ne permettent pas de tout développer il faut un Windows 10 minimum. On peut aussi choisir de ne pas installer Hyper-V mais dans ce cas on perd des fonctionnalités. Donc la boucle est bouclée d’autant qu’en plus le Windows en question doit être un Pro ou Enterprise. Donc il faut faire avec Hyper-V. Mais ce n’est pas une mauvaise chose, il est bien préférable de disposer d’une virtualisation native de l’OS qu’un émulateur “étranger” qui aura peut-être de ci de là du mal à tourner correctement.

Les vraies conséquences sont celles qui découlent de l’utilisation de Hyper-V qui comme tout émulateur n’est pas équivalent à une device réelle. Hyper-V a ses propres particularités qui vont jouer sur l’App tournant dans l’émulateur Android.

Il va donc falloir faire attention à trois ou quatre choses importantes :

  • La gestion de la mémoire dynamique
  • La localisation des fichiers de stockage
  • Le Switch virtuel
  • Le déploiement des changements dans le code

Mémoire dynamique & mémoire fixe

Hyper-V propose une gestion dynamique de la mémoire pour tous les OS émulés. Cela est très pratique puisqu’on évite un plantage en plein test si on a besoin d’un petit rab de Ram ! Mais si vous voulez tester vos Apps dans des conditions à peu près réalistes vous devrez faire attention à désactiver cette facilité. Sinon vous risquez de croire que votre App tourne à merveille alors qu’elle plantera le premier smartphone venu s’il n’a pas des Go de Ram…

Ouvrez le gestionnaire d’Hyper-V, sélectionnez une machine virtuelle Android puis éditez ses propriétés. Dans la page Mémoire voici ce qu’on trouve :

image

Rappel : sur Dot.Blog un clic sur une image affiche son équivalent à 100% ce qui est parfois plus lisible (ce qui est le cas ici !).

Sur la capture plus haut on s’aperçoit que la mémoire dynamique est désactivée et que la mémoire disponible pour la machine émulée  est de 2 Go. Cela peut être bon mais peut-être pas… si dans vos spécifications vous devez tourner sur 1Go seulement voire 512 Mo pensez à faire le réglage nécessaire sinon vous risquez de grosses désillusions !

Localisation des fichiers images

Les fichiers images pour Hyper-V doivent être modifiables (par exemple installation d’une app, modification des paramètres de l’OS qui doivent être persistés, etc). Or, Windows 10 bloque les écritures dans les répertoires protégés pour les applications sur C. De fait les images Hyper-V sont placées dans le répertoire utilisateur car ce dernier peut être écrit par une application.

La plupart des machines de développement disposent de plusieurs disques et le disque C est réservé à l’OS. Les applications développées se trouvent en général sur le disque D ou autre. Mais lorsqu’on dispose d’un laptop ou de toute machine à un seul disque dur tout va se passer sur C (même s’il est partitionné en C/D par exemple). C’est le même disque dur qui supporte touts les mouvements.

Et cette situation peut être pénalisante en donnant des performances disques inférieures à celle d’un vrai smartphone… Donc avant de vous acharner à optimiser plus encore votre code même si cela doit être fait commencez par vous demandez si votre configuration n’est pas trop lente notamment en raison de l’utilisation d’un seul disque dur. Et pour cela, une fois encore, testez toujours en cours de développement sur toutes les devices qui vous passeront devant le nez !

Mais une fois le problème constaté que faire ?

Retour aux paramètres de la machine émulée cette fois-ci à la rubrique Contrôleur IDE, il peut y en avoir plusieurs :

image

Sur cette capture on voit l’emplacement de la zone de stockage simulant le contrôleur IDE 0 possédant un seul disque dur (il peut y en avoir plusieurs par contrôleur même si cela n’est pas tout à fait conseillé vu que dans la réalité les devices mobiles n’ont que rarement de telles configurations).

Si vous disposez de plusieurs disques dur déplacez les fichiers de stockage sur un disque différent de celui des images de l’émulateur et différent du disque C, et si possible différent de celui de l’app développée sous Visual Studio. En gros si vous avez un disque C pour l’OS, un disque D pour le développement et un disque E pour le stockage divers vous devriez avoir les images Hyper-V sur C, votre app en développement sur D et les stockages de l’émulateur sur E. En insistant bien sur le fait que ces trois disques sont de vrais disques et par un partitionnement d’un seul disque physique.

Si vous ne disposez que d’un seul disque dur… ce n’est pas cool. Mais si vous avez la possibilité d’insérer une carte mémoire ou une clé USB rapide, tentez l’expérience en plaçant les fichiers de stockage à cet endroit. Vous constaterez peut-être une amélioration de la vitesse des accès disque dans votre App ce qui se rapprochera plus d’une situation réelle (à comparer avec une vraie device de toute façon).

Le commutateur de réseau virtuel

Comme tout le reste le réseau qui est vu par la machine virtuelle est lui-même virtuel… Encore faut-il qu’il finisse par correspondre avec un vrai réseau quelque part… Que cela soit un réseau Wifi ou câblé, vos devices auront certainement besoin d’une connexion internet valide. Il faut donc veiller à ce que la machine virtuelle soit bien configurée. Dans les paramètres de celle-ci on trouve une catégorie pour les cartes réseau qui porte le nom du premier réseau créé (ce qui est idiot, on devrait avoir une catégorie Réseau avec en dessous les réseaux créés, mais bon c’est ainsi).

image

Pour compliquer un peu Hyper-V utilise trois types de connexion :

  • Les connexions externes qui créent un pont avec le véritable réseau du PC
  • Les connexions internes qui permettent à la VM de discuter avec le PC mais sans avoir accès à “l’extérieur” donc pas d’internet
  • Les connexions privées qui créent une sorte de canal de communication interne à la machine émulée sans pouvoir donner accès ni à l’hôte ni à internet

En général une device doit posséder une connexion internet et c’est donc une connexion du premier type qu’on choisira. Mais si vous voulez tester une machine sans réseau assurez-vous de bien l’avoir paramétré.

Un autre paramètre à prendre en compte est la vitesse maximale du réseau. Aujourd’hui la plupart des smartphones ont un accès 4G plusieurs fois plus rapide que l’internet fixe à la maison, du coup rien à faire, votre PC sera plus lent que la réalité d’une device… En revanche si vous disposez d’un connexion vibre optique de bonne qualité avec un gros débit il n’est pas idiot de poser une limite dans la VM afin de ne pas être trompé par votre réseau fixe de luxe… On peut aussi vouloir poser des limites à la bande passante pour tester son App dans des situations non favorables comme de la 3G ou moins bien. Si on doit avoir de bonnes performances même dans ces cas là il est donc préférable de configurer la VM pour éviter les mauvaises surprises plus tard.

Le déploiement des modifications dans le code

Visual Studio est un partenaire sympa pour le développeur il fait plein de choses et essaye d’accélérer tout ce qu’il peut. Mais parfois il pèche par excès. Il peut arriver que de toutes petites modifications de code ne soient pas redéployées sur la VM.

Il ne me semble pas que cela soit très fréquent mais cela peut arriver, en tout cas c’est arrivé (toujours le côté un peu mystique du développement !).

Si vous avez un doute n’hésitez pas à :

  • Supprimer l’App sur la VM
  • Nettoyer la solution
  • Supprimer les répertoires bin et obj

Vous devriez être sûr que la version déployée est bien le dernier build.

Comme le doute est une chose terrible je vous conseille de faire ce petit ménage une fois de temps en temps mais systématiquement. Et surtout le jour où vous tombez sur bogue bizarre que vous pensez corriger dans le code mais sans effet sur l’App en test dans l’émulateur. Même si cela relève un peu de la magie, ce que j’adore en spectacle mais que je déteste dans mon boulot, c’est une précaution qui vaut la peine d’être essayée…

Conclusion

Les émulateurs en général ne doivent pas être confondus avec de vraies machines. Rien ne vaut un test sur une vraie device il faut le rappeler sans cesse. Ne restez jamais longtemps sur un projet sans un test réel. Si jamais l’émulateur vous a trompé sur un comportement n’attendez pas le déploiement sur une machine réelle en fin de projet pour vous en rendre compte !

En dehors de ce salutaire rappel chaque émulateur a ses spécificités qui ont un impact sur les Apps testées. Hyper-V n’y échappe pas et connaître ces petites particularités peut aider…

Stay Tuned !