Pourquoi adopter le compilateur .Net Native pour la plateforme Universelle Windows ?
Pourquoi adopter le compilateur .Net Native pour la plateforme Universelle Windows ?
Pour gagner en performance et bien plus encore, estime Microsoft
Depuis l’introduction de la compilation .NET Native dans Visual Studio 2013 update 2, les applications ont gagné en performance. Côté utilisateurs, les logiciels s’exécutent plus rapidement avec un temps de démarrage réduit. Par ailleurs, l’usage de la mémoire par ces applications a été réduit.
Tous ces avantages dénotent de la nécessité d’utiliser la compilation .Net Native qui compile le code source des applications en code natif lors de la génération du package tandis que le compilateur à la volée lui compile le code intermédiaire en code natif avant l’exécution d’une méthode par exemple.
Vu les avantages du premier, Microsoft a fait le choix du compilateur .Net Native et recommande celui-ci pour la compilation des applications destinées à tourner sur sa Plateforme Universelle Windows.
Comme avantages résultant de l’adoption de ce compilateur pour les applications Windows Universelles, Microsoft indique que les applications gagnent en performance à cause du temps de démarrage qui est réduit. Pour vous faire également une d’idée de ces gains, Microsoft avance que ces performances sont de l’ordre de celles enregistrées à travers les applications conçues avec C++.
En outre, avec ce compilateur, les applications universelles consomment moins d’énergie lorsqu’elles sont compilées nativement. La seule contrainte observée est que le compilateur met plus de temps à générer les binaires par rapport au compilateur classique. Si le temps de compilation n’est pas un souci pour vous, alors .Net Native sera votre mode de compilation privilégiée.
En plus des gains de performance et l’usage réduit de la mémoire, il faut lui ajouter également, un délestage des bibliothèques du framework après compilation des binaires. Vous pouvez utiliser vos binaires sans vous soucier de l’importation des bibliothèques associées. Seul élément requis pour le fonctionnement de ces applications, c’est le runtime .Net Native. Microsoft précise que le runtime sur le terminal sera toujours compatible avec le package de l’application.
En outre, lorsque vous aurez besoin de créer le package de votre application dans Visual Studio, vous constaterez que la configuration AnyCPU permettant de cibler plusieurs architectures a disparu. Pour créer les différents packages des applications, vous n’aurez besoin que de sélectionner les trois plateformes x86, x64 et ARM et de vous laisser guider par Visual Studio.
Enfin en dernier point, il faut savoir que le compilateur .Net Native est également utilisé sur le Cloud. En effet, lorsque vous créez vos applications, deux packages sont générés. Un avec l’extension .appx et un autre avec l’extension .appxuload. Le premier est utilisé pour des tests en local tandis que le second est chargé en ligne pour être hébergé sur le store.
Et compte tenu du fait que .Net Native est également hébergé en ligne, c’est lui qui va compiler ce fichier pour vous directement sur le Cloud. Il ne faut donc pas uploader le binaire .app sur le store, mais plutôt celui le fichier avec l’extension .Appxuload.
De même, le compilateur en ligne prendra en charge le nommage des versions. Toutefois, une certaine marge est donnée au développeur afin qu’il puisse garder le contrôle sur cet aspect. Lors du développement avec Visual Studio, il est donc recommandé de laisser le numéro du package à « 0 » lors de la création du package.
Source : Blog Microsoft
Et vous ?
Que pensez-vous de ce compilateur ?
Répondre avec citation
Envoyé par lunatix
Partager