Pull to refresh
0
Microsoft
Microsoft — мировой лидер в области ПО и ИТ-услуг

.NET Native – что это означает для разработчиков под универсальную Windows-платформу (UWP)?

Reading time 7 min
Views 45K
Original author: Daniel Jacobson
В Windows 10 универсальные Windows-приложения на управляемых языках (C#, VB) проходят в магазине процедуру компиляции в машинный код с использованием .NET Native. В данной статье мы предлагаем вам познакомиться подробнее с тем, как это работает и как это влияет на процесс разработки приложений. Ниже вы найдете видео-интервью с представителем команды разработки .NET Native и перевод соответствующей статьи.




Что такое .NET Native?


.NET Native – это технология предварительной компиляции, используемая при создании универсальных Windows-приложений в Visual Studio 2015. Инструменты .NET Native компилируются ваши IL-библиотеки с управляемым кодом в нативные библиотеки. Каждое управляемое (C# или VB) универсальное Windows-приложение использует данную технологию. Приложения автоматически компилируются в нативный код прежде, чем они попадут на конечное устройство. Если вы хотите погрузиться глубже в то, как это работает, рекомендуем статью “Компиляция приложений с помощью машинного кода .NET”.

Как .NET Native повлияет на меня и мое приложение?


Конкретные показатели могут отличаться, но в большинстве случаев ваше приложение будет запускаться быстрее, работать с большей скоростью и потреблять меньше системных ресурсов.
  • До 60% повышения скорости холодного старта
  • До 40% повышения скорости горячего старта
  • Уменьшенное потребление памяти при компиляции в машинный код
  • Нет зависимости от десктопного .NET Runtime при установке


Так как ваше приложение скомпилировано в машинный код, вы получите прирост производительности, связанный со скоростью выполнения нативного кода (близко к производительности C++). При этом вы по-прежнему можете пользоваться преимуществами индустриальных языков программирования C# или VB и связанных инструментов.

Вы также можете продолжать использовать всю мощь программной модели, доступной в .NET с широким набором API для описания бизнес-логики и со встроенными механизмами управления памятью и обработки исключений.
Другими словами, вы получаете лучшее из обоих миров: управляемая разработка с производительностью близкой к С++. Это ли не прекрасно?

Различия настроек компиляции в отладке и релизе


Компиляция в .NET Native – это сложный процесс, обычно более медленный в сравнении с классической компиляцией в .NET. Преимущества, упомянутые выше, имеют цену в виде времени компиляции. Вы можете выбрать компилировать нативно каждый раз, когда вы запускаете приложение, но при этому вы будете тратить больше времени, ожидая окончания сборки. Инструменты Visual Studio могут помочь вам лучше управлять этим, сглаживая, насколько это возможно, опыт разработки.

Когда вы собираете проект и запускаете в режиме отладки, вы используете IL-код поверх CoreCLR, упакованного в ваше приложение. Системные сборки .NET добавляются к коду вашего приложения, и ваше приложение учитывает зависимость от пакета Microsoft.NET.CoreRuntime (CoreCLR).
Это означает, что вы получаете наилучший возможный опыт разработки: быстрые компиляция и развертывание, широкие возможности отладки и диагностики и работоспособность всех других инструментов, к которым вы привыкли при разработке на .NET.

Когда вы переключаетесь в режим релиза, по умолчанию, ваше приложение начинает использовать цепочку сборки .NET Native. Так как пакет компилируется в машинный код, более не требуется, чтобы пакет содержал библиотеки .NET-фреймворка. В дополнение, пакет теперь зависит от свежей версии .NET Native среды – в отличие от пакета CoreCLR. Среда исполнения .NET Native на устройстве будет всегда совместима с пакетом вашего приложения.

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

Хорошее правило, которое вы можете взять себе в привычку, — это тестировать ваше приложение таким образом в течение процесса разработки, чтобы убедиться, что вы вовремя находите и исправляете проблемы, которые могут происходить в результате компиляции с .NET Native. В большинстве случаев никаких проблем не должно быть, однако, мы знаем о нескольких вещах, которые работают не очень хорошо с .NET Native. К примеру, массивы с размерностью больше четырех. В конце концов, ваши пользователи получат версию вашего приложения, скомпилированную через .NET Native, так что это хорошо бы проверить, что все работает заранее и до того, как приложение будет доставлено.

В дополнение к тому, что хорошо бы тестировать в режиме нативной компиляции, вы также можете заметить, что конфигурация сборки AnyCPU исчезла. С появлением .NET Native конфигурация AnyCPU больше не имеет смысла, так как нативная компиляция зависит от архитектуры. Дополнительным следствием этого является то, что, когда вы упаковываете ваше приложение, вам нужно выбрать все три конфигурации архитектуры (x86, x64 и ARM), чтобы быть уверенным, что ваше приложение будет запускаться на максимальном количестве устройств. Все-таки это универсальная Windows-платформа! По умолчанию, Visual Studio настроена для сборки именно таким образом, как показано на снимке ниже.


Все три архитектуры выбраны по умолчанию

Важно отметить, что вы по-прежнему можете собирать AnyCPU-библиотеки и использовать соответствующие DLL в вашем UWP-приложении. Эти компоненты будут скомпилированы в бинарные библиотеки под соответствующие архитектуры, указанные в настройках проекта.

Наконец, последнее значительное изменение в привычном подходе в результате перехода на .NET Native – это то, как вы создаете пакеты для магазина. Одна из ключевых возможностей .NET Native заключается в том, что компилятор может работать в облаке. Когда вы создаете пакет для магазина в Visual Studio, создаются два пакета: .appxupload для магазина и “тестовый” .appx для локальной установки. Пакет .appxupload содержит MSIL-сборки, а также явные отсылки на версию .NET Native, используемую вашим приложением (указано в AppxManifest.xml). Далее этот пакет отправляется в магазин и компилируется с использованием той же версии цепочки компиляции .NET Native. Так как компилятор находится в облаке, он может быть использован повторно для исправления багов без необходимости локальной перекомпиляции приложений.


Пакет .appxupload отправляется в магазин; папка Test содержит пакет appx для локальной устровки
Два следствия из этого: первое, вы как разработчик более не имеете доступа к номеру ревизии вашего приложения (четвертое число). Магазин резервирует это число как способ версионирования пакета приложения, если по какой-либо причине потребуется перекомпиляция в облаке. Не беспокойтесь, вы по-прежнему можете управлять тремя другими числами.

Второе, что вам нужно иметь в виду – вам нужно быть осторожным относительно того, какой пакет вы загружаете в магазин. Так как магазин осуществляет компиляцию в машинный код за вас, вы не можете загружать нативные сборки, созданные локальным компилятором .NET Native. Visual Studio поможет вам разобраться с этим, чтобы вы могли выбрать правильный пакет.


Выберите “Yes” для загрузки в магазин

Когда вы используете помощника для создания пакетов приложения, вам нужно выбрать “Yes” в ответ на вопрос Visual Studio, хотите ли вы создать пакет для загрузки в магазин. Я также рекомендую выбрать “Always” для опции “Generate app bundle”, что приведет к созданию единого файла .appxupload, готового для загрузки. Полная инструкция по созданию пакетов для магазина доступна в статье «Пакетирование универсальных приложений Windows для Windows 10».

Как итоги, основные изменения в том, как вы работаете, от использования .NET Native:
  • Регулярно тестируйте ваше приложение в режиме релиза
  • Убедитесь, что вы оставляете номер ревизии пакета как 0. Visual Studio не даст вам его изменить, но также не стоит это делать в других редакторах.
  • Загружайте в магазин только .appxupload, собранные в процессе создания пакета для магазина, если вы загрузите .appx для UWP-приложения, вы получите ошибку в магазине.


Дополнительные советы по использованию .NET Native


Если вы столкнетесь с проблемой, в причине которой вы подозреваете .NET Native, есть техника, которая поможет вам отладить такую проблему. Релизная конфигурация по умолчанию оптимизирует код так, что он теряет некоторые артефакты, используемые при отладки. В итоге попытка отладки релизной конфигурации будет осложнена. Вместо этого вы можете создать собственную конфигурацию, разрешив в ней использование компиляции .NET Native. Убедитесь, что вы не оптимизируете код. Подробнее об этом описано в статье “Debugging .NET Native Windows Universal Apps”.

Теперь, когда вы знаете, как отлаживать проблемы, не было бы еще лучше научиться избегать их? Для этого через NuGet вы можете поставить в ваше приложение Microsoft.NETNative.Analyzer (из консоли управления пакетами можно использовать команду “Install-Package Microsoft.NETNative.Analyzer”). Во время разработки анализатор будет предупреждать вас, если ваш код не совместим с компилятором .NET Native. Есть небольшое подмножество пространства .NET, которое не совместимо, но большинство приложений никогда не столкнется с такой проблемой.

Если вы хотите самостоятельно оценить улучшения во времени загрузки от перехода на .NET Native, вы можете замерить их самостоятельно.

Известные проблемы и способы решения


Есть несколько вещей, которые нужно иметь в виду при использовании Windows Application Certification Kit (WACK) для тестирования ваших приложений:
  1. Когда вы запускаете WACK на UWP-приложении, не прошедшем через процедуру компиляции, вы столкнетесь с нетривиальной проблемой. Она выглядит примерно так:
    • API ExecuteAssembly in uwphost.dll is not supported for this application type. App.exe calls this API.
    • API DllGetActivationFactory in uwphost.dll is not supported for this application type. App.exe has an export that forwards to this API.
    • API OpenSemaphore in ap-ms-win-core-synch-11-1-0.dll is not support for this application type. System.Threading.dll calls this API.
    • API CreateSemaphore in api-ms-win-core-kernel32-legacy-11-1-0.dll is not supported for this application type. System.Threading.dll calls this API.

    Решением является убедиться, что вы создаете пакеты правильно и запускаете WACK на соответствующем пакете. Следуйте рекомендациям сборки, чтобы не сталкиваться с такой проблемой.
  2. Приложения на .NET Native, использующие рефлекцию, могут провалиться в Windows App Cert Kit (WACK) с отсылкой на Windows.Networking.Vpn для исправления. Для решения проблемы в файле rd.xml добавьте следующую строчку и пересоберите пакет:
    < Namespace Name=”Windows.Networking.Vpn” Dynamic=”Excluded” Serialize=”Excluded” Browse=”Excluded” Activate=”Excluded” />
    


Подводя итоги


Все пользователи Windows должны выиграть от использования .NET Native. Управляемые приложения из магазина будут стартовать и работать быстрее. Разработчики смогут сочетать опыт разработки в .NET в Visual Studio, а пользователи получат прирост производительности от машинного кода. Если вы хотите рассказать нам о вашем опыте или пожеланиях, используйте UserVoice. Если вы хотите сообщить об ошибке, заполните, пожалуйста, информацию на Connect.
Tags:
Hubs:
+18
Comments 14
Comments Comments 14

Articles

Information

Website
www.microsoft.com
Registered
Founded
Employees
Unknown
Location
США