Sdílet prostřednictvím

Nativní nasazení AOT v systémech iOS a Mac Catalyst

  • Článek

Nativní nasazení AOT vytvoří aplikaci .NET Pro víceplatformní aplikace (.NET MAUI) v iOSu a Mac Catalystu, která byla předem zkompilována do nativního kódu. Nativní AOT provádí statickou analýzu programu, úplné oříznutí aplikace, což je agresivní při odebírání kódu, na který se staticky neodkazuje, a před generováním kódu předem.

Publikování a nasazení nativní aplikace AOT přináší následující výhody:

  • Zmenšená velikost balíčku aplikace
  • Rychlejší spuštění.
  • Rychlejší doba sestavení.

Nativní AOT zavádí omezení používání určitých aspektů modulu runtime .NET a mělo by se používat pouze ve scénářích, ve kterých je důležitá velikost a výkon aplikace. Budete muset přizpůsobit aplikace nativním požadavkům AOT, což znamená, že jsou plně oříznuty a kompatibilní s AOT. Další informace o omezeních nativní AOT najdete v tématu Nativní omezení AOT.

Pokud je povolené nativní nasazení AOT, systém sestavení analyzuje váš kód a všechny jeho závislosti a ověří, jestli je vhodný pro úplné oříznutí a kompilaci AOT. Pokud jsou zjištěny nekompatibility, vygenerují se upozornění na oříznutí a AOT. Jedno oříznutí nebo upozornění AOT znamená, že aplikace není kompatibilní s nativním nasazením AOT a že nemusí správně fungovat. Proto při vytváření aplikace pro nativní nasazení AOT byste měli zkontrolovat a opravit všechna upozornění oříznutí a AOT. Pokud to neuděláte, může dojít k výjimkám za běhu, protože byl odebrán potřebný kód. Pokud potlačíte upozornění nasazené aplikace AOT, musíte důkladně otestovat, abyste ověřili, že se funkce nezměnily z nepotřebné aplikace. Další informace naleznete v tématu Úvod k oříznutí upozornění a Úvod do upozornění AOT.

Poznámka:

Můžou nastat případy, kdy není možné opravit oříznutí a upozornění AOT, například když se objeví u knihoven třetích stran. V takových případech bude nutné aktualizovat knihovny třetích stran, aby byly plně kompatibilní.

Výhody nativního výkonu AOT

Publikování a nasazení nativní aplikace AOT vytvoří aplikaci, která je obvykle až o 2,5x menší a aplikace, která se spouští obvykle až o 2x rychleji. Přesné výhody výkonu jsou ale závislé na několika faktorech, mezi které patří použitá platforma, zařízení, na kterém je aplikace spuštěná, a samotné aplikaci.

Důležité

Následující grafy ukazují typické výhody výkonu nativního nasazení AOT pro aplikaci v dotnet new maui systémech iOS a Mac Catalyst. Přesná data jsou ale závislá na hardwaru a v budoucích verzích se můžou změnit.

Následující graf ukazuje velikost balíčku aplikace pro aplikaci v dotnet new maui systémech iOS a Mac Catalyst v různých modelech nasazení:

Graf zobrazující velikost balíčku aplikace v různých modelech nasazení

Předchozí graf ukazuje, že nativní AOT obvykle vytváří více než 2x menší aplikace pro iOS i Mac Catalyst ve srovnání s výchozím modelem nasazení.

Následující graf ukazuje průměrnou dobu spuštění konkrétního dotnet new maui hardwaru pro aplikaci v systémech iOS a Mac Catalyst v mono a nativním nasazení AOT:

Graf znázorňující průměrnou dobu spuštění aplikace v Mono a Nativní AOT

Předchozí graf ukazuje, že nativní AOT má obvykle až 2x rychlejší spouštění na zařízeních s iOSem a 1,2x rychlejší spuštění v systému Mac Catalyst v porovnání s nasazením Mono.

Následující graf ukazuje průměrnou dobu sestavení na konkrétním hardwaru pro aplikaci v dotnet new maui systémech iOS a Mac Catalyst v různých modelech nasazení:

Graf znázorňující průměrnou dobu sestavení aplikace v Mono a Nativní AOT

Předchozí graf ukazuje, že nativní AOT má na zařízeních s iOSem až 2,8krát rychlejší sestavení než výchozí model nasazení. Pro Mac Catalyst jsou časy sestavení srovnatelné pro aplikace ARM64 s jedním identifikátorem RID, ale jsou mírně pomalejší pro univerzální aplikace v porovnání s nasazením Mono.

Důležité

V mnoha scénářích nativní AOT vytvoří menší a rychlejší aplikace. V některých scénářích ale nativní AOT nemusí vytvářet menší a rychlejší aplikace. Proto je důležité otestovat a profilovat aplikaci, abyste zjistili výsledek povolení nativního nasazení AOT.

Publikování pomocí nativní AOT

Nativní model nasazení AOT je povolený s $(PublishAot) vlastností sestavení a příkazem dotnet publish . Následující příklad ukazuje, jak upravit soubor projektu tak, aby umožňoval nativní nasazení AOT v systémech iOS a Mac Catalyst:

<PropertyGroup>
  <!-- enable trimming and AOT analyzers on all platforms -->
  <IsAotCompatible>true</IsAotCompatible>

  <!-- select platforms to use with NativeAOT -->
  <PublishAot Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'ios'">true</PublishAot>
  <PublishAot Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'maccatalyst'">true</PublishAot>
</PropertyGroup>

$(IsAotCompatible) Nastavení vlastnosti sestavení na true, pro všechny platformy, umožňuje oříznutí a analyzátory AOT. Tyto analyzátory vám pomůžou identifikovat kód, který není kompatibilní s oříznutím nebo AOT.

Podmíněné nastavení $(PublishAot) pro trueiOS a Mac Catalyst umožňuje dynamickou analýzu využití kódu během sestavování a nativní kompilace AOT během publikování. Nativní analýza AOT zahrnuje veškerý kód aplikace a všechny knihovny, na které aplikace závisí.

Upozorňující

$(PublishAot) Vlastnost sestavení by neměla být podmíněna konfigurací sestavení. Důvodem je to, že přepínače funkcí oříznutí jsou povolené nebo zakázané na základě hodnoty $(PublishAot) vlastnosti sestavení a stejné funkce by měly být povoleny nebo zakázány ve všech konfiguracích sestavení, aby se váš kód chová stejně. Další informace o ořezávání přepínačů funkcí naleznete v tématu Ořezávání přepínačů funkcí.

Jediným způsobem, jak ověřit, že nativní aplikace AOT funguje správně, je publikovat ji pomocí dotnet publish a ověřit, že neexistují žádná upozornění na oříznutí nebo upozornění AOT vytvořená vaším kódem a jejími závislostmi. Konkrétně dotnet build -t:Publish není ekvivalentem dotnet publish.

Pomocí následujícího dotnet publish příkazu publikujte aplikaci v systémech iOS a Mac Catalyst pomocí nativního nasazení AOT:

# iOS
dotnet publish -f net9.0-ios -r ios-arm64

# Mac Catalyst
dotnet publish -f net9.0-maccatalyst -r maccatalyst-arm64
dotnet publish -f net9.0-maccatalyst -r maccatalyst-x64

# Universal Mac Catalyst apps
# (when <RuntimeIdentifiers>maccatalyst-x64;maccatalyst-arm64</RuntimeIdentifiers> is set in the project file)
dotnet publish -f net9.0-maccatalyst

Tip

Publikování aplikací často kvůli zjišťování problémů s oříznutím nebo AOT v rané fázi životního cyklu vývoje

Nativní omezení AOT

Nativní AOT zavádí omezení používání určitých aspektů modulu runtime .NET a mělo by se používat pouze ve scénářích, ve kterých je důležitá velikost a výkon aplikace. Bude vyžadovat přizpůsobení aplikací nativním požadavkům AOT, což znamená, že jsou plně oříznuté a kompatibilní s AOT, což může vyžadovat spoustu práce. Kromě omezení rozhraní .NET pro nativní nasazení AOT má nativní nasazení AOT pro .NET MAUI další omezení.

Knihovny třetích stran, na které vaše aplikace závisí, nemusí být kompatibilní s AOT. Jediný způsob, jak zajistit, aby knihovna ořízla a kompatibilní SOT, je publikovat aplikaci pomocí nativního dotnet publish nasazení AOT a příkazu a zjistit, jestli nativní kompilátor AOT vytvoří pro knihovnu upozornění. Informace o tom, jak zajistit kompatibilitu vlastních knihoven AOT, najdete v tématu Jak nastavit, aby knihovny byly kompatibilní s nativní AOT.

Reflexe a dynamický kód

Nativní nasazení AOT omezuje použití reflexe v kódu a jejích závislostech a může být nezbytné používat poznámky, které umožní nativnímu kompilátoru AOT porozumět vzorům reflexe. Když kompilátor narazí na vzor odrazu, nemůže staticky analyzovat, a proto nemůže sestavit aplikaci, vytvoří upozornění oříznutí. Nativní AOT vám také brání v používání dynamického kódu v aplikaci. Kompilace System.Linq.Expressions například nebude fungovat podle očekávání a není možné načíst a spouštět sestavení za běhu. Když kompilátor narazí na dynamický vzor, nemůže předem provést kompilaci, vytvoří upozornění AOT.

V aplikaci .NET MAUI to znamená, že:

Důležité

Interpret Mono není kompatibilní s nativním nasazením AOT, a proto $(UseInterpreter) vlastnosti MSBuild $(MtouchInterpreter) nemají při použití nativní AOT žádný vliv. Další informace o interpretu Mono naleznete v tématu Mono interpret v systémech iOS a Mac Catalyst.

Další informace o upozorněních oříznutí najdete v tématu Úvod k oříznutí upozornění. Další informace o upozorněních AOT najdete v tématu Úvod k upozorněním AOT.

Přizpůsobení aplikace nativnímu nasazení AOT

Následující kontrolní seznam vám pomůže přizpůsobit aplikaci nativním požadavkům na nasazení AOT:

Nativní podpora diagnostiky AOT v systémech iOS a Mac Catalyst

Nativní funkce AOT a Mono sdílejí podmnožinu možností diagnostiky a instrumentace. Vzhledem k rozsahu diagnostických nástrojů mono může být užitečné diagnostikovat a ladit problémy v rámci Mono místo nativní AOT. Aplikace, které jsou oříznuty a kompatibilní s AOT, by neměly mít rozdíly v chování, takže šetření se často vztahují na oba moduly runtime.

Následující tabulka ukazuje podporu diagnostiky nativní AOT v systémech iOS a Mac Catalyst:

Funkce Plně podporovaná Částečně podporováno Nepodporováno
Pozorovatelnost a telemetrie
Diagnostika v době vývoje
Nativní ladění
Profilace procesoru
Analýza haldy

Následující části obsahují další informace o této podpoře diagnostiky.

Pozorovatelnost a telemetrie

Trasování aplikací .NET MAUI na mobilních platformách je povolené prostřednictvím dotnet-dsrouter , který spojuje diagnostické nástroje s aplikacemi .NET běžícími v systémech iOS a Mac Catalyst přes PROTOKOL TCP/IP. Nativní AOT ale v současné době není kompatibilní s tímto scénářem, protože nepodporuje komponenty EventPipe/DiagnosticServer vytvořené se zásobníkem TCP/IP. Pozorovatelnost je stále dosažitelná explicitně v kódu.

Diagnostika v době vývoje

Nástroje .NET CLI poskytují samostatné příkazy pro build a publish. dotnet build (nebo Start Debugging (F5) v editoru Visual Studio Code) ve výchozím nastavení používá mono při sestavování nebo spouštění aplikací .NET MAUI pro iOS nebo Mac Catalyst. Pokud je dotnet publish projektu povolený, vytvoří se pouze nativní aplikace AOT.

Ne všechny diagnostické nástroje budou bez problémů fungovat s publikovanými nativními aplikacemi AOT. Všechny aplikace, které jsou kompatibilní s AOT (to znamená, že ty, které nevygenerují žádné oříznutí a upozornění AOT v době sestavení), by ale neměly mít rozdíly v chování mezi mono a nativní AOT. Proto jsou všechny diagnostické nástroje pro vývoj v době vývoje .NET, jako je například Opětovné načítání za provozu, stále dostupné vývojářům během vývojového cyklu mobilních aplikací.

Tip

Aplikaci byste měli vyvíjet, ladit a testovat jako obvykle a publikovat finální aplikaci pomocí nativní AOT jako jeden z posledních kroků.

Nativní ladění

Při spuštění aplikace .NET MAUI iOS nebo Mac Catalyst během vývoje běží ve výchozím nastavení na Mono. Pokud je však v souboru projektu povolené nativní nasazení AOT, očekává se, že chování bude stejné mezi Mono a Native AOT, pokud aplikace nevytvoří žádné oříznutí a upozornění AOT v době sestavení. Za předpokladu, že vaše aplikace splňuje tento požadavek, můžete k vývoji a testování použít standardní ladicí modul spravovaný editorem Visual Studio Code.

Po publikování jsou nativní binární soubory nativních aplikací AOT, takže na nich spravovaný ladicí program nebude fungovat. Nativní kompilátor AOT však generuje plně nativní spustitelné soubory, které můžete ladit pomocí lldb. Ladění aplikace Mac Catalyst je lldb rovnou vpřed, protože se provádí ve stejném systému. Ladění aplikací NativeAOT pro iOS ale vyžaduje další úsilí.

Ladění aplikací .NET MAUI pro iOS pomocí nativní AOT

Aplikace .NET MAUI pro iOS, které jsou kompatibilní s nativní AOT a které jsou správně nakonfigurované a publikované s tímto modelem nasazení, je možné ladit následujícím způsobem:

  1. Publikujte aplikaci s nativním cílením ios-arm64 AOT a poznamenejte si následující informace:

    • Název aplikace (odkazovaný níže jako <app-name>).
    • Identifikátor svazku (odkazovaný níže jako <bundle-identifier>).
    • Cesta k souboru .ipa publikované aplikace (na který odkazujeme níže).<path-to-ipa>

  2. Získejte ID fyzického zařízení (na které se odkazuje níže <device-identifier>:

    xcrun devicectl list devices

  3. Nainstalujte aplikaci na fyzické zařízení:

    xcrun devicectl device install app --device <device-identifier> <path-to-ipa>

  4. Spusťte aplikaci na fyzickém zařízení:

    xcrun devicectl device process launch --device <device-identifier> --start-stopped <bundle-identifier>

  5. Otevřete lldb fyzické zařízení a připojte se k němu:

    (lldb) device select <device-identifier>
(lldb) device process attach -n <app-name>

Po úspěšném dokončení těchto kroků budete moci spustit ladění nativní aplikace AOT .NET MAUI iOS pomocí lldbaplikace .

Důležitost souboru symbolů

Ve výchozím nastavení jsou symboly ladění odebrány z binárního souboru aplikace do souboru .dSYM . Tento soubor používají ladicí programy a nástroje pro analýzu po mortem k zobrazení informací o místních proměnných, zdrojových řádcích a k opětovnému vytvoření trasování zásobníku výpisů stavu systému. Proto je důležité před odesláním aplikace do App Storu zachovat soubor symbolů.

Profilace procesoru

Nástroje Xcode lze použít ke shromažďování vzorků procesoru nativní aplikace AOT.

Analýza haldy

Analýza haldy se v současné době nepodporuje v nativní AOT.

Viz také