Xamarin.Mac перед компиляцией времени

  • Статья

Обзор

Перед компиляцией (AOT) — это мощный способ оптимизации для повышения производительности запуска. Однако это также влияет на время сборки, размер приложения и выполнение программы глубоко. Чтобы понять компромиссы, которые он налагает, мы рассмотрим компиляцию и выполнение приложения.

Код, написанный на управляемых языках, таких как C# и F#, компилируется в промежуточное представление с именем IL. Этот IL, хранящийся в библиотеках и сборках программ, относительно компактный и переносимый между архитектурами процессора. IL, однако, является только промежуточным набором инструкций, и в какой-то момент, что IL необходимо будет преобразовать в машинный код, характерный для процессора.

Существует два пункта, в которых можно выполнить эту обработку:

  • JIT — во время запуска и выполнения приложения il компилируется в памяти для машинного кода.
  • Заранее (AOT) — во время сборки IL компилируется и записывается в собственные библиотеки и хранится в пакете приложений.

Каждый вариант имеет ряд преимуществ и компромиссов:

  • JIT
    • Время запуска — JIT-компиляция должна выполняться при запуске. Для большинства приложений это по 100 мс, но для крупных приложений на этот раз может быть значительно больше.
    • Выполнение . Так как код JIT можно оптимизировать для конкретного используемого процессора, можно создать немного лучший код. В большинстве приложений это несколько процентных точек быстрее.
  • AOT
    • Время запуска— загрузка предварительно скомпилированных dylibs значительно быстрее, чем сборки JIT.
    • Дисковое пространство — эти дилбибы могут занять значительное количество дискового пространства. В зависимости от того, какие сборки являются AOTed, он может удвоить или больше размера части кода приложения.
    • Время сборки — компиляция AOT значительно медленнее, что JIT и замедлит сборки, используя ее. Это замедление может варьироваться от секунд до минуты или более, в зависимости от размера и количества скомпилированных сборок.
    • Обфускация — так как IL, что значительно проще для реверсивного инженера, чем машинный код, не обязательно требуется, чтобы он мог быть лишен, чтобы помочь скрыть конфиденциальный код. Для этого требуется приведенный ниже параметр "Гибридный".

Включение AOT

Параметры AOT будут добавлены в область сборки Mac в будущем обновлении. До тех пор включение AOT требует передачи аргумента командной строки через поле "Дополнительные аргументы mmp" в сборке Mac. Существуют следующие варианты выбора.

--aot[=VALUE]          Specify assemblies that should be AOT compiled
                          - none - No AOT (default)
                          - all - Every assembly in MonoBundle
                          - core - Xamarin.Mac, System, mscorlib
                          - sdk - Xamarin.Mac.dll and BCL assemblies
                          - |hybrid after option enables hybrid AOT which
                          allows IL stripping but is slower (only valid
                          for 'all')
                          - Individual files can be included for AOT via +
                          FileName.dll and excluded via -FileName.dll

                          Examples:
                            --aot:all,-MyAssembly.dll
                            --aot:core,+MyOtherAssembly.dll,-mscorlib.dll

Гибридный AOT

Во время выполнения приложения macOS среда выполнения по умолчанию использует машинный код, загруженный из собственных библиотек, созданных компиляцией AOT. Однако существуют некоторые области кода, такие как батуты, где компиляция JIT может производить значительно более оптимизированные результаты. Для этого требуется, чтобы доступные управляемые сборки IL. В iOS приложения ограничены любым использованием JIT-компиляции; эти разделы кода также компилируются AOT.

Гибридный параметр указывает компилятору компилировать эти разделы (например, iOS), но также предположить, что IL не будет доступен во время выполнения. Затем этот IL можно удалить после сборки. Как отмечалось выше, среда выполнения будет вынуждена использовать менее оптимизированные подпрограммы в некоторых местах.

Дальнейшие рекомендации

Негативные последствия масштабирования AOT с размерами и количеством обработанных сборок. Полная целевая платформа, например, содержит значительно большую библиотеку базовых классов (BCL), чем современная, и поэтому AOT займет значительно больше времени и создает большие пакеты. Это связано с несовместимостью платформы full target framework с связыванием, которая удаляет неиспользуемый код. Рассмотрите возможность перемещения приложения в современный и включения связывания для наилучших результатов.

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