Megosztás a következőn keresztül:

Natív AOT-üzembe helyezés iOS és Mac Catalyst rendszeren

  • Cikk

A natív AOT-telepítési folyamat egy olyan .NET többplatformos alkalmazás felhasználói felületet (.NET MAUI) hoz létre iOS-en és Mac Catalyston, amely előzetesen natív kódra lett fordítva. A natív AOT statikus programelemzést, az alkalmazás teljes csökkentését végzi, ami agresszív a nem statikusan hivatkozott kódok eltávolításában és az előzetes kódgenerálásban.

Natív AOT-alkalmazás közzététele és üzembe helyezése a következő előnyökkel jár:

  • Az alkalmazáscsomag méretének csökkentése.
  • Gyorsabb indítási idő.
  • Gyorsabb létrehozási idő.

A natív AOT korlátozásokat vezet be a .NET-futtatókörnyezet bizonyos aspektusainak használatára vonatkozóan, és csak olyan helyzetekben használható, ahol az alkalmazás mérete és teljesítménye fontos. Ehhez az alkalmazásokat hozzá kell igazítania a natív AOT-követelményekhez, ami azt jelenti, hogy biztosítani kell, hogy teljes mértékben támogassák a méretcsökkentést és AOT-kompatibilisek legyenek. A natív AOT-korlátozásokról további információt natív AOT-korlátozásokcímű témakörben talál.

Ha a natív AOT-telepítés engedélyezve van, a buildrendszer elemzi a kódot és annak minden függőségét, hogy ellenőrizze, hogy alkalmas-e a teljes vágásra és az AOT-fordításra. Inkompatibilitások észlelése esetén a rendszer vágási és AOT-figyelmeztetéseket hoz létre. Egyetlen vágási vagy AOT-figyelmeztetés azt jelenti, hogy az alkalmazás nem kompatibilis a natív AOT-telepítéssel, és lehet, hogy nem működik megfelelően. Ezért a natív AOT-telepítéshez készült alkalmazás létrehozásakor érdemes áttekinteni és kijavítani az összes vágási és AOT-figyelmeztetést. Ennek elmulasztása futásidőben kivételeket eredményezhet, mivel a szükséges kódot el lehetett volna távolítani. Ha letiltja a figyelmeztetéseket, az üzembe helyezett AOT-alkalmazást alaposan tesztelni kell annak ellenőrzéséhez, hogy a funkció nem változott-e a nem ellenőrzött alkalmazásról. További információért lásd: Bevezetés a metszési figyelmeztetésekhez és Bevezetés az AOT-figyelmeztetésekhez.

Jegyzet

Előfordulhat, hogy a vágási és AOT-figyelmeztetések javítása nem lehetséges, például külső kódtárak esetében. Ilyen esetekben a külső kódtárakat frissíteni kell, hogy teljes mértékben kompatibilisek legyenek.

Natív AOT-teljesítménybeli előnyök

A Natív AOT-alkalmazások közzététele és üzembe helyezése általában akár 2,5-szer kisebb alkalmazásokat és általában akár 2-szer gyorsabban elinduló alkalmazást is eredményez. A pontos teljesítménybeli előnyök azonban több tényezőtől függenek, például a használt platformtól, az eszköztől, amelyen az alkalmazás fut, és magát az alkalmazást is.

Fontos

Az alábbi diagramok az iOS-en és Mac Catalysten futó dotnet new maui alkalmazások natív AOT-telepítésének jellemző teljesítménybeli előnyeit mutatják be. A pontos adatok azonban hardverfüggőek, és a jövőbeli kiadásokban változhatnak.

Az alábbi diagram egy dotnet new maui-alkalmazás alkalmazáscsomagjának méretét mutatja be iOS-en és Mac Catalyston különböző üzemi modelleken:

különböző üzemi modellek alkalmazáscsomag-méretét bemutató diagram.

Az előző diagram azt mutatja, hogy a Natív AOT általában több mint 2x kisebb alkalmazásokat állít elő iOS és Mac Catalyst rendszerhez az alapértelmezett üzemi modellhez képest.

Az alábbi diagram az iOS-en és Mac Catalyston futó dotnet new maui-alkalmazások átlagos indítási idejét mutatja be egy adott hardveren mono- és natív AOT-környezetben:

Diagram, amelyen az alkalmazások átlagos indítási ideje látható a Mono és natív AOT rendszeren.

Az előző diagram azt mutatja, hogy a natív AOT általában legfeljebb 2x gyorsabb indítási idővel rendelkezik iOS-eszközökön, és 1,2-szer gyorsabb indítási időt a Mac Catalyston, mint a Mono üzembe helyezés.

Az alábbi diagram az iOS- és Mac Catalyst-alapú dotnet new maui-alkalmazások átlagos buildelési idejét mutatja be a különböző üzemi modelleken:

Monó- és natív AOT-alkalmazások átlagos buildidejére vonatkozó diagram.

Az előző diagram azt mutatja, hogy a natív AOT általában legfeljebb 2,8-szoros gyorsabb buildelési idővel rendelkezik iOS-eszközökön az alapértelmezett üzemi modellhez képest. A Mac Catalyst esetében a buildelési idők összehasonlíthatók az arm64-alapú önálló RID-alkalmazásokhoz, de az univerzális alkalmazások esetében kissé lassabbak a Mono-telepítéshez képest.

Fontos

A natív AOT számos esetben kisebb és gyorsabb alkalmazásokat fog létrehozni. Bizonyos esetekben azonban előfordulhat, hogy a natív AOT nem hoz létre kisebb és gyorsabb alkalmazásokat. Ezért fontos, hogy tesztelje és profilozza az alkalmazást a natív AOT-telepítés engedélyezésének eredményének meghatározásához.

Közzététel natív AOT használatával

A natív AOT üzemi modell engedélyezve van a $(PublishAot) buildtulajdonság és a dotnet publish parancs használatával. Az alábbi példa bemutatja, hogyan módosíthat egy projektfájlt a natív AOT-telepítés engedélyezéséhez iOS és Mac Catalyst rendszeren:

<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>

A $(IsAotCompatible) build tulajdonság truebeállítása minden platformon aktiválja a csökkentést és az AOT-elemzőket. Ezek az elemzők segítenek azonosítani a vágással vagy az AOT-val nem kompatibilis kódot.

A $(PublishAot) feltételes beállítása true, iOS és Mac Catalyst esetén, lehetővé teszi a dinamikus kódhasználat elemzését az építéskor, valamint a natív AOT-fordítást a közzététel idején. A natív AOT-elemzés tartalmazza az alkalmazás összes kódját és az alkalmazástól függő kódtárakat.

Figyelmeztetés

A $(PublishAot) build tulajdonság nem függhet a buildkonfigurációtól. Ennek az az oka, hogy a vágási funkciók kapcsolói a $(PublishAot) buildtulajdonság értéke alapján vannak engedélyezve vagy letiltva, és minden buildkonfigurációban engedélyezni vagy letiltani kell ugyanazokat a funkciókat, hogy a kód azonos módon viselkedjen. A funkciókapcsolók vágásáról további információt a A funkciókapcsolók vágásacímű témakörben talál.

A natív AOT-alkalmazások megfelelő működésének ellenőrzéséhez csak úgy lehet azt ellenőrizni, ha dotnet publish használatával közzéteszik, és ellenőrzik, hogy a kód és a függőségei nem okoznak-e vágási vagy AOT-figyelmeztetéseket. A dotnet build -t:Publish nem egyenértékű dotnet publish.

Az alábbi dotnet publish paranccsal teheti közzé alkalmazását iOS és Mac Catalyst rendszeren natív AOT-telepítéssel:

# 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

Borravaló

Gyakran közzéteheti az alkalmazásokat a vágási vagy AOT-problémák felderítéséhez a fejlesztési életciklus korai szakaszában.

Natív AOT-korlátozások

A natív AOT korlátozásokat vezet be a .NET-futtatókörnyezet bizonyos aspektusainak használatára vonatkozóan, és csak olyan helyzetekben használható, ahol az alkalmazás mérete és teljesítménye fontos. Ehhez hozzá kell igazítania az alkalmazásokat a natív AOT-követelményekhez, ami azt jelenti, hogy az alkalmazások teljes mértékben levághatók és AOT-kompatibilisek, és ez sok munkát igényelhet. A natív AOT-telepítés.NET-korlátozásai mellett a .NET MAUI natív AOT-telepítése további korlátozásokkal is rendelkezik.

Előfordulhat, hogy az alkalmazások külső kódtárai nem kompatibilisek az AOT-sal. A kódtárak kivágásának és az AOT-kompatibilisségének egyetlen módja az alkalmazás natív AOT-telepítéssel és a dotnet publish paranccsal való közzététele, valamint annak ellenőrzése, hogy a natív AOT-fordító figyelmeztetéseket állít-e elő a kódtárhoz. További információért a saját könyvtárak natív AOT-kompatibilissé tételéről lásd: Hogyan tegyük a könyvtárakat kompatibilissé a natív AOT-tal?.

Tükröződés és dinamikus kód

A natív AOT-üzembe helyezés korlátozza a kódban és annak függőségeiben a tükröződés használatát, és szükség lehet széljegyzetek használatára, hogy segítsen a natív AOT-fordítónak megérteni a tükröződési mintákat. Amikor a fordító tükröződési mintával találkozik, nem tudja statikusan elemezni, ezért nem tudja létrehozni az alkalmazást, vágási figyelmeztetéseket hoz létre. A natív AOT azt is megakadályozza, hogy dinamikus kódot használjon az alkalmazásban. Például, a System.Linq.Expressions fordítása nem működik a vártnak megfelelően, és futásidőben nem lehet assembly-ket betölteni és futtatni. Ha a fordító olyan dinamikus mintával találkozik, amely nem tud előre lefordítani, AOT-figyelmeztetést fog generálni.

A .NET MAUI alkalmazásban ez a következőt jelenti:

Fontos

A Mono-értelmező nem kompatibilis a natív AOT-telepítéssel, ezért az MSBuild $(UseInterpreter) és $(MtouchInterpreter) tulajdonságainak nincs hatása a natív AOT használatakor. További információkért a Mono értelmezőről, lásd: Mono értelmező iOS-on és Mac Catalyst-on.

További információ a vágási figyelmeztetésekről a vágási figyelmeztetések bemutatásarészben található. További információ az AOT-figyelmeztetésekről: lásd Bevezetés az AOT-figyelmeztetésekbe.

Alkalmazás adaptálása natív AOT-üzembe helyezéshez

Az alábbi ellenőrzőlista segít az alkalmazás natív AOT-telepítési követelményekhez való igazításában:

Natív AOT diagnosztikai támogatás iOS és Mac Catalyst rendszeren

A natív AOT és a Mono a diagnosztikai és műszeres ellenőrzési lehetőségek közös részhalmazát birtokolják. A Mono diagnosztikai eszközeinek köszönhetően előnyös lehet a problémák diagnosztizálása és hibakeresése a Monoban a natív AOT helyett. Az optimalizált és AOT-kompatibilis alkalmazásoknak nem szabad viselkedésbeli különbségeiknek lenniük, ezért a vizsgálatok gyakran mindkét futtatókörnyezetre vonatkoznak.

Az alábbi táblázat az iOS és Mac Catalyst natív AOT-beli diagnosztikai támogatását mutatja be:

Funkció Teljes mértékben támogatott Részben támogatott Nem támogatott
Megfigyelhetőség és telemetria ✔️
Diagnosztikák fejlesztési időben ✔️
natív hibakeresés ✔️
CPU-profilozás ✔️
halom elemzés

A következő szakaszok további információkat nyújtanak a diagnosztikai támogatásról.

Megfigyelhetőség és telemetria

A .NET MAUI-alkalmazások mobilplatformokon való nyomon követése dotnet-dsrouter keresztül érhető el, amely tcp/IP-en keresztül csatlakoztatja a diagnosztikai eszközöket az iOS-en és Mac Catalyston futó .NET-alkalmazásokkal. A natív AOT azonban jelenleg nem kompatibilis ezzel a forgatókönyvvel, mivel nem támogatja a TCP/IP-veremhez készült EventPipe/DiagnosticServer-összetevőket. A megfigyelhetőség továbbra is elérhető kifejezetten a kódban.

Fejlesztési idő diagnosztikái

A .NET CLI eszközök külön parancsokat biztosítanak build és publishszámára. dotnet build (vagy a Visual Studio Code-ban Start Debugging (F5)) alapértelmezés szerint a Mono-t használja .NET MAUI iOS- vagy Mac Catalyst-alkalmazások létrehozásakor vagy indításakor. Csak dotnet publish fog natív AOT-alkalmazást létrehozni, ha ez az üzemi modell engedélyezve van a projektfájlban.

Nem minden diagnosztikai eszköz fog zökkenőmentesen működni a közzétett Natív AOT-alkalmazásokkal. Azonban az összes levágott és AOT-kompatibilis alkalmazásnak (vagyis azoknak, amelyek nem hoznak létre vágást és AOT-figyelmeztetéseket a buildeléskor) nem kell viselkedésbeli különbségekkel rendelkezniük a Mono és a Natív AOT között. Ezért a mobilalkalmazás-fejlesztési ciklus során az összes .NET fejlesztési idő diagnosztikai eszköz, például a Hot Reload továbbra is elérhető a fejlesztők számára.

Borravaló

A szokásos módon kell fejlesztenie, hibakeresést végeznie és tesztelnie kell az alkalmazást, és az utolsó lépések egyikeként közzé kell tennie a végleges alkalmazást a Natív AOT használatával.

Natív hibakeresés

Amikor a fejlesztés során futtatja a .NET MAUI iOS- vagy Mac Catalyst-alkalmazást, az alapértelmezés szerint Mono-n fut. Ha azonban a natív AOT-telepítés engedélyezve van a projektfájlban, a viselkedés várhatóan megegyezik a Mono és a Natív AOT között, ha az alkalmazás nem hoz létre vágási és AOT-figyelmeztetéseket a létrehozáskor. Feltéve, hogy az alkalmazás megfelel ennek a követelménynek, a standard Visual Studio Code által felügyelt hibakeresési motort használhatja a fejlesztéshez és teszteléshez,

A közzététel után a natív AOT-alkalmazások valódi natív bináris fájlok, így a felügyelt hibakereső nem fog rajtuk működni. A natív AOT fordítóprogram azonban teljesen natív végrehajtható fájlokat hoz létre, amelyeket hibakereséshez használhat lldb. A Mac Catalyst-alkalmazás lldb hibakeresése egyszerű, mivel ugyanazon a rendszeren fut. A NativeAOT iOS-alkalmazások hibakeresése azonban további erőfeszítést igényel.

.NET MAUI iOS-alkalmazások hibakeresése natív AOT használatával

A natív AOT-kompatibilis, és az ezzel az üzembe helyezési modellel megfelelően konfigurált és közzétett .NET MAUI iOS-alkalmazások az alábbiak szerint hibakeresést végezhetnek:

  1. Tegye közzé alkalmazását natív AOT célozva ios-arm64-val, és jegyezze fel a következő információkat:

    • Alkalmazás neve (az alábbiakban <app-name>).
    • Csomagazonosító (az alábbiakban <bundle-identifier>).
    • A közzétett alkalmazás archívumának elérési útja az alábbiakban <path-to-ipa>-ként hivatkozott .ipa fájlhoz.

  2. Szerezze be a fizikai eszköz azonosítóját (az alábbiakban <device-identifier>):

    xcrun devicectl list devices

  3. Telepítse az alkalmazást a fizikai eszközére:

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

  4. Indítsa el az alkalmazást a fizikai eszközön:

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

  5. Nyissa meg lldb, és csatlakozzon a fizikai eszközhöz:

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

A lépések sikeres elvégzése után megkezdheti az AOT .NET MAUI iOS natív alkalmazás hibakeresését a lldbsegítségével.

A szimbólumfájl fontossága

Alapértelmezés szerint a hibakeresési szimbólumok az alkalmazás bináris fájljából egy .dSYM fájlba lesznek eltávolítva. Ezt a fájlt a hibakeresők és a post mortem analysis tools használják a helyi változókra, a forrássorszámokra vonatkozó információk megjelenítésére, valamint az összeomlási memóriaképek veremnyomainak újbóli létrehozására. Ezért fontos megőrizni a szimbólumfájlt, mielőtt beküldené az alkalmazást az App Store-ba.

CPU-profilkészítés

Xcode Instruments használható a natív AOT-alkalmazások cpu-mintáinak gyűjtésére.

Halomelemzés

A halomelemzés jelenleg nem támogatott natív AOT környezetben.

Lásd még: