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

Nativní nasazení kompilace AOT vytvoří aplikaci .NET MAUI na iOSu a Mac Catalystu, která byla předběžně zkompilována do nativního kódu. Nativní AOT provádí statickou analýzu programu, kompletní ořezání aplikace, které agresivně odstraňuje kód, na který se staticky neodkazuje, a generování 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 své aplikace požadavkům nativního AOT, což znamená zajistit, aby byly plně optimalizovány a kompatibilní s AOT. Další informace o omezeních Nativního AOT najdete v tématu Omezení Nativního AOT.

Pokud je povolena nativní distribuce AOT, systém sestavení analyzuje váš kód a všechny jeho závislosti, aby ověřil, zda je vhodný k úplné eliminaci nepotřebného kódu a kompilaci AOT. Pokud jsou zjištěny nekompatibility, jsou generována varování o ořezávání a AOT. Jedno varování ohledně ořezávání nebo AOT znamená, že aplikace není kompatibilní s nativním nasazením pomocí AOT a nemusí správně fungovat. Proto při vytváření aplikace pro nativní nasazení prostřednictvím AOT byste měli zkontrolovat a opravit všechna upozornění na ořezávání 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í, musíte důkladně otestovat aplikaci nasazenou pomocí AOT, abyste ověřili, že se funkčnost nezměnila oproti neokrájené aplikaci. Další informace naleznete v tématu Úvod do upozornění pro trim a Úvod do upozornění pro AOT.

Poznámka:

Mohou nastat případy, kdy není možné opravit oříznutí a výstrahy AOT, například když se vyskytují 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í aplikace na konkrétním dotnet new maui hardwaru pro systémy iOS a Mac Catalyst při nasazení na Mono a Native 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 iOS zařízeních až 2,8krát rychlejší dobu sestavení ve srovnání s výchozím modelem 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.

Publikujte nativně pomocí AOT

Nativní model nasazení AOT je aktivován 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>

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

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

Upozornění

Vlastnost sestavení $(PublishAot) 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

Abyste mohli odhalit problémy s oříznutím nebo AOT v rané fázi vývojového cyklu, často publikujte aplikace.

Omezení nativního 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 od vás vyžadováno, abyste své aplikace přizpůsobili požadavkům nativního AOT, což znamená zajistit, že jsou plně trimovatelné a kompatibilní s AOT, a to může vyžadovat hodně práce. Kromě omezení nativního nasazení AOT rozhraní .NET má nativní nasazení AOT pro .NET MAUI další vlastní 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 byla knihovna schopná oříznutí a kompatibilní s AOT, je publikovat aplikaci pomocí nasazení nativního AOT a příkazu dotnet publish a zjistit, zda nativní kompilátor AOT vytvoří pro knihovnu nějaká 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 reflexní vzor, který nelze staticky analyzovat, a proto nelze sestavit aplikaci, vytvoří varování o 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, který nemůže předčasně zkompilovat, zobrazí varování AOT.

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

Důležité

Interpretátor Mono není kompatibilní s nativním AOT nasazením, a proto vlastnosti MSBuild $(UseInterpreter) a $(MtouchInterpreter) nemají při použití nativního 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 na oříznutí najdete v tématu Úvod do upozornění na oříznutí. 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í 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 optimalizovány a kompatibilní s AOT (Ahead of Time), by neměly mít rozdíly v chování, takže šetření se často vztahují na obě prostředí běhu aplikace.

Následující tabulka ukazuje podporu diagnostiky s nativní AOT na 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. Jenom dotnet publish vytvoří nativní aplikaci AOT, pokud je tento model nasazení povolen v souboru projektu .

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 ořezáváním a AOT (to znamená, že nevygenerují žádná varování o ořezávání a AOT při 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 .NET, jako je například Hot Reload, stále k dispozici 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é pro Mono a Native AOT, pokud aplikace nevyvolá žádná upozornění na ořezání ani 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í se z nativních aplikací AOT stanou skutečné nativní binární soubory, 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 s lldb je jednoduché, protože je spuštěno na 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 svou aplikaci s cílením Native AOT ios-arm64 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ý se dále odkazuje jako na <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í AOT .NET MAUI iOS aplikace pomocí lldb.

Důležitost souboru symbolů

Ve výchozím nastavení jsou symboly ladění odebrány z binárního souboru aplikace a uloženy 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 v nativní AOT není v současné době podporována.

Viz také

  • Last updated on