Аппаратное ускорение visual studio
Сразу скажу, что в финале мне удалось добиться сокращения времени компиляции решения с 4:24 минут до менее чем одной минуты. Детали под катом.
На старт!
В начале я собирался собрать отдельную тестовую машину с «чистой» ОС и одной лишь установленной программой — Visual Studio. Но потом решил, что тестировать сферических коней в вакууме будет не совсем верно. На компьютере программиста так или иначе будут установлены какой-нибудь браузер, антивирус, файловый менеджер, архиватор, текстовый редактор и т.д., а значит Студии придется работать со всем этим по близости. Значит, в таком режиме и будем её тестировать, на обычном компьютере разработчика (переустановив, правда, ради чистоты эксперимента, операционную систему и поставив свежие версии используемых в работе программ).
Набор экспериментов составлен по советом с сайтов Stackoverfow, RSDN, форумов MSDN, выдачи Google ну и просто из головы.
Объектом тестирования станет время полной компиляции решения. Перед каждым экспериментом вся папка проекта будет удаляться, код будет заново заливаться из репозитория, а Visual Studio перезагружаться. Каждый эксперимент будет повторяться трижды, результатом будет среднее время. После каждого эксперимента сделанные изменения откатываются.
Если кому-нибудь интересна аппаратная конфигурация моего компьютера, так вот она:
+ жесткий диск WD 500 Гб, 7200 RPM, 16 Мб кэш
+ Win 7 Профессиональная 32 бита со всеми возможными обновлениями
+ Visual Studio 2010 Professional с первым сервис-паком
В Windows включен режим максимальной производительности, отключен Aero и всякие анимации.
Исходное время компиляции моего решения: 4 минуты 24 секунды
Поехали!
Временные файлы — на RamDrive
Есть мнение, что самые медленные операции во время компиляции решения связаны с доступом к диску. Уменьшить это время можно путем использования RamDrive для временных файлов.
Результат: 4 минуты 13 секунд или -4.17% ко времени компиляции.
Вывод: прирост производительности имеется, хоть и небольшой. Если количество ОЗУ позволяет, этот совет можно применять в деле.
Весь проект — на RamDrive
Коль уж нам удалось немного ускорить компиляцию за счет выноса на RamDrive временных файлов, возможно получиться добиться еще лучших результатов, переместив туда всё решение (всё-таки более 4000 файлов).
Результат: 3 минуты 47 секунд или -14.02% ко времени компиляции.
Вывод: По началу этот эксперимент показался мне немного стрёмным — хранить исходники в оперативной памяти не лучший вариант (а вдруг пропадет питание?). Но, учитывая факт наличия бесперебойников, равно как и таких версий RamDrive, как от QSoft (с автоматическим дублированием измененных файлов с RamDrive на жесткий диск) убедили меня, что вариан возможен. Нужно только достаточно ОЗУ (и, по-хорошему, 64-битная ОС).
Весь проект — на флешку
Включение функции ReadyBoost в Windows
Microsoft расхваливает эту функцию именно за повышение производительности при работе с большим количеством относительно небольших блоков данных (наш вариант). Попробуем.
Результат: 4 минуты 17 секунд или -2.65% ко времени компиляции.
Вывод: вполне нормальный способ ускорения работы. Кроме необходимости 1 раз вставить флешку и настроить ReadyBoost других недостатков не имеет, а некоторый прирост производительности даёт.
Изменение количества одновременно компилирующихся проектов
Visual Studio при установке прописывает это число равным общему количеству ядер процессоров в Вашем ПК. Тем не менее, мы можем попробовать его изменить (делается это в настройках VS для С++ проектов) и оценить изменение производительности. Так как в моём компьютере 4-ядерный процессор, изначально это число было равным четырём.
Результат:
6 проектов компилируются одновременно — 4 минуты 34 секунды или +3.79% ко времени компиляции
2 проекта компилируется одновременно — 4 минуты 21 секунда или -1.14% ко времени компиляции
Вывод: я с самого начала ожидал, что увеличение числа одновременно компилирующихся проектов не даст никакого прироста производительности (так и вышло). Но вот почему уменьшение его до двух дало небольшой прирост для меня не очень понятно. Возможно, это просто статистическая погрешность, а может быть при компиляции 4-ех проектов Студия из-за их зависимостей теряет время на каком-то ожидании, что происходит реже при компиляции всего двух проектов. Если у кого-нибудь еще есть мысли по теме — прошу в комментарии.
Отключение вывода текста билда в окно Оutput
Меньше вывода текста при компиляции — быстрее результат.
Результат: 4 минуты 22 секунды или -0.76% ко времени компиляции
Вывод: прирост столь смехотворен, что не стоит даже комментариев. Он может быть как реальным, так и случайным.
Очистка корзины
Я вычитал этот совет на Stackoverflow. Аргументация была в том, что по ходу компиляции создаётся и удаляется масса мелких файлов, а процедура удаления в Windows работает медленнее при забитой корзине. Поскольку все предыдущие эксперименты я и так проводил при пустой корзине, мне пришлось проделать обратный эксперимент — положить в корзину 5000 файлов общим объёмом в 2 Гб.
Результат: 4 минуты 23 секунды или +0.38% ко времени компиляции.
Вывод: время компиляции осталось без изменений. Теория провалилась.
Ключ компилятора /MP
Ключ /MP — это тоже параллельная компиляция, но уже не проектов в решении, а файлов внутри каждого проекта.
Результат: 2 минуты 38 секунд или -40.15% ко времени компиляции
Вывод: это одно из самых существенных достижений среди всех поставленных экспериментов. Конечно, прирост столь высок в основном из-за 4-ядерности моего процессора, но вскоре такие (и еще более-ядерные процессоры) станут нормой в любом компьютере, так что включать опцию имеет смысл. При её включении компилятор честно предупреждает, что она не совместимо с ключом /Gm (Enable Minimal Rebuild), что вначале пугает — возникает мысль, что теперь при любом изменении любого файла будет происходить полная перекомпиляция решения. Так вот — нифига подобного! После изменения одного файла с кодом, как и ранее, будет перекомпилироваться только этот файл, а не всё решение. Всё, что делает ключ — это определяет выбор алгоритма определения взаимосвязей файлов кода и файлов заголовков в проекте (детальнее). Оба алгоритма неплохи и существенный прирост производительности от включения /MP во много раз превосходит недостатки от отключения /Gm.
Удаление папки решения из индекса поиска Windows
Есть мнение, что изменение файлов в папках, которые индексируются механизмом поиска ОС Windows, приводит к увеличению времени компиляции.
Результат: 4 минуты 24 секунды или никакого изменения во времени компиляции
Вывод: то ли индексирование в Windows сделано так хорошо, что вообще не замедляет работу других программ с диском, то ли это влияние минимально, то ли мне просто повезло и компиляция не совпала по времени с индексацией.
Unity Builds
Об этом механизме я рассказывал в прошлой статье.
Результат: 3 минуты 24 секунды или -22.73% ко времени компиляции.
Вывод: сокращение времени компиляции существенно. О всех достоинства и недостатках этой методики я уже писал, использовать его или нет Вы можете решить сами.
Завершение лишних программ
Работающие параллельно со Студией программы кушают память и ресурсы процессора. Их закрытие может положительно сказаться на скорости работы Студии. Итак, я закрываю Skype, QIP, Dropbox, GTalk, DownloadMaster, Mysql server.
Результат: 4 минуты 15 секунд или -3.41% ко времени компиляции
Вывод: во время компиляции придется обойтись без других программ. Никаких анекдотов и порнухи «пока оно там компилится». Вряд ли полный отказ от всех программ возможен для разработчика, но можно создать бат-файлы, включающие\выключащие все лишнее и иногда ими пользоваться.
Отключение антивируса
Если у Вас в системе установлен антивирус, то эта сволочь полезная программа постоянно проверяет все файловые операции. Таким образом, каждый участвующей в компиляции файл будет удостоен внимательного взгляда бдительного стража, что может замедлить время компиляции. Я, честно говоря, не был уверен, как настроить мой антивирус так, чтобы быть уверенным в полном игнорировании им моего проекта и попросту его удалил. Ваш антивирус, возможно, конфигурируется нужным образом.
Результат: 3 минуты 32 секунды или -19.07% ко времени компиляции
Вывод: удивительный результат. Я почему-то был уверен, что все эти *.cpp. *.h, *.obj файлы полностью антивирусом игнорируются и внимания удостоятся только скомпилированные исполняемые программы, что не очень сильно замедлит работу. Однако, факт налицо — почти минута времени экономии.
Дефрагментация жесткого диска
Файловые операции выполняются быстрее на дефрагментированом диске, а компиляция — это огромное количество файловых операций. Я специально оставил этот эксперимент напоследок, поскольку отменить дефрагментацию диска невозможно, а я хотел сделать эксперименты максимально независимыми.
Результат: 4 минуты 8 секунд или -6.06% ко времени компиляции
Вывод: практика согласуется с теорией. Поставьте себе дефрагментацию в планировщик и почаще.
Способы, которые, вероятно, помогли бы, но попробовать не вышло
Переход на 64-битную версию Windows
Есть предположение, что это дало бы некоторый прирост производительности, но портирование нашего проекта под x64, в силу его специфики, имеет не очень высокий приоритет и пока не реализовано. Соответственно, пока что нечего и тестировать.
Обновление процессора, памяти, замена HDD на SSD или RAID
Нужно сказать, что моя тестовая машинка не так уж плоха и до планового апгрейда еще далеко. Работаем с тем, что есть. По отзывам в интернете наибольшее влияние на время компиляции оказывает установка SSD.
Вынесение редко меняющихся проектов в отдельное решение
Это и так уже было сделано. Если в Вашем проекте подобное еще не реализовано — обязательно займитесь.
Xoreax's IncrediBuild или аналог
Распределение компиляции между компьютерами — это уже достаточно кардинальный шаг. Он требует покупки специального ПО, серьёзной настройки и некоторого «выворачивания наизнанку» процесса сборки. Но в очень больших проектах это может стать единственным возможным вариантом. На сайте Xoreax's IncrediBuild есть данные по приросту производительности, рассказы клиентов и куча другого спама разной полезной информации по теме.
Это всё, что я хотел рассказать о способах ускорения компиляции решений в Visual Studio, а в следующей статье я приведу несколько советов по ускорению работы самой IDE.
Visual Studio упрощает тестирование и отладку приложений Xamarin.Android с помощью Android Emulator в ситуациях, когда использовать устройство с Android невозможно или неудобно. Однако если на компьютере недоступно аппаратное ускорение, Android Emulator работает слишком медленно. Вы можете значительно повысить производительность эмулятора Android Emulator, используя специальные образы виртуальных устройств на платформе x86 в сочетании с функциями виртуализации на компьютере.
Сценарий | HAXM | WHPX | Hypervisor.Framework |
---|---|---|---|
У вас процессор Intel | X | X | X |
У вас процессор AMD | X | ||
Требуется поддержка Hyper-V | X | ||
Требуется поддержка вложенной виртуализации | Ограниченный | ||
Требуется использовать такие технологии, как Docker | (С WSL2) | X | X |
Ускорение эмуляторов Android в Windows
Следующие технологии виртуализации доступны для ускорения эмулятора Android:
Microsoft Hyper-V и платформа гипервизора Windows (WHPX) . Hyper-V — это функция виртуализации в Windows, которая позволяет запускать виртуализированные компьютерные системы на физическом главном компьютере.
Intel Hardware Accelerated Execution Manager (HAXM) . HAXM — это механизм виртуализации для компьютеров на базе процессоров Intel.
Для достижения наилучшего взаимодействия с пользователем в Windows рекомендуется использовать WHPX для ускорения Android Emulator. Если WHPX недоступен на вашем компьютере, можно использовать HAXM. Эмулятор Android автоматически использует аппаратное ускорение, если соблюдены следующие условия:
Аппаратное ускорение доступно и включено на компьютере разработчика.
Эмулятор работает с образом системы, созданным для виртуального устройства на платформе x86.
Нельзя запустить эмулятор на базе ускоренной виртуальной машины внутри другой виртуальной машины, например под управлением VirtualBox, VMware или Docker (если не используется WSL2). Эмулятор Android следует запускать непосредственно на системном оборудовании.
Сведения о запуске и отладке с помощью эмулятора Android см. в статье Отладка в Android Emulator.
Ускорение с помощью Hyper-V
Перед включением Hyper-V прочтите следующий раздел, чтобы убедиться, что компьютер поддерживает Hyper-V.
Проверка поддержки Hyper-V
Hyper-V работает на платформе гипервизора Windows. Чтобы использовать эмулятор Android с Hyper-V, компьютер должен отвечать следующим условиям для поддержки платформы гипервизора Windows:
Оборудование компьютера должно соответствовать следующим требованиям:
- 64-разрядный ЦП Intel или AMD Ryzen с преобразованием адресов второго уровня (SLAT).
- ЦП должен поддерживать расширения режима мониторинга виртуальной машины (VT-c на процессорах Intel).
- Не менее 4 ГБ памяти.
В BIOS компьютера необходимо включить следующие элементы:
- Технология виртуализации (может иметь другое название в зависимости от производителя системной платы).
- Предотвращение исполнения данных на основе оборудования.
Компьютер необходимо обновить до Windows 10, обновление за апрель 2018 г. (сборка 1803), или более поздней версии. Выполните следующие действия, чтобы проверить актуальность вашей версии Windows:
В поле поиска Windows введите Сведения.
В результатах поиска выберите Сведения о компьютере.
Прокрутите диалоговое окно Сведения до раздела Характеристики Windows.
Должна быть указана версия не ранее 1803:
Чтобы убедиться, что компьютерное оборудование и программное обеспечение совместимо с Hyper-V, откройте командную строку и введите следующую команду:
Если все указанные требования Hyper-V имеют значение Да, компьютер поддерживает Hyper-V. Пример:
Включение ускорения Hyper-V
Если ваш компьютер соответствует приведенным выше критериям, выполните следующие действия для ускорения эмулятора Android с помощью Hyper-V.
Введите компоненты windows в поле поиска Windows и выберите Включение и отключение компонентов Windows в результатах поиска. В диалоговом окне Компоненты Windows включите Hyper-V и платформу гипервизора Windows:
После внесения этих изменений перезагрузите компьютер.
В Windows 10 с обновлением за октябрь 2018 г. (RS5) и более поздних версий необходимо только включить Hyper-V, так как он будет автоматически использовать платформу гипервизора Windows (WHPX).
Установите Visual Studio 15.8 или более поздней версии (в этой версии Visual Studio интегрированная среда разработки поддерживает запуск эмулятора Android с Hyper-V).
Установите пакет Android Emulator версии 27.2.7 или более поздней. Чтобы установить этот пакет, выберите инструменты Android > пакет SDK для Android Manager в Visual Studio. Откройте вкладку Инструменты и убедитесь, что установлена версия эмулятора Android не ниже 27.2.7. Кроме того, убедитесь, что установлен компонент Android SDK Tools версии 26.1.1 или более поздней:
При создании виртуального устройства (см. раздел Управление виртуальными устройствами с помощью Android Device Manager) не забудьте выбрать образ системы на базе x86. Если вы используете образ системы на основе ARM, виртуальное устройство не ускорится и будет работать медленно.
Теперь технология Hyper-V должна быть включена, и вы можете запустить эмулятор Android с ускорением.
Ускорение с помощью HAXM
Если компьютер не поддерживает Hyper-V, используйте HAXM для ускорения эмулятора Android. Отключите отключить Device Guard, чтобы использовать HAXM.
Проверка поддержки HAXM
Чтобы определить, поддерживает ли оборудование HAXM, следуйте инструкциям из раздела Мой процессор поддерживает технологию виртуализации Intel?. Если оборудование поддерживает HAXM, проверьте, установлен ли HAXM:
Откройте окно командной строки и введите следующую информацию:
Посмотрите в выходных данных, запущен ли процесс HAXM. Если да, для состояния intelhaxm будет отображаться RUNNING . Пример:
Если STATE не имеет значение RUNNING , HAXM не установлен.
Если компьютер поддерживает HAXM, но он не установлен, установите его, выполнив действия, приведенные в следующем разделе.
Установка HAXM
Пакеты установки HAXM для Windows можно найти на странице выпусков GitHub, посвященной Intel Hardware Accelerated Execution Manager. Чтобы скачать и установить решение HAXM, выполните следующие действия:
Скачайте с веб-сайта Intel последнюю версию установщика подсистемы виртуализации HAXM для ОС Windows. Скачивая установщик HAXM с веб-сайта Intel, вы гарантированно получаете последнюю версию этой программы.
Откройте файл haxm-N.N.N-setup.exe (где N.N.N — это номер версии), чтобы запустить установщик HAXM. Примите значения по умолчанию, предлагаемые в диалоговых окнах установщика:
При создании виртуального устройства (см. раздел Управление виртуальными устройствами с помощью Android Device Manager) не забудьте выбрать образ системы на базе x86. Если вы используете образ системы на основе ARM, виртуальное устройство не ускорится и будет работать медленно.
Устранение неполадок
Сведения о решении проблем с аппаратным ускорением см. в руководстве по устранению неполадок для эмулятора Android.
Ускорение эмуляторов Android в macOS
Следующие технологии виртуализации доступны для ускорения эмулятора Android:
Платформа гипервизора Apple. Гипервизор входит в состав macOS 10.10 и более поздних версий и позволяет запускать виртуальные машины на компьютере Mac.
Intel Hardware Accelerated Execution Manager (HAXM) . HAXM — это механизм виртуализации для компьютеров на базе процессоров Intel.
Рекомендуется использовать платформу гипервизора для ускорения эмулятора Android. Если платформа гипервизора недоступна на компьютере Mac, можно использовать HAXM. Эмулятор Android автоматически использует аппаратное ускорение, если соблюдены следующие условия:
Аппаратное ускорение доступно и включено на компьютере разработчика.
Эмулятор работает с образом системы, созданным для виртуального устройства на платформе x86.
Вы не можете запускать эмулятор на базе ускоренной виртуальной машины внутри другой виртуальной машины, например под управлением VirtualBox, VMWare или Docker. Эмулятор Android следует запускать непосредственно на системном оборудовании.
Сведения о запуске и отладке с помощью эмулятора Android см. в статье Отладка в Android Emulator.
Ускорение с помощью платформы гипервизора
Для использования эмулятора Android с платформой гипервизора компьютер Mac должен соответствовать следующим критериям:
Mac должен работать под управлением macOS 10.10 или более поздней версии.
ЦП компьютера Mac должен поддерживать платформу гипервизора.
Если компьютер Mac соответствует этим критериям, Android Emulator будет автоматически использовать платформу гипервизора для ускорения. Если вы не уверены, поддерживает ли Mac платформу гипервизора, см. руководство Устранение неполадок, чтобы проверить это.
Если платформа гипервизора не поддерживается на компьютере Mac, используйте решение HAXM для ускорения эмулятора Android (описывается далее).
Ускорение с помощью HAXM
Если компьютер Mac не поддерживает платформу гипервизора (или ваша версия macOS ниже 10.10), используйте Intel Hardware Accelerated Execution Manager (HAXM) для ускорения эмулятора Android.
Прежде чем использовать эмулятор Android с HAXM в первый раз, рекомендуется проверить наличие установленного решения HAXM и его доступность для эмулятора Android.
Проверка поддержки HAXM
Проверьте, установлен ли HAXM:
Откройте терминал и введите следующую команду:
Эта команда предполагает, что пакет SDK для Android установлен в расположении по умолчанию ~/Library/Developer/Xamarin/android-sdk-macosx; в противном случае измените этот путь для расположения пакета SDK для Android на Mac.
Если решение HAXM установлено, приведенная выше команда вернет подобный результат:
Если решение HAXM не установлено, установите его, выполнив действия, приведенные в следующем разделе.
Установка HAXM
Пакеты установки HAXM для macOS можно найти на странице Intel Hardware Accelerated Execution Manager. Чтобы скачать и установить решение HAXM, выполните следующие действия:
Скачайте с веб-сайта Intel последнюю версию установщика подсистемы виртуализации HAXM для ОС macOS.
Запустите установщик HAXM. Примите значения по умолчанию, предлагаемые в диалоговых окнах установщика:
Устранение неполадок
Сведения о решении проблем с аппаратным ускорением см. в руководстве по устранению неполадок для эмулятора Android.
Visual Studio makes it easier for developers to test and debug their Xamarin.Android applications by using the Android emulator in situations where an Android device is unavailable or impractical. However, the Android emulator runs too slowly if hardware acceleration is not available on the computer that runs it. You can drastically improve the performance of the Android emulator by using special x86 virtual device images in conjunction with the virtualization features of your computer.
Scenario | HAXM | WHPX | Hypervisor.Framework |
---|---|---|---|
You have an Intel Processor | X | X | X |
You have an AMD Processor | X | ||
You want to support Hyper-V | X | ||
You want to support nested Virtualization | Limited | ||
You want to use technologies like Docker | (with WSL2) | X | X |
Accelerating Android emulators on Windows
The following virtualization technologies are available for accelerating the Android emulator:
Microsoft's Hyper-V and the Windows Hypervisor Platform (WHPX). Hyper-V is a virtualization feature of Windows that makes it possible to run virtualized computer systems on a physical host computer.
Intel's Hardware Accelerated Execution Manager (HAXM). HAXM is a virtualization engine for computers running Intel CPUs.
For the best experience on Windows, it is recommended that you use WHPX to accelerate the Android emulator. If WHPX is not available on your computer, then HAXM can be used. The Android emulator will automatically make use of hardware acceleration if the following criteria are met:
Hardware acceleration is available and enabled on your development computer.
The emulator is running a system image created for an x86-based virtual device.
You can't run a VM-accelerated emulator inside another VM, such as a VM hosted by VirtualBox, VMware, or Docker (unless using WSL2). You must run the Android emulator directly on your system hardware.
For information about launching and debugging with the Android emulator, see Debugging on the Android Emulator.
Accelerating with Hyper-V
Before enabling Hyper-V, read the following section to verify that your computer supports Hyper-V.
Verifying support for Hyper-V
Hyper-V runs on the Windows Hypervisor Platform. To use the Android emulator with Hyper-V, your computer must meet the following criteria to support the Windows Hypervisor Platform:
Your computer hardware must meet the following requirements:
- A 64-bit Intel or AMD Ryzen CPU with Second Level Address Translation (SLAT).
- CPU support for VM Monitor Mode Extension (VT-c on Intel CPUs).
- Minimum of 4-GB memory.
In your computer's BIOS, the following items must be enabled:
- Virtualization Technology (may have a different label depending on motherboard manufacturer).
- Hardware Enforced Data Execution Prevention.
Your computer must be updated to Windows 10 April 2018 update (build 1803) or later. You can verify that your Windows version is up-to-date by using the following steps:
Enter About in the Windows search box.
Select About your PC in the search results.
Scroll down in the About dialog to the Windows specifications section.
Verify that the Version is at least 1803:
To verify that your computer hardware and software is compatible with Hyper-V, open a command prompt and type the following command:
If all listed Hyper-V requirements have a value of Yes, then your computer can support Hyper-V. For example:
Enabling Hyper-V acceleration
If your computer meets the above criteria, use the following steps to accelerate the Android emulator with Hyper-V:
Enter windows features in the Windows search box and select Turn Windows features on or off in the search results. In the Windows Features dialog, enable both Hyper-V and Windows Hypervisor Platform:
After making these changes, reboot your computer.
On Windows 10 October 2018 Update (RS5) and higher, you only need to enable Hyper-V, as it will use Windows Hypervisor Platform (WHPX) automatically.
Install Visual Studio 15.8 or later (this version of Visual Studio provides IDE support for running the Android emulator with Hyper-V).
Install the Android Emulator package 27.2.7 or later. To install this package, navigate to Tools > Android > Android SDK Manager in Visual Studio. Select the Tools tab and ensure that the Android emulator version is at least 27.2.7. Also ensure that the Android SDK Tools version is 26.1.1 or later:
When you create a virtual device (see Managing Virtual Devices with the Android Device Manager), be sure to select an x86-based system image. If you use an ARM-based system image, the virtual device will not be accelerated and will run slowly.
Hyper-V should now be enabled and you can run your accelerated Android emulator.
Accelerating with HAXM
If your computer does not support Hyper-V, you may use HAXM to accelerate the Android emulator. You must disable Device Guard if you want to use HAXM.
Verifying HAXM support
To determine if your hardware supports HAXM, follow the steps in Does My Processor Support Intel Virtualization Technology?. If your hardware supports HAXM, you can check to see if HAXM is already installed by using the following steps:
Open a command prompt window and enter the following command:
Examine the output to see if the HAXM process is running. if it is, you should see output listing the intelhaxm state as RUNNING . For example:
If STATE is not set to RUNNING , then HAXM is not installed.
If your computer can support HAXM but HAXM is not installed, use the steps in the next section to install HAXM.
Installing HAXM
HAXM install packages for Windows are available from the Intel Hardware Accelerated Execution Manager GitHub releases page. Use the following steps to download and install HAXM:
From the Intel website, download the latest HAXM virtualization engine installer for Windows. The advantage of downloading the HAXM installer directly from the Intel website is that you can be assured of using the latest version.
Run haxm-N.N.N-setup.exe (where N.N.N is the version number) to start the HAXM installer. Accept the default values in the installer dialogs:
When you create a virtual device (see Managing Virtual Devices with the Android Device Manager), be sure to select an x86-based system image. If you use an ARM-based system image, the virtual device will not be accelerated and will run slowly.
Troubleshooting
For help with troubleshooting hardware acceleration issues, see the Android emulator Troubleshooting guide.
Accelerating Android emulators on macOS
The following virtualization technologies are available for accelerating the Android emulator:
Apple's Hypervisor Framework. Hypervisor is a feature of macOS 10.10 and later that makes it possible to run virtual machines on a Mac.
Intel's Hardware Accelerated Execution Manager (HAXM). HAXM is a virtualization engine for computers running Intel CPUs.
It is recommended that you use the Hypervisor Framework to accelerate the Android emulator. If the Hypervisor Framework is not available on your Mac, then HAXM can be used. The Android emulator will automatically make use of hardware acceleration if the following criteria are met:
Hardware acceleration is available and enabled on the development computer.
The emulator is running a system image created for an x86-based virtual device.
You can't run a VM-accelerated emulator inside another VM, such as a VM hosted by VirtualBox, VMware, or Docker. You must run the Android emulator directly on your system hardware.
For information about launching and debugging with the Android emulator, see Debugging on the Android Emulator.
Accelerating with the Hypervisor Framework
To use the Android emulator with the Hypervisor Framework, your Mac must meet the following criteria:
Your Mac must be running macOS 10.10 or later.
Your Mac's CPU must be able to support the Hypervisor Framework.
If your Mac meets these criteria, the Android emulator will automatically use the Hypervisor Framework for acceleration. If you are not sure if Hypervisor Framework is supported on your Mac, see the Troubleshooting guide for ways to verify that your Mac supports Hypervisor.
If the Hypervisor Framework is not supported by your Mac, you can use HAXM to accelerate the Android emulator (described next).
Accelerating with HAXM
If your Mac does not support the Hypervisor framework (or you are using a version of macOS earlier than 10.10), you can use Intel's Hardware Accelerated Execution Manager (HAXM) to speed up the Android emulator.
Before using the Android emulator with HAXM for the first time, it's a good idea to verify that HAXM is installed and available for the Android emulator to use.
Verifying HAXM support
You can check to see if HAXM is already installed by using the following steps:
Open a Terminal and enter the following command:
This command assumes that the Android SDK is installed at the default location of ~/Library/Developer/Xamarin/android-sdk-macosx; if not, modify the above path for the location of the Android SDK on your Mac.
If HAXM is installed, the above command will return a message similar to the following result:
If HAXM is not installed, a message similar to the following output is returned:
If HAXM is not installed, use the steps in the next section to install HAXM.
Installing HAXM
HAXM installation packages for macOS are available from the Intel Hardware Accelerated Execution Manager page. Use the following steps to download and install HAXM:
From the Intel website, download the latest HAXM virtualization engine installer for macOS.
Run the HAXM installer. Accept the default values in the installer dialogs:
Troubleshooting
For help with troubleshooting hardware acceleration issues, see the Android emulator Troubleshooting guide.
В этой статье приведены обходные пути для временных проблем с производительностью, сбоев продукта или отрисовки в Microsoft Visual Studio 2013.
Исходная версия продукта: Visual Studio 2013, 2015, 2017
Исходный номер базы знаний: 2894215
Симптомы
Если вы включили аппаратное ускорение или используете параметры визуального интерфейса по умолчанию в Visual Studio 2017, Visual Studio 2015 и Visual Studio 2013, могут возникнуть периодические проблемы с производительностью, сбои продукта или проблемы с отрисовки.
Причина
Эти проблемы могут возникать из-за ошибок в установленном графическом драйвере.
Команда Visual Studio продолжает заметить небольшое, но важное количество проблем с производительностью и надежностью, вызванных ошибками в установленных графических драйверах. По умолчанию Visual Studio настраивает визуальный интерфейс, чтобы максимально повысить производительность и скорость реагирования в конфигурациях клиентов. Visual Studio также использует аппаратное ускорение графики, когда оно доступно на клиенте. Для большинства клиентов эти параметры Visual Studio по умолчанию обеспечивают наилучшее взаимодействие с пользователем. Однако некоторые пользователи сообщили, что ручная корректировка этих параметров может привести к улучшению работы. В этой статье описывается, как внести эти изменения в Visual Studio.
Временные решения
Чтобы обойти эти проблемы, используйте один из следующих методов:
Установите последние графические драйверы.
Устаревшие драйверы являются распространенным источником проблем Windows Presentation Foundation (WPF).
Отключите аппаратное ускорение графики, чтобы переключиться на отрисовку программного обеспечения. Для этого выполните следующие действия:
В Visual Studio щелкните ToolsOptions > .
В диалоговом окне "Параметры" снимите флажок "Автоматически настраивать визуальный интерфейс на основе производительности клиента ". (См. следующий снимок экрана для этого шага.)
Снимите флажок "Использовать аппаратное ускорение графики", если он доступен, чтобы предотвратить аппаратное ускорение графики.
Установите или снимите флажок " Включить полнофункциональный визуальный интерфейс клиента", чтобы обеспечить постоянное или отключение расширенных визуальных элементов соответственно. Если этот флажок установлен, полнофункциональные визуальные элементы используются независимо от компьютерной среды. Например, расширенные визуальные элементы используются при запуске Visual Studio локально в полнофункциональных клиентах и на удаленном рабочем столе.
В этой статье объясняется, как использовать аппаратные функции ускорения компьютера для повышения производительности эмулятора Android.
Сценарий | HAXM | WHPX | Hypervisor.Framework |
---|---|---|---|
У вас процессор Intel | X | X | X |
У вас процессор AMD | X | ||
Требуется поддержка Hyper-V | X | ||
Требуется поддержка вложенной виртуализации | Ограниченный | ||
Требуется использовать такие технологии, как Docker | (С WSL2) | X | X |
Ускорение эмуляторов Android в Windows
Следующие технологии виртуализации доступны для ускорения эмулятора Android:
Microsoft Hyper-V и платформа гипервизора Windows (WHPX) .
Hyper-V — это функция виртуализации в Windows, которая позволяет запускать виртуализированные компьютерные системы на физическом главном компьютере.
Intel Hardware Accelerated Execution Manager (HAXM) .
HAXM — это механизм виртуализации для компьютеров на базе процессоров Intel.
Для оптимального взаимодействия с Windows рекомендуется использовать WHPX для ускорения эмулятора Android. Если WHPX недоступен на компьютере, можно использовать HAXM. Эмулятор Android автоматически использует аппаратное ускорение, если выполнены следующие критерии:
Аппаратное ускорение доступно и включено на компьютере разработчика.
Эмулятор выполняет системный образ, созданный для виртуального устройства на основе x86-64 или x86.
Нельзя запустить эмулятор на базе ускоренной виртуальной машины внутри другой виртуальной машины, например под управлением VirtualBox, VMware или Docker (если не используется WSL2). Эмулятор Android следует запускать непосредственно на системном оборудовании.
Сведения о запуске и отладке с помощью эмулятора Android см. в статье Отладка в Android Emulator.
Ускорение с помощью Hyper-V
Перед включением Hyper-V прочтите следующий раздел, чтобы убедиться, что компьютер поддерживает Hyper-V.
Проверка поддержки Hyper-V
Hyper-V работает на платформе гипервизора Windows. Чтобы использовать эмулятор Android с Hyper-V, компьютер должен отвечать следующим условиям для поддержки платформы гипервизора Windows:
Оборудование компьютера должно соответствовать следующим требованиям:
- 64-разрядный ЦП Intel или AMD Ryzen с преобразованием адресов второго уровня (SLAT).
- ЦП должен поддерживать расширения режима мониторинга виртуальной машины (VT-c на процессорах Intel).
- Не менее 4 ГБ памяти.
В BIOS компьютера необходимо включить следующие элементы:
- Технология виртуализации (может иметь другое название в зависимости от производителя системной платы).
- Предотвращение исполнения данных на основе оборудования.
Компьютер должен работать под управлением Windows 11 или Windows 10 версии 1909 или более поздней.
Чтобы убедиться, что компьютерное оборудование и программное обеспечение совместимо с Hyper-V, откройте командную строку и введите следующую команду:
Если все указанные требования Hyper-V имеют значение Да, компьютер поддерживает Hyper-V. Пример:
Если результат Hyper-V указывает на то, что гипервизор запущен, Hyper-V уже включен.
Включение ускорения Hyper-V в Windows и эмуляторе
Если ваш компьютер соответствует приведенным выше критериям, выполните следующие действия для ускорения эмулятора Android с помощью Hyper-V.
Введите компоненты windows в поле поиска Windows и выберите Включение и отключение компонентов Windows в результатах поиска. В диалоговом окне Компоненты Windows включите Hyper-V и платформу гипервизора Windows:
После внесения этих изменений перезагрузите компьютер.
В Windows 10 с обновлением за октябрь 2018 г. (RS5) и более поздних версий необходимо только включить Hyper-V, так как он будет автоматически использовать платформу гипервизора Windows (WHPX).
- Убедитесь, что виртуальное устройство, созданное в Android диспетчер устройств, является системным образом на основе x86-64 или x86. Если вы используете образ системы на основе Arm, виртуальное устройство не будет ускорено и будет работать медленно.
После включения Hyper-V вы сможете запустить ускоренный эмулятор Android.
Ускорение с помощью HAXM
HAXM поддерживается только на ЦП Intel.
Если компьютер не поддерживает Hyper-V, вы можете использовать HAXM для ускорения эмулятора Android. Чтобы использовать HAXM, отключите Device Guard.
Проверка поддержки HAXM
Чтобы определить, поддерживает ли оборудование HAXM, следуйте инструкциям из раздела Мой процессор поддерживает технологию виртуализации Intel?. Если оборудование поддерживает HAXM, проверьте, установлен ли HAXM:
Откройте окно командной строки и введите следующую информацию:
Посмотрите в выходных данных, запущен ли процесс HAXM. Если это так, вы увидите выходные данные с указанием intelhaxm состояния как RUNNING . Пример:
Если STATE не задано значение RUNNING , haXM не установлен.
Если компьютер может поддерживать HAXM, но HAXM не установлен, выполните действия, описанные в следующем разделе, чтобы установить HAXM.
Установка HAXM
Пакеты установки HAXM для Windows можно найти на странице выпусков GitHub, посвященной Intel Hardware Accelerated Execution Manager. Чтобы скачать и установить решение HAXM, выполните следующие действия:
Скачайте с веб-сайта Intel последнюю версию установщика подсистемы виртуализации HAXM для ОС Windows. Скачивая установщик HAXM с веб-сайта Intel, вы гарантированно получаете последнюю версию этой программы.
Чтобы начать работу с установщиком HAXM, запустите файл intelhaxm-android.exe. Примите значения по умолчанию в диалоговых окнах установщика.
При создании виртуального устройства обязательно выберите системный образ x86_64 или x86. Если вы используете образ системы на основе Arm, виртуальное устройство не будет ускорено и будет работать медленно.
Устранение неполадок
Сведения о решении проблем с аппаратным ускорением см. в руководстве по устранению неполадок для эмулятора Android.
Читайте также: