Поделиться через

Собственное развертывание AOT в iOS и Mac Catalyst

  • Статья

В собственном развертывании AOT создается приложение пользовательского интерфейса приложений .NET (.NET MAUI) на iOS и Mac Catalyst, скомпилированное в машинном коде (AOT). Собственный AOT выполняет статический анализ программы, полное обрезка приложения, которое является агрессивным при удалении кода, на который не ссылается статический код, и в преддверии создания кода.

Публикация и развертывание собственного приложения AOT дает следующие преимущества:

  • Уменьшен размер пакета приложения.
  • Быстрое время запуска.
  • Быстрее времени сборки.

Собственный AOT вводит ограничения на использование определенных аспектов среды выполнения .NET и должен использоваться только в сценариях, когда размер приложения и производительность важны. Вам потребуется адаптировать приложения к собственным требованиям AOT, что означает, что они полностью обрезаны и совместимы с AOT. Дополнительные сведения об ограничениях Собственного AOT см. в разделе об ограничениях AOT native AOT.

Если развертывание AOT в машинном коде включено, система сборки анализирует код и все его зависимости, чтобы проверить, подходит ли оно для полной обрезки и компиляции AOT. При обнаружении несовместимости создаются предупреждения обрезки и предупреждения AOT. Одно предупреждение обрезки или AOT означает, что приложение несовместимо с развертыванием Native AOT и что оно может работать неправильно. Поэтому при создании приложения для собственного развертывания AOT следует проверять и исправлять все обрезки и предупреждения AOT. Сбой этого может привести к исключениям во время выполнения, так как необходимый код мог быть удален. Если вы подавляете предупреждения, развернутое приложение AOT, необходимо тщательно протестировать, чтобы убедиться, что функциональность не изменилась с нетримированного приложения. Дополнительные сведения см. в разделе "Введение в обрезку предупреждений " и "Введение в предупреждения AOT".

Примечание.

Возможны случаи, когда исправление обрезки и предупреждения AOT недоступны, например, когда они происходят для сторонних библиотек. В таких случаях сторонние библиотеки должны быть обновлены для полной совместимости.

Преимущества производительности AOT в машинном коде

Публикация и развертывание собственного приложения AOT создает приложение, которое обычно меньше 2,5x, и приложение, которое запускается обычно до 2x быстрее. Однако точные преимущества производительности зависят от нескольких факторов, которые включают используемую платформу, устройство, на котором работает приложение, и само приложение.

Внимание

На следующих диаграммах показаны типичные преимущества производительности развертывания Native AOT для dotnet new maui приложения в iOS и Mac Catalyst. Однако точные данные зависят от оборудования и могут измениться в будущих выпусках.

На следующей dotnet new maui диаграмме показан размер пакета приложения для приложения в iOS и Mac Catalyst в разных моделях развертывания:

Диаграмма с размером пакета приложения в разных моделях развертывания.

На предыдущей диаграмме показано, что, как правило, Native AOT создает более 2x небольших приложений для iOS и Mac Catalyst по сравнению с моделью развертывания по умолчанию.

На следующей диаграмме показано среднее время запуска для конкретного dotnet new maui оборудования для приложения в iOS и Mac Catalyst в развертывании Mono и Native AOT:

Диаграмма, показывающая среднее время запуска приложения в Mono и Native AOT.

На приведенной выше диаграмме показано, что собственный AOT обычно имеет до 2x быстрее запуска на устройствах iOS и 1,2x быстрее времени запуска в Mac Catalyst, по сравнению с развертыванием Mono.

На следующей диаграмме показано среднее время сборки для конкретного dotnet new maui оборудования для приложения в iOS и Mac Catalyst в разных моделях развертывания:

Диаграмма, показывающая среднее время сборки приложения на Mono и Native AOT.

На предыдущей диаграмме показано, что обычно собственный AOT имеет до 2,8x быстрее сборки на устройствах iOS по сравнению с моделью развертывания по умолчанию. Для Mac Catalyst время сборки сравнимо с приложениями arm64 single RID, но немного медленнее для универсальных приложений по сравнению с развертыванием Mono.

Внимание

Во многих сценариях собственный AOT создаст небольшие и быстрые приложения. Однако в некоторых сценариях собственный AOT может не создавать небольшие и быстрые приложения. Поэтому важно протестировать и профилировать приложение, чтобы определить результат включения собственного развертывания AOT.

Публикация с помощью собственного AOT

Модель развертывания AOT в машинном коде включена со свойством $(PublishAot) сборки и командой dotnet publish . В следующем примере показано, как изменить файл проекта, чтобы включить развертывание Native AOT в iOS и 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) Задание свойства trueсборки для всех платформ включает обрезку и анализаторы AOT. Эти анализаторы помогают определить код, несовместимый с обрезкой или AOT.

Условное задание $(PublishAot) trueдля iOS и Mac Catalyst обеспечивает динамический анализ использования кода во время сборки и компиляции машинного AOT во время публикации. Анализ собственного AOT включает весь код приложения и все библиотеки, от которые зависит приложение.

Предупреждение

Свойство $(PublishAot) сборки не должно быть обусловлено конфигурацией сборки. Это связано с тем, что параметры обрезки включены или отключены на основе значения $(PublishAot) свойства сборки, а те же функции должны быть включены или отключены во всех конфигурациях сборки, чтобы код вел себя одинаково. Дополнительные сведения об обрезке переключателей функций см. в разделе "Параметры обрезки".

Единственный способ проверить правильность работы собственного приложения AOT заключается в том, чтобы опубликовать его с помощью dotnet publish и убедиться, что нет предупреждений обрезки или AOT, созданных кодом и его зависимостей. В частности, dotnet build -t:Publish не эквивалентен dotnet publish.

Используйте следующую dotnet publish команду для публикации приложения в iOS и Mac Catalyst с помощью собственного развертывания 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

Совет

Часто публикуйте приложения для обнаружения проблем с обрезкой или AOT в начале жизненного цикла разработки.

Ограничения AOT в собственном коде

Собственный AOT вводит ограничения на использование определенных аспектов среды выполнения .NET и должен использоваться только в сценариях, когда размер приложения и производительность важны. Это потребует от вас адаптации приложений к собственным требованиям AOT, что означает, что они полностью обрезки и совместимость AOT, и это может потребовать много работы. Помимо ограничений .NET для развертывания Native AOT, развертывание Native AOT для .NET MAUI имеет дополнительные ограничения.

Сторонние библиотеки, от которые зависят ваши приложения, могут быть несовместимы с AOT. Единственный способ обеспечить обрезку библиотеки и совместимость AOT заключается в публикации приложения с помощью собственного развертывания AOT и dotnet publish команды, а также узнать, создает ли компилятор AOT собственный код предупреждения для библиотеки. Сведения о том, как сделать собственные библиотеки совместимыми с AOT, см. в статье о том, как сделать библиотеки совместимыми с собственным AOT.

Отражение и динамический код

Собственное развертывание AOT ограничивает использование отражения в коде и его зависимостях, и это может стать необходимым для использования заметок, чтобы помочь машинному компилятору AOT понять шаблоны отражения. Когда компилятор сталкивается с шаблоном отражения, он не может статически анализировать и, следовательно, не может создать приложение, он создает предупреждения об обрезки. Собственный AOT также запрещает использование динамического кода в приложении. Например, компиляция System.Linq.Expressions не будет работать должным образом, и невозможно загрузить и выполнить сборки во время выполнения. Когда компилятор сталкивается с динамическим шаблоном, он не может заранее скомпилироваться, он создаст предупреждение AOT.

В приложении .NET MAUI это означает следующее:

  • Все КОДы XAML должны быть скомпилированы заранее. Поэтому убедитесь, что вы не отключили компиляцию XAML и что все привязки компилируются. Дополнительные сведения см. в разделе "Компиляция XAML" и "Скомпилированные привязки".
  • Все выражения привязки должны использовать скомпилированные привязки, а не путь привязки, заданный строкой. Дополнительные сведения см. в разделе "Скомпилированные привязки".
  • Операторы неявного преобразования могут не вызываться при назначении значения несовместимого типа свойству в XAML или при использовании привязки данных двумя свойствами разных типов. Вместо этого необходимо определить TypeConverter тип и присоединить его к типу с помощью .TypeConverterAttribute Дополнительные сведения см. в разделе "Определение typeConverter" для замены неявного оператора преобразования.
  • Невозможно проанализировать XAML во время выполнения с LoadFromXaml помощью метода. Хотя это можно сделать обрезкой безопасно, заметив все типы, которые могут быть загружены во время выполнения с DynamicallyAccessedMembers помощью атрибута или атрибута DynamicDependency , это очень подвержено ошибке и не рекомендуется.
  • Получение данных навигации с помощью QueryPropertyAttribute не будет работать. Вместо этого следует реализовать IQueryAttributable интерфейс для типов, которые должны принимать параметры запроса. Дополнительные сведения об обработке данных навигации с помощью одного метода см. в этом разделе.
  • Свойство SearchHandler.DisplayMemberName может не работать. Вместо этого необходимо указать внешний ItemTemplate SearchHandler вид результатов. Дополнительные сведения см. в разделе "Определение внешнего вида элемента результатов поиска".

Внимание

Интерпретатор Mono несовместим с развертыванием Native AOT, поэтому $(UseInterpreter) $(MtouchInterpreter) свойства MSBuild не влияют на использование собственного AOT. Дополнительные сведения о интерпретаторе Mono см . в интерпретаторе Mono в iOS и Mac Catalyst.

Дополнительные сведения об предупреждениях об обрезки см. в разделе "Введение в обрезку предупреждений". Дополнительные сведения о предупреждениях AOT см. в статье "Введение в предупреждения AOT".

Адаптация приложения к развертыванию Собственного AOT

Используйте следующий контрольный список, чтобы помочь вам адаптировать приложение к требованиям к развертыванию Native AOT:

  • Убедитесь, что все XAML скомпилированы:
    • Удалите все [XamlCompilation(XamlCompilationOptions.Skip)] использование.
    • Удалите все <?xaml-comp compile="false" ?> использование.
  • Удалите все вызовы LoadFromXaml метода.
  • Убедитесь, что все привязки данных компилируются. Дополнительные сведения см. в разделе "Скомпилированные привязки".
    • Убедитесь, что все привязки данных XAML аннотированы.x:DataType
    • Убедитесь, что все привязки данных кода заменяют все строковые привязки лямбда-базой.
  • Замените все [QueryProperty(...)] использование реализацией IQueryAttributable интерфейса. Дополнительные сведения об обработке данных навигации с помощью одного метода см. в этом разделе.
  • Замените все SearchHandler.DisplayMemberName использование параметром ItemTemplate. Дополнительные сведения см. в разделе "Определение внешнего вида элемента результатов поиска".
  • Замените все неявные операторы преобразования для типов, используемых в XAML, TypeConverterи прикрепите его к типу с помощью .TypeConverterAttribute Дополнительные сведения см. в разделе "Определение typeConverter" для замены неявного оператора преобразования.
    • При преобразовании из типа в тип BA будет использоваться метод в преобразователе типов, ConvertTo связанном с A ним, или ConvertFrom метод для преобразователя типов, связанного с B ним.
    • Если исходный и целевой типы имеют связанный преобразователь типов, можно использовать любой из них.
  • Скомпилируйте все регулярные выражения с помощью генераторов источников. Дополнительные сведения см. в разделе генераторов источников регулярных выражений .NET.
  • Убедитесь, что сериализация и десериализация JSON используют исходный созданный контекст. Дополнительные сведения см. в разделе "Минимальные API" и полезные данные JSON.
  • Проверьте и исправьте все предупреждения обрезки или AOT. Дополнительные сведения см. в разделе "Введение в обрезку предупреждений " и "Введение в предупреждения AOT".
  • Тщательно протестируйте приложение.

Встроенная поддержка диагностики AOT в iOS и Mac Catalyst

Собственный AOT и Mono используют подмножество возможностей диагностика и инструментирования. Благодаря широкому спектру средств диагностики Mono, это может быть полезно для диагностики и отладки проблем в Mono вместо собственного AOT. Приложения, которые являются обрезными и совместимыми с AOT, не должны иметь различий в поведении, поэтому исследования часто применяются к обеим средам выполнения.

В следующей таблице показаны диагностика поддержки native AOT в iOS и Mac Catalyst:

Функция полностью поддерживается. Частично поддерживается Не поддерживается
Наблюдаемость и телеметрия
Время разработки диагностика
Собственная отладка
Профилирование ЦП
Анализ кучи

В следующих разделах приведены дополнительные сведения об этой диагностика поддержке.

Наблюдаемость и телеметрия

Трассировка приложений .NET MAUI на мобильных платформах включена через dotnet-dsrouter , который подключает средства диагностики с приложениями .NET, работающими в iOS и Mac Catalyst, по протоколу TCP/IP. Однако собственный AOT в настоящее время несовместим с этим сценарием, так как он не поддерживает компоненты EventPipe/DiagnosticServer, созданные стеком TCP/IP. Наблюдаемость по-прежнему достижима явным образом в коде.

Время разработки диагностика

Средства командной строки .NET предоставляют отдельные команды для build и publish. dotnet build (или Start Debugging (F5) в Visual Studio Code) использует Mono по умолчанию при создании или запуске приложений .NET MAUI iOS или Mac Catalyst. В файле проекта будет создано только dotnet publish собственное приложение AOT, если эта модель развертывания включена в файле проекта.

Не все средства диагностики будут работать без труда с опубликованными приложениями AOT в машинном коде. Однако все приложения, которые являются обрезными и совместимыми с AOT (т. е. теми, которые не создают никаких предупреждений обрезки и AOT во время сборки) не должны иметь различий в поведении между Mono и Native AOT. Поэтому все средства диагностики во время разработки .NET, такие как Горячая перезагрузка, по-прежнему доступны разработчикам во время цикла разработки мобильных приложений.

Совет

Вы должны разрабатывать, отлаживать и тестировать приложение как обычно и публиковать окончательное приложение с помощью Native AOT в качестве одного из последних шагов.

Собственная отладка

При запуске приложения .NET MAUI iOS или Mac Catalyst во время разработки он выполняется в Mono по умолчанию. Однако если развертывание AOT в собственном коде AOT включено в файле проекта, поведение, как ожидается, совпадает между Mono и Native AOT, если приложение не создает никаких предупреждений обрезки и AOT во время сборки. Если приложение соответствует этому требованию, вы можете использовать стандартный модуль управляемой отладки Visual Studio Code для разработки и тестирования.

После публикации собственные приложения AOT являются собственными двоичными файлами, поэтому управляемый отладчик не будет работать над ними. Однако собственный компилятор AOT создает полностью собственные исполняемые файлы, с помощью которые можно выполнить отладку lldb. Отладка приложения lldb Mac Catalyst прямо вперед, так как она выполняется в той же системе. Однако отладка приложений NativeAOT для iOS требует дополнительных усилий.

Отладка приложений iOS .NET MAUI с помощью Собственного AOT

Приложения iOS .NET MAUI, совместимые с Native AOT и которые правильно настроены и опубликованы с помощью этой модели развертывания, можно выполнить отладку следующим образом:

  1. Опубликуйте приложение с использованием собственного целевого объекта ios-arm64 AOT и обратите внимание на следующие сведения:

    • Имя приложения (по ссылке ниже).<app-name>
    • Идентификатор пакета (на который ссылается ниже <bundle-identifier>).
    • Путь к архиву IPA-файла опубликованного приложения (ссылка приведена ниже<path-to-ipa>).

  2. Получите идентификатор физического устройства (по ссылке ниже):<device-identifier>

    xcrun devicectl list devices

  3. Установите приложение на физическом устройстве:

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

  4. Запустите приложение на физическом устройстве:

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

  5. Откройте и подключитесь lldb к физическому устройству:

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

После успешного выполнения этих действий вы сможете начать отладку собственного приложения lldbAOT .NET MAUI iOS.

Важность файла символов

По умолчанию символы отладки удаляются из двоичного файла приложения в DSYM-файл . Этот файл используется отладчиками и средствами анализа после смерти для отображения сведений о локальных переменных, номерах исходной строки и воссоздания трассировок стека аварийных дампов. Поэтому необходимо сохранить файл символов перед отправкой приложения в App Store.

Профилирование ЦП

Инструменты Xcode можно использовать для сбора примеров ЦП собственного приложения AOT.

Анализ кучи

Анализ кучи в настоящее время не поддерживается в собственном AOT.

См. также