Środowiska uruchomieniowe i kompilacja w .NET MAUI

Mono

Mono to międzyplatformowe środowisko uruchomieniowe .NET, które historycznie obsługuje aplikacje Xamarin i aplikacje .NET MAUI w systemach Android, iOS i Mac Catalyst. Mono obsługuje kompilację just in time (JIT) i kompilację przed czasem (AOT). Mono to domyślne środowisko uruchomieniowe dla aplikacji MAUI platformy .NET na platformach mobile i Mac Catalyst.

Mono nie jest obsługiwane w przypadku aplikacji .NET MAUI przeznaczonych dla .NET 11 lub nowszych.

W programie .NET MAUI coreCLR jest środowiskiem uruchomieniowym używanym w systemie Windows. W .NET 10 coreCLR jest również dostępna jako opcja eksperymentalna dla systemu Android.

W .NET wersji 11 lub nowszej coreCLR jest domyślnym środowiskiem uruchomieniowym aplikacji .NET MAUI w Windows, Android, iOS i Mac Catalyst. NativeAOT to opcjonalna alternatywa do publikowania dla wszystkich platform docelowych .NET 11. Obsługa nativeAOT jest eksperymentalna w systemie Android.

• Używane przez: CoreCLR w Windows i eksperymentalnie w systemie Android; Mono w kompilacjach debugowania systemu Android
• Zalety: szybkie czasy kompilacji, diagnostyka pełnego środowiska uruchomieniowego i obsługa dynamicznego generowania kodu
• Wady: wolniejsze uruchamianie, ponieważ kod jest kompilowany na urządzeniu w czasie wykonywania

• Używane przez: CoreCLR w systemach Windows i Android
• Zalety: szybkie czasy kompilacji, diagnostyka pełnego środowiska uruchomieniowego i obsługa dynamicznego generowania kodu
• Wady: wolniejsze uruchamianie, gdy kod nie został jeszcze skompilowany przez ReadyToRun

Targety urządzeń Apple CoreCLR nie używają trybu JIT, ponieważ ograniczenia platformy Apple uniemożliwiają dynamiczne generowanie kodu natywnego. Zamiast tego używają interpretera CoreCLR.

Kompilacja Mono AOT (kompilacja wyprzedzająca)

Kompilacja mono AOT wstępnie kompiluje język MSIL w kodzie natywnym w czasie kompilacji przy użyciu kompilatora AOT mono. Jest to domyślny tryb kompilacji w wersji .NET MAUI na iOS, Mac Catalyst i Android.

• Używane przez: środowisko uruchomieniowe Mono w systemach iOS, Mac Catalyst i Android
• Zalety: szybsze uruchamianie niż JIT i wymagane dla platform, które ograniczają generowanie kodu dynamicznego
• Wady: większy rozmiar aplikacji niż w przypadku kompilacji wyłącznie JIT oraz ograniczona obsługa niektórych funkcji dynamicznych

Mono AOT nie jest taki sam jak NativeAOT. Aplikacja mono AOT nadal zawiera środowisko uruchomieniowe Mono i opcjonalnie może używać interpretera Mono dla kodu, który nie został skompilowany przez usługę AOT. NativeAOT kompiluje cały kod z wyprzedzeniem i nie zawiera kompilatora JIT ani interpretera. Mono obsługuje również tryb Pełny AOT, w którym nie jest dostępny interpreter ani tryb JIT. Pełna funkcja AOT jest używana domyślnie w przypadku wersji Mono w systemach iOS i Mac Catalyst.

• Dostępne w: aplikacjach platformy .NET MAUI na iOS i Mac Catalyst po jawnym włączeniu publikowania
• Zalety: mały rozmiar aplikacji, szybkie uruchamianie i pojedynczy natywny plik binarny
• Wady: dłuższe czasy kompilacji, brak dynamicznego generowania kodu i dynamicznego ładowania, a cały kod musi być bezpieczny względem przycinania i kompatybilny z AOT
• Właściwość MSBuild: <PublishAot>true</PublishAot>

• Dostępne w: wszystkie elementy docelowe .NET MAUI, gdy jawnie włączono funkcję publikowania. Obsługa nativeAOT jest eksperymentalna w systemie Android.
• Zalety: mały rozmiar aplikacji, szybkie uruchamianie i pojedynczy natywny plik binarny
• Wady: dłuższe czasy kompilacji, brak dynamicznego generowania kodu i dynamicznego ładowania, a cały kod musi być bezpieczny względem przycinania i kompatybilny z AOT
• Właściwość MSBuild: <PublishAot>true</PublishAot>

NativeAOT to model wdrażania wyłącznie do publikowania. Użyj dotnet publish, aby utworzyć i zweryfikować aplikację NativeAOT. Zwykła kompilacja debugowania nie używa funkcji NativeAOT.

• Używane przez: CoreCLR w systemie Windows oraz kompilacje CoreCLR dla systemu Android, które korzystają z eksperymentalnego środowiska uruchomieniowego
• Zalety: Ulepszony czas uruchamiania przy zachowaniu zgodności JIT
• Wady: większe rozmiary zestawów, ponieważ zestawy zawierają zarówno MSIL, jak i kod macierzysty
• Właściwość MSBuild: <PublishReadyToRun>true</PublishReadyToRun>

Funkcja ReadyToRun jest domyślnie włączona dla aplikacji .NET MAUI w trybie Windows Release i dla aplikacji systemu Android korzystających z trybu CoreCLR (eksperymentalne).Release Obrazy R2R są pakowane wewnątrz .dll plików.

• Używane przez: CoreCLR w Windows, Android, iOS i Mac Catalyst
• Zalety: ulepszony czas uruchamiania przy zachowaniu odpowiedniego zachowania kompilacji środowiska uruchomieniowego
• Wady: Większe rozmiary aplikacji i pobieranych plików

W przypadku aplikacji na Androida funkcja ReadyToRun jest domyślnie włączona w konfiguracji Release. Wartością domyślną jest częściowa funkcja ReadyToRun. Tryb Full ReadyToRun można włączyć za pomocą polecenia MauiEnableFullReadyToRun=true. Może ona poprawić wydajność uruchamiania lub środowiska uruchomieniowego, ale zwiększa rozmiar pakietu, więc zmierz wynik aplikacji.

Funkcja ReadyToRun, w tym złożona funkcja ReadyToRun, wymaga PublishTrimmed=true w systemie Android. Jeśli funkcja ReadyToRun jest włączona, ale PublishTrimmed nie jest true, zestaw SDK systemu Android wyłącza zarówno XA0119, jak i PublishReadyToRun, oraz zgłasza ostrzeżenie PublishReadyToRunComposite. Pozostaw włączone przycinanie, aby użyć częściowego lub pełnego ReadyToRun.

W przypadku aplikacji dla systemów iOS i Mac Catalyst w kompilacjach Debug stosuje się częściowy złożony model ReadyToRun, a w kompilacjach Release — pełny złożony model ReadyToRun. Interpreter CoreCLR jest zawsze włączony i wykonuje kod, który nie jest wstępnie skompilowany, ponieważ te platformy nie zezwalają na kompilację JIT.

Optymalizacja sterowana profilem (PGO)

Optymalizacja sterowana profilem (PGO) używa danych profilowania w celu kierowania kompilatorem w celu tworzenia bardziej wydajnego kodu. W kontekście .NET MAUI istnieją dwie formy PGO:

• Statyczny protokół PGO z profilami MIBC: .NET MAUI dostarcza .mibc pliki profilów zawierające dane dotyczące metod często wywoływanych podczas typowego uruchamiania i użycia aplikacji. Gdy kompilacja ReadyToRun jest włączona, kompilator R2R używa tych profilów, aby zdecydować, które metody mają być wstępnie skompilowane.
• Dynamiczne PGO: w CoreCLR kompilator JIT może zbierać dane profilowania w czasie wykonywania i wykorzystywać je, gdy metody są ponownie kompilowane z większą liczbą optymalizacji.

Aby uzyskać więcej informacji, zobacz Optymalizacja sterowana profilami i Kompilacja ReadyToRun (gotowa do uruchomienia).

Interpretator mono

Interpreter Mono umożliwia aplikacji interpretowanie MSIL w czasie wykonywania bez dynamicznego generowania kodu natywnego. Jest on używany razem z usługą Mono AOT na platformach, które nie zezwalają na kompilację JIT, taką jak urządzenia z systemem iOS.

Interpreter Mono umożliwia również szybkie przeładowanie .NET dla aplikacji działających w środowisku uruchomieniowym Mono. UseInterpreter jest domyślnie ustawiona na true w trybie Debug na Androidzie, iOS i Mac Catalyst.

• Używane przez: środowisko uruchomieniowe Mono
• Zalety: obsługuje funkcje dynamiczne, których usługa AOT nie może obsłużyć, włącza .NET Przeładowywanie na gorąco i może zmniejszyć rozmiar aplikacji
• Wady: Interpretowany kod działa wolniej niż skompilowany kod
• Właściwość MSBuild: <UseInterpreter>true</UseInterpreter>

Aby uzyskać więcej informacji, zobacz Interpretery w systemach iOS i Mac Catalyst.

Interpreter CoreCLR

CoreCLR zawiera interpreter w systemach iOS i Mac Catalyst. Interpreter jest zawsze włączony i wykonuje kod, który nie jest wstępnie skompilowany, ponieważ te platformy nie zezwalają na kompilację JIT. To zachowanie jest częścią środowiska uruchomieniowego i nie wymaga właściwości interpretera MSBuild.

Obsługa kodu dynamicznego na platformach firmy Apple

W .NET 11+ aplikacje CoreCLR w systemach iOS, tvOS i Mac Catalyst domyślnie używają DynamicCodeSupport=true. IsDynamicCodeSupported zgłasza true z tą wartością domyślną. Interpreter CoreCLR może wykonywać dynamicznie generowany kod MSIL bez kompilatora JIT. Dzięki temu biblioteki, takie jak Entity Framework Core, mogą tworzyć modele w czasie wykonywania, zamiast niepoprawnie wybierać ścieżkę kodu NativeAOT.

Pozostawienie włączonej obsługi kodu dynamicznego powoduje zachowanie System.Reflection.Emit w przyciętych danych wyjściowych i może zwiększyć rozmiar aplikacji. Wyłącz ją tylko wtedy, gdy aplikacja i jej zależności nie wymagają kodu dynamicznego:

<PropertyGroup Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'ios' Or $([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'tvos' Or $([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'maccatalyst'">
    <DynamicCodeSupport>false</DynamicCodeSupport>
</PropertyGroup>

To ustawienie zmienia wykrywanie możliwości i umożliwia usunięcie obsługi kodu dynamicznego podczas przycinania. To nie eliminuje konieczności zapewnienia zgodności zależności z przycinaniem. NativeAOT nadal domyślnie używa DynamicCodeSupport=false i nie obsługuje kodu dynamicznego.

W poniższej tabeli przedstawiono podsumowanie strategii środowiska uruchomieniowego i kompilacji .NET MAUI używanych na każdej platformie w zależności od konfiguracji kompilacji.

W poniższej tabeli przedstawiono podsumowanie strategii środowiska uruchomieniowego i kompilacji używanej przez .NET MAUI na każdej platformie:

W poniższej tabeli porównaliśmy strategie kompilacji dostępne dla aplikacji .NET MAUI:

Typowa wydajność

Poniższe testy porównawcze pochodzą z dotnet new maui aplikacji i są zależne od sprzętu. Ilustrują względne różnice w czasie wykonania i nie stanowią bezwzględnych gwarancji.

Czas uruchamiania (milisekundy):

Rozmiar aplikacji w systemie iOS (MB):

W poniższej tabeli porównaliśmy strategie kompilacji dostępne dla aplikacji .NET MAUI przeznaczonych dla .NET 11:

Począwszy od .NET 10, możesz wyrazić zgodę na uruchamianie aplikacji systemu Android w coreCLR zamiast Mono.

<PropertyGroup Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'android'">
    <UseMonoRuntime>false</UseMonoRuntime>
</PropertyGroup>

W programie .NET 10 coreCLR w systemie Android jest funkcją eksperymentalną i nie jest przeznaczona do użytku produkcyjnego.

W .NET 11+, CoreCLR jest domyślnym środowiskiem uruchomieniowym dla aplikacji Android, iOS i Mac Catalyst. NativeAOT to opcjonalna alternatywa, która nie korzysta z CoreCLR i ma charakter eksperymentalny na Androidzie. Nie ustawiaj UseMonoRuntime=true; Mono nie jest obsługiwane w przypadku .NET 11 lub nowszych, a ustawienie właściwości powoduje błąd kompilacji.

Zawartość pakietu APK różni się w zależności od tego, którego środowiska uruchomieniowego i strategii kompilacji używa aplikacja:

Mono:

• classes.dex — Kod Java/Kotlin
• lib/arm64-v8a/libmonosgen-2.0.so — Środowisko uruchomieniowe mono
• lib/arm64-v8a/libmonodroid.so — klej uruchamiania środowiska uruchomieniowego specyficznego dla systemu Android
• lib/arm64-v8a/libassemblies.arm64-v8a.blob.so — Skompresowane, zapakowane zestawy MSIL
• lib/arm64-v8a/libaot-*.dll.so — Natywne obrazy AOT Mono w kompilacjach produkcyjnych

CoreCLR:

• classes.dex — Kod Java/Kotlin
• lib/arm64-v8a/libcoreclr.so — Środowisko uruchomieniowe CoreCLR
• lib/arm64-v8a/libclrjit.so — Kompilator JIT coreCLR
• lib/arm64-v8a/libmonodroid.so — klej uruchamiania środowiska uruchomieniowego specyficznego dla systemu Android
• lib/arm64-v8a/libassemblies.arm64-v8a.so — Spakowany kod MSIL z obrazami ReadyToRun

Zawartość pliku APK systemu Android różni się w zależności od tego, czy aplikacja używa coreCLR, czy NativeAOT:

CoreCLR:

• classes.dex — Kod Java/Kotlin
• lib/arm64-v8a/libcoreclr.so — Środowisko uruchomieniowe CoreCLR
• lib/arm64-v8a/libclrjit.so — Kompilator JIT coreCLR
• lib/arm64-v8a/libmonodroid.so — klej uruchamiania środowiska uruchomieniowego specyficznego dla systemu Android
• lib/arm64-v8a/libassembly-store.so — Spakowany kod MSIL z obrazami ReadyToRun

NativeAOT w systemie Android (eksperymentalne):

• classes.dex — Kod Java/Kotlin
• lib/arm64-v8a/libhellomaui.so — natywna biblioteka zawierająca środowisko uruchomieniowe, kod zarządzany i klej startowy

Poniższa tabela zawiera podsumowanie właściwości programu MSBuild, które kontrolują zachowanie środowiska uruchomieniowego i kompilacji:

W poniższej tabeli przedstawiono podsumowanie właściwości programu MSBuild związanych z zachowaniem środowiska uruchomieniowego .NET 11 i kompilacji: