Codegenerierung auf Mobilgeräten wechselt von Mono zu CoreCLR

.NET 11 mobile Apps können coreCLR JIT, ReadyToRun (R2R) und den CoreCLR-Interpreter verwenden. Die verfügbaren Modi hängen weiterhin von der Ziel- und Buildkonfiguration ab.

Eingeführt in Version

.NET 11

Bisheriges Verhalten

.NET 10 mobile Apps können mono JIT, Mono AOT, Mono AOT mit LLVM und den Mono-Interpreter verwenden. Die verfügbaren Modi hingen von der Ziel- und Buildkonfiguration ab.

Einige Apps verwendeten den Mono-Interpreter nur für eine ausgewählte Liste von Assemblys. Dies half diesen Apps, ein ausgewogenes Verhältnis zwischen Kompatibilität und Geschwindigkeit zu finden.

Neues Verhalten

.NET 11 mobile Apps können coreCLR JIT, ReadyToRun (R2R) und den CoreCLR-Interpreter verwenden. Die verfügbaren Modi hängen weiterhin von der Ziel- und Buildkonfiguration ab.

R2R ist eine AOT-Technologie, aber es ist kein neuer Name für Mono AOT. Sie behält IL- und Metadaten in der App bei und kann den JIT oder Interpreter verwenden, wenn die Zielplattform es zulässt.

Android Release-Builds verwenden CoreCLR R2R, um einen Teil der App vorzukompilieren und den JIT für den Rest zu verwenden. MauiEnableFullReadyToRun=true wendet R2R auf die gesamte App an. Die App kann den JIT zur Laufzeit weiterhin für dynamisches Verhalten verwenden. Debugbuilds verwenden weniger R2R, sodass der größte Teil der App mit dem JIT ausgeführt wird.

Apple-Release-Builds kompilieren die gesamte App mit R2R vorab und können den Interpreter zur Laufzeit für dynamisches Verhalten verwenden. Debugbuilds verwenden weniger R2R, sodass der größte Teil der App mit dem Interpreter ausgeführt wird.

NativeAOT ist eine weitere Codegenerierungsoption auf mobilen Plattformen. Es unterscheidet sich von Mono AOT und CoreCLR R2R. Android NativeAOT ist experimentell in .NET 11.

Art der einschneidenden Änderung

Diese Änderung kann sich auf die Quellkompatibilität und das Verhalten auswirken.

Grund für die Änderung

CoreCLR verwendet ein eigenes Compiler- und Ausführungsmodell. Mono AOT-Einstellungen beeinflussen CoreCLR R2R nicht.

  • Verwenden Sie die R2R-Standardwerte aus der mobilen Workload.
  • Versuchen Sie nicht, jede Mono AOT-Einstellung in eine R2R-Einstellung zu übersetzen.
  • Verwenden Sie MauiEnableFullReadyToRun erst nach Messung der App.
  • Messen Sie Startzeit, Geschwindigkeit, Arbeitsspeichernutzung und App-Größe.
  • Wenn Sie NativeAOT in Betracht ziehen, lesen Sie den .NET MAUI Native AOT-Bereitstellungsleitfaden, da es sich um ein separates Bereitstellungsmodell mit unterschiedlichen Einschränkungen handelt. Behandeln Sie Android NativeAOT als experimentell in .NET 11.

Betroffene APIs

Es werden keine verwalteten APIs entfernt. Die folgenden MSBuild-Eigenschaften und -Elemente stellen ihren Mono-Codegenerierungseffekt nicht mehr bereit, wenn die App CoreCLR verwendet:

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

Diese Einstellungen konfigurieren die Mono-AOT-Kompilierung, LLVM, die Interpreterauswahl, AOT-Eingaben oder generierte Marshallmethoden. Sie konfigurieren die CoreCLR ReadyToRun-Pipeline nicht. Einzelheiten zum Migrations- und Builddiagnoseverhalten finden Sie unter Mono-Projekteigenschaften konfigurieren keine mobilen Apps mehr.

  • Zuletzt aktualisiert um