La génération de code sur mobile passe de Mono à CoreCLR

.NET 11 applications mobiles peuvent utiliser le JIT CoreCLR, ReadyToRun (R2R) et l’interpréteur CoreCLR. Les modes disponibles dépendent toujours de la cible et de la configuration de build.

Version introduite

.NET 11

Comportement antérieur

.NET 10 applications mobiles peuvent utiliser mono JIT, Mono AOT, Mono AOT avec LLVM et l’interpréteur Mono. Les modes disponibles dépendaient de la cible et de la configuration de build.

Certaines applications utilisaient l’interpréteur Mono uniquement pour une liste sélectionnée d’assemblys. Cela a permis à ces applications d’équilibrer la compatibilité et la vitesse.

Nouveau comportement

.NET 11 applications mobiles peuvent utiliser le JIT CoreCLR, ReadyToRun (R2R) et l’interpréteur CoreCLR. Les modes disponibles dépendent toujours de la configuration cible et de compilation.

R2R est une technologie AOT, mais ce n’est pas un nouveau nom pour Mono AOT. Il conserve l’IL et les métadonnées dans l’application et peut utiliser le JIT ou l’interpréteur lorsque la cible l’autorise.

Les builds Android Release utilisent CoreCLR R2R pour précompiler une partie de l’application et utiliser le JIT pour le reste. MauiEnableFullReadyToRun=true applique R2R à l’ensemble de l’application. L’application peut toujours utiliser le JIT au moment de l’exécution pour le comportement dynamique. Les builds de débogage utilisent moins de R2R. La majeure partie de l’application s’exécute donc avec le JIT.

Les builds Apple Release précompilent l’ensemble de l’application avec R2R et peuvent utiliser l’interpréteur au moment de l’exécution pour un comportement dynamique. Les builds de débogage utilisent moins de R2R. La plupart de l’application s’exécute donc avec l’interpréteur.

NativeAOT est une autre option de génération de code sur les plateformes mobiles. Il est différent de Mono AOT et CoreCLR R2R. Android NativeAOT est expérimental dans .NET 11.

Type de changement avec rupture de compatibilité

Cette modification peut affecter la compatibilité source et le comportement.

Raison du changement

CoreCLR utilise son propre compilateur et son propre modèle d’exécution. Les paramètres Mono AOT ne contrôlent pas CoreCLR R2R.

Action recommandée

• Utilisez les valeurs par défaut R2R de la charge de travail mobile.
• N’essayez pas de convertir chaque paramètre Mono AOT en paramètre R2R.
• Utilisez MauiEnableFullReadyToRun uniquement après avoir évalué les performances de l’application.
• Mesurez le temps de démarrage, la vitesse, l’utilisation de la mémoire et la taille de l’application.
• Si vous envisagez NativeAOT, passez en revue les instructions de déploiement .NET MAUI Native AOT, car il s’agit d’un modèle de déploiement distinct avec différentes restrictions. Traitez Android NativeAOT comme expérimental dans .NET 11.

API affectées

Aucune API managée n’est supprimée. Les propriétés et éléments MSBuild suivants ne fournissent plus leur effet de génération de code Mono lorsque l’application utilise CoreCLR :

• Android :RunAOTCompilation, AotAssemblies, AndroidEnableProfiledAot, AndroidAotMode, AndroidUseInterpreter, AndroidExtraAotOptions, AndroidEnableMarshalMethods, AndroidAotAdditionalArguments, @(AndroidAotProfile), AndroidAotEnableLazyLoad, UseInterpreter et EnableLLVM.
• iOS, tvOS et Mac Catalyst :UseInterpreter, MtouchInterpreter, MtouchUseLlvm, MtouchFloat32, MonoUseCompressedInterfaceBitmap, RunAotCompilation, AotAssemblies et AotCompileMaxDegreeOfParallelism.

Ces paramètres configurent la compilation Mono AOT, LLVM, la sélection de l’interpréteur, les entrées AOT ou les méthodes de marshaling générées. Ils ne configurent pas le pipeline CoreCLR ReadyToRun. Pour connaître le comportement détaillé de migration et de diagnostic de build, consultez Les propriétés du projet Mono ne configurent plus les applications mobiles.