Всем доброго времени суток!

Насколько производительно работает Android Studio? Считаете ли Вы, что она работает шустро на Вашем ПК или Mac? Или, иногда, сталкиваетесь с лагами или долгой сборкой? А на крупных проектах?

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

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

Мотивация

Android Studio была неповоротливой еще во времена перехода с Eclipse. И уже тогда я начал искать способы оптимизации работы этой IDE. Однако, большинство коллег относилось к этому "никак". Работает. Не всегда быстро. И ладно.

Но вот уже год я работаю в другой компании. Климат другой, разработчикам читают доклады по разным технологиям. На одном из таких докладов мне показалось, что тема данной статьи может быть востребованной. Особенно в рамках проектов повышенной технической сложности.

Поговорив с коллегами и знакомыми разработчиками, мне стало понятно, что даже не каждый "профи" понимает нюансы работы железа, ОС и IDE. Потому здесь я постарался собрать полный ликбез на основе собственного опыта.

DISCLAIMER! Все упомянутые в статье модели и бренды не являются рекламой!

Железо

Вот что сказано о железе на официальном сайте Android Studio в графе System requirements (не считая дискового пространства):

3 GB RAM minimum, 8 GB RAM recommended; plus 1 GB for the Android Emulator
1280x800 minimum screen resolution

Этого достаточно, чтобы студия просто запустилась и работала. О каких либо производительности и комфорте здесь речи не идет.

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

Здесь для нас наиболее критичны 5 параметров:

• Производительность CPU
• Количество аппаратных потоков CPU
• Количество оперативной памяти
• Скорость произвольного чтения и произвольной записи дисковой подсистемы
• Скорость мелкоблочного чтения и мелкоблочной записи дисковой подсистемы

Поскольку я чаще работал на конфигурациях на базе продукции Intel, то далее речь пойдет о них. Однако, если у Вас AMD- просто при прочтении делайте для себя поправки на аналогичные технологии "красных". Единственный минус, с которым я сталкивался на AMD, уже был описан на Хабре.

Пара слов о Mac

Существует мнение, что Mac является лучшей машиной для разработки. Чаще так говорят о MacBook Pro.

Лично я считаю это мифом. С приходом технологии NVMe Mac растерял свою "магию". Так что сегодня, даже среди ноутбуков, Mac не является лидером по соотношению цена-качество-производительность. Особенно в контексте разработки под Android Studio.

В остальном для комфортной разработки имеет смысл MacBook Pro 2015 или 2016 года не с U-процессором. Об остальных характеристиках и обслуживании читайте ниже.

Процессор

По производительности процессора- очевидно и понятно. Чем она выше- тем лучше. Единственное, что нужно отметить- при наличии достаточно быстрого накопителя, слабый процессор станет "бутылочным горлышком" в Вашей системе. Особенно критично в случае NVMe-накопителя. Часто, при работе с ним, упор идет именно в мощности CPU.

С потоками всё немного сложнее. Читал о том, что пользователи снижают приоритет студии и ее подпроцессов, чтобы ОС "не зависала" во время сборки. Причина здесь одна- 1-2 аппаратных потока. Этого мало не только для IDE, но и для современной ОС. Единственное "но"- на моей практике были ситуации, когда двухъядерные U-процессоры с Hyper Threading (то есть 2 ядра на 4 потока) нормально работали с относительно мелкими проектами, но на крупных начинались вышеперечисленные проблемы.

Само собой, наличие аппаратной виртуализации обязательно.

Потому рекомендую смотреть в сторону Core i5 HQ Skylake c 4+ потоками и мощнее.

Оперативная память

По поводу стандартов- DDR3 и выше. Тут, думаю, понятно.

Если есть возможность работы в 2х или 4х-канальном режиме и у Вас они не активны- настоятельно рекомендую задействовать, так как можно получить существенную прибавку к отзывчивости IDE. Активируется эта возможность либо в настройках BIOS\UEFI, либо установкой дополнительных модулей оперативной памяти (если у Вас до сих пор один модуль).

Какой нужен объем? Для мелких (действительно мелких) проектов хватает 4ГБ. На проектах крупнее студия способна быстро занять 4ГБ памяти и больше. Добавим сюда эмулятор на HAXM (скажем 2 ГБ) и учтем, что современная ОС (за исключением некоторых дистрибутивов Linux) занимает в памяти около 2ГБ- и вот получается, что 8ГБ уже "впритык".

Это без учета, например, Slack (который занимает в среднем около 500 мб в памяти) и Chrome (там счет идет на гигабайты).

В целом, при 8ГБ оперативной памяти работать быстро и комфортно можно- спасает быстрый накопитель и swap\файл подкачки. Но стоит задуматься об апгрейде.

Потому компания закупает новые, либо предоставляет апгрейд текущих рабочих машин на 12ГБ RAM и более.

SSD

Дисковая подсистема является самым частым "бутылочным горлышком", потому на нее надо обращать внимание в первую очередь.

Работа с Android Studio на HDD в 2018 году сравнима с мучениями- чем больше проект, тем больше фризов Вам обеспечено. Потому, очевидно, использовать только SSD.

Как было упомянуто выше, здесь два критичных параметра:

• Скорость произвольного чтения и произвольной записи дисковой подсистемы
• Скорость мелкоблочного чтения и мелкоблочной записи дисковой подсистемы

Чем они выше- тем отзывчивее будет студия, и тем быстрее она будет загружаться и производить сборку.

Обращаю Ваше внимание, что о скоростях линейного чтения\записи речи не идет- для студии это не критично. Потому, при выборе накопителя, нужно смотреть не на его скорость чтения\записи на сайте производителя или магазина, а на количество IOPS (чем больше- тем лучше).

Само собой, здесь не идет речи о Mac, так как там накопитель либо имеет собственный стандарт либо просто распаян на плате. Замена возможна, разве что, на больший объем. Скоростные характеристики здесь поднять вряд ли получится.

NVMe

Если Вашей материнской платой поддерживается технология NVMe — то лучше использовать накопитель с ее поддержкой. Она позволяет получить скорости, сравнимые с SSD на Mac и выше.

При наличии скоростного накопителя, упор идет на шину PCIe и мощности Вашего CPU. Потому, если, например, Ваша материнская плата поддерживает вывод на накопитель PCIe 2.0x4\3.0x2 или у Вас не очень мощный CPU- не стоит покупать очень дорогой накопитель. Смотрите на возможности Вашей системы и толщину Вашего кошелька.

SATA3

Да, SATA3 живее всех живых. И на нем можно быстро работать на студии.

В этом сегменте скоростные накопители более доступны, потому имеет смысл сразу смотреть на топовые решения объемом 120 GB и выше.

Intel Optane

Использовать Android Studio на машине с данным накопителем (если его так можно назвать) мне не приходилось. Если у кого-то есть опыт- пишите в комментарии.

GPU

Тут много говорить не нужно.
Если пишете обычные пользовательские приложения- для самой студии и эмулятора чего-то вроде Intel HD 500 Series хватит за глаза.

Если Вы разрабатываете игры или это- Ваша личная машина, то имеет смысл дискретная графика. Какая- смотрите по Вашим потребностям.

Система охлаждения и троттлинг

Здесь речь не о апгрейде, а о обслуживании.

Большинству из нас известно такое явление, как троттлинг. Его реализацию применяют для защиты от перегрева.

Само собой, троттлинг ведет к понижению производительности. Не всегда заметному. В одних случаях работа Turbo Boost снижается до минимальных значений, в других начинается падение максимальных частот процессора. Причина- недостаточно эффективная работа системы охлаждения. Так же важно понимать, что большинство стресс-тестов (вроде AIDA) диагностируют штатную работу Turbo Boost как троттлинг.

В случае десктопных PC всё давно есть в сети. В случае мобильных систем, основанных на тепловых трубках, много противоречивой информации. Сюда относятся большинство ноутбуков, неттопов, MacBook и iMac. Далее речь пойдет именно о них.

На современных мощных мобильных CPU 80-90 градусов на кристалле под нагрузкой- это норма. При этом SOC с этими CPU имеют конструкцию с открытым кристаллом, от того площадь теплопередачи небольшая. Вся эта куча тепла отводится вот этим посмешищем подобной конструкцией с небольшим закрытым жидкостным контуром.

Нужно понимать, что такие системы охлаждения испытывают бОльшие нагрузки и нуждаются в более частом обслуживании. Особенно в случае ноутбуков и MacBook- при переноске от вибраций слой засохшей термопасты разрушается быстрее. А несвоевременное обслуживание чревато не только потерей производительности, но и протечкой термотрубок и "отвалами" кристаллов.

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

Из-за маленькой площади кристалла имеет смысл использовать диэлектрическую термопасту с высокой теплопроводностью (такая стоит в районе 800-1000 р за грамм). Ни в коем случае не используйте жидкий металл! Иначе отделить кристалл от пластины Вы, скорее всего, уже не сможете!

Если у Вас не хватает навыков для данной процедуры- лучше обратитесь в сервис.

Аппаратные настройки

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

Intel Hyper Threading

Это технология Intel, которая разделяет аппаратный поток ядра на два "виртуальных". Благодаря ей система видит 4-ядерный процессор как 8-ядерный. Такой подход позволяет эффективно утилизировать процессорные мощности. Аналогичная технология есть и у AMD.

Часто сталкиваюсь с тем, что у многих разработчиков эта функция отключена и они вообще о ней не знают. Однако, ее включение может повысить отзывчивость студии и производительность сборки. В отдельных случаях на 10-15%.

Включается она в настройках BIOS\UEFI Вашей материнской платы или ноутбука. Называется пункт аналогичным или похожим образом. Если Вы еще не знали о этой технологии- то имеет смысл проверить ее наличие и включить если этого не было сделано.

Intel Turbo Boost

Еще одна широко известная технология. По факту является автоматическим кратковременным разгоном CPU и дает существенный прирост при сборке. И, в то же время, имеет свойство раскалять мобильные процессоры до температур, не далеких от Tjunction.

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

Включаться она может как BIOS\UEFI, так и в настройках ОС.

Intel Rapid Storage

Поддержка этой технологии мат.платой крайне рекомендуется. Более подробно можно почитать здесь.

Могу порекомендовать только своевременно обновлять драйверы для этой технологии до самой свежей версии с официального сайта Intel. Даже если производитель Вашего ноутбука поставляет Вам драйверы более старых версий.

В моем конкретном случае, обновление с версии драйвера от производителя до актуальной, повысило скорость линейной записи примерно на 30%, а произвольной- на 15%.

Как устанавливать и обновлять драйверы IRST на Linux- я не знаю (и вообще, возможно ли это?). Если кто знает- пишите в комментарии, я с удовольствием дополню статью.

SSD Secure Erase

Производительность недорогих моделей SSD может со временем падать. Это не всегда происходит из-за "деградации" накопителя. Возможно, в Вашей модели TRIM реализован не очень эффективно.

Secure Erase заставит контроллер пометить все ячейки памяти пустыми, что, теоретически, должно вернуть производительность SSD к заводскому состоянию. И, также, сотрет все Ваши данные! Будьте аккуратны, делайте бекапы!

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

На одном из этапов, возможно, накопитель придется переподключить прямо во время работы. Потому, в случае M.2 очень желательно наличие переходника.

Использовать сторонние утилиты для этой операции крайне не рекомендуется.

Впрочем, если Ваш SSD существенно потерял в скорости за время менее года- лучше поменять накопитель на другую модель.

Аппаратная виртуализация

Эта технология необходима для быстрой работы x86-эмулятора. Если у Вас она отключена- включите ее в настройках BIOS\UEFI. У разных вендоров могут быть разные названия настроек.

Да, мы все знаем про Genymotion и BlueStacks, которые прекрасно обходятся без аппаратной виртуализации. Однако, в образах этих эмуляторов некоторые или многие реализации Android API сильно изменены с целью увеличения скорости работы. Это может провоцировать поведение, которое Вы никогда не встретите на реальном устройстве. Или при отладке Вы можете упустить пару багов. Потому наличие рабочего и шустрого AVD крайне желательно.

ОС и Сторонний софт

В этой главе речь пойдет о возможной настройке ОС и установке стороннего софта с целью увеличения производительности.

Индексация

Здесь речь пойдет о поиске Windows и Spotlight на Mac OS. Эти механизмы могут отнимать до 15% мощностей CPU при сборке поскольку пытаются индексировать всё, что генерируется в /build.

Само собой, из под индексации необходимо исключить все директории, с которыми работает студия:

• Директория SDK
• Директория студии
• Директория проектов (крайне рекомендуется)
• ~/.gradle
• ~/.android
• ~/Android StudioX.X
• ~/lldb
• Директория кеша Kotlin

Антивирус

Знаю, не у всех в среде разработки принято использовать антивирус. Но многие его используют. В том числе, иногда, на Linux и Mac OS. И его использование совершенно оправдано.

Даже если у Вас Windows 10 и нет антивируса- его функции выполняет Windows Defender.

При сборке антивирус может отнимать очень существенную долю CPU. Потому все директории, перечисленные в графе "Индексация", следует добавить в исключения антивируса. Также, в исключения имеет смысл добавить имена процессов самой студии и JetBrains JVM.

В зависимости от реализации антивируса, потребление CPU им во время сборки снизится существенно, либо он вообще перестанет потреблять мощности CPU. А время самой сборки заметно уменьшится.

Шифрование диска или домашней директории

Эти функции присутствуют на всех популярных ОС или реализуются сторонним софтом. Само собой, работа студии в шифрованном файловом пространстве может требовать бОльших мощностей CPU. Насколько- зависит от реализации шифрования. Потому рекомендуется такие функции отключать либо совсем, либо, если это возможно, для перечисленных в графе "Индексация" директорий.

А работает ли TRIM?

TRIM может быть реализован как аппаратно, так и программно. В последнем случае обязанность вызова TRIM ложится на ОС. И, по разными причинам, периодический вызов может отключаться, что приводит к падению скорости накопителя.

Проверить работоспособность и возобновить вызовы TRIM можно с помощью специализированных утилит. Рекомендуется использовать утилиты от производителя накопителя.

RAMDisk

Что такое RAMDisk большинству давно известно. Но насколько он эффективен в работе со студией?

По своему опыту скажу- не очень. Разве что Вы перенесете в RAMDisk сам проект, SDK, студию и так далее. Если у вас хватает RAM...

С простым переносом проекта весом в более чем 500 мб (цифра указана с build-кэшем), у меня не получалось добиться прироста более 15%. По всей видимости, тормозятся вызовы к SDK и системным API. В итоге такой прирост обходится достаточно дорого.

Следующий способ существенно эффективнее и обходится куда дешевле.

Кэширование запросов к накопителю

Нечто похожее реализовано в Mac OS. Однако, в сравнении с перечисленными ниже технологиями- не настолько эффективно.

К сожалению, мне известны только две реализации, и обе жестко завязаны на продукцию производителей. Речь о Samsung R.A.P.I.D. и PlexTurbo.

Обе технологии работают по схожим принципам (описываю так, как понял сам):

• Если был запрос на чтение небольших объемов, то они откладываются в RAM и при повторном чтении берутся уже оттуда. Стандартный RAM cache.
• Если был запрос на запись небольших данных- они откладываются в RAM-кэш. Далее запросы на запись сравниваются с кэшем. Если Вы повторно пишете одни и те же данные по одним и тем же путям- зачем их повторно записывать аппаратно? И SSD так дольше проживет.

Единственная разница- R.A.P.I.D. использует свободный остаток оперативной памяти в качестве кэша. Меньше остаток- меньше размер кэша, меньше ускорения. PlexTurbo позволяет ограничить максимальный объем кэша и подгружать его с жесткого диска при старте системы.

В случае использовании на SATA 3 можно получить прирост до 50%. При использовании NVMe-накопителя- меньше, но, часто, тоже существенный.

В данный момент у меня в работе Samsung 860 EVO SATA 3. Под спойлером бенчмарки с i7 6700HQ и отключенным Turbo Boost.

Наглядно видно, как система начинает кэшировать данные на первом прогоне. Итоговый результат существенно выше показателей SATA 3. Однако, эффективность работы данной технологии больше зависит от мощностей CPU. Что наглядно видно при включении Turbo Boost.

Синтетика- это, конечно, хорошо. Но это всё работает при чтении\записи повторяющихся мелких файлов. И это- самые частые операции при работе Android Studio.

У меня сейчас в работе проект суммарным с кэшем весом более 700 MB, состоящий из 10 модулей. Один из модулей- собственный кодогенератор на базе kapt с весьма тяжелой логикой. Два NDK-модуля, один из которых ссылается на Boost по внешнему пути. Остальное- тонны Kotlin-кода.

Если сравнить время полного ребилда данного проекта, то результаты следующие:

• С выключенным R.A.P.I.D. время составило 1m 47s 633ms. Терпимо.
• С включенным R.A.P.I.D. первый ребилд прошел за 1m 41s 633ms. Укладывается в погрешность.
• С включенным R.A.P.I.D. второй ребилд прошел за 1m 7s 132m. Вот и прирост. Чуть больше 37%, что существенно. Дальнейшие ребилды показывают еще меньшее время но уже с разницей не более 3-5 секунд от последнего замера. Что несущественно.

В менее длительных процессах прирост в студии заметен сразу.

Как итог можно рекомендовать эти технологии и накопители как хороший способ повысить производительность. По стабильности нареканий не возникало.

Android Studio

Многие из этих советов взяты отсюда и дополнены моими комментариями. Остальные- результат моих изысканий и опыта.

Обновления

Совет хоть и банальный, но всегда актуальный. Если у Вас не legacy-проект, то, по-возможности, старайтесь держать версии студии и сопутствующих компонентов (таких как Gradle, Android Plugin, Kotlin Plugin) в актуальном состоянии. Google и JetBrains делают много работы в плане оптимизации скорости работы и сборки в новых версиях.

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

В некоторых случаях нужно выполнить File->invalidate caches and restart после отката. Если обновляете саму студию- лучше сделать бекап директории студии и директории настроек. Это актуально в том случае, если Ваш проект содержит какие-либо костыли нестандартные подходы, чувствительные к механизмам сборки или самой студии.

Структура проекта

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

Однако, не возводите всё в абсолют. Выносите компоненты в модули осмысленно, думайте своей головой.

Instant Run

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

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

Включить и отключить функцию можно в меню Build, Execution, Deployment -> Instant Run флагом Enable Instant Run.

Attach to Process

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

Потому, если на устройстве актуальный билд и перед отладкой никаких изменений вносить в код не требуется- смело жмем Attach debugger to Android process.

Gradle build configs

При возможности, если на Вашем основном рабочем buildConfig или flavour есть компоненты, которые используются только в release-сборках (например, crashlytics, различные annotation-процессоры или собственные gradle-процедуры)- отключите их для debug или для Вашего отладочного конфига. Как это сделать- можно найти здесь, либо на официальных страницах компонентов, либо просто загуглите.

В случае, если у Вас кастомный buildConfig, то для него следует отключить PNG crunching, так как по-умолчанию эта опция выключена только для debug-конфига. Эта опция применяет компрессию к png при сборке. Отключить ее можно следующим образом:

android {
   buildTypes {
       myConfig {
           crunchPngs false
       }
   }
}

//Для старых версий android plugin
android{
   aaptOptions {
       cruncherEnabled false
   }
}

WebP

Если minimum api level Вашего проекта больше 18, то имеет смысл конвертация изображений в WebP. Этот формат более компактный, быстрее читается и к нему не применяется компрессия во время сборки. Потому конвертация всей растровой графики в проекте рекомендуется всегда. Соответственно, чем больше растра в Вашем проекте- тем меньше время сборки после конвертации.

Параллельная сборка

Если Ваш проект содержит несколько независимых модулей (например, несколько app-модулей), то для него будет актуальной опция Compile independent modules in parallel в Settings->Build, Execution, Deployment -> Compiler. Это позволит более эффективно утилизировать потоки CPU при сборке. Минус- больший heap size и, как следствие, больший расход оперативной памяти.

Так же эту опцию можно включить посредством строчки в gradle.properties

org.gradle.parallel=true

Gradle daemon

Эта опция в свежих версиях студии включена по-умолчанию и этот совет для тех, кто до сих пор ее не задействовал.

Данная опция позволяет держать отдельный инстанс jvm и gradle в оперативной памяти в течении трех часов с момента последней сборки. Таким образом не тратится время на их инициализацию и наращивание кучи. Минус- больший расход оперативной памяти. Включается строчкой в gradle.properties

org.gradle.daemon=true

Offline-сборка

При сборке Gradle периодически проверяет web-ресурсы зависимостей, чтобы их разрешить. Можно отключить данное поведение. Этот совет подходит для тех, кто имеет медленное интернет-соединение или соединение с большими задержками.

В меню Build, Execution, Deployment -> Gradle отмечаем чекбокс Offline work.

Увеличение heap size Android Studio или IDEA

Такая опция пригодится для больших проектов. По умолчанию в студии указан xmx1280m (тем не менее, вместе с подпроцессами студия поглощает RAM сильно больше). Маленький максимальный размер кучи может провоцировать более частые вызовы GC и, тем самым, замедлять работу.

Увеличить стартовый heap size можно как самой студии, так и Gradle.

Для Gradle пишем в gradle.properties

org.gradle.jvmargs=-Xms1024m -Xmx4096m

что соответствует 1ГБ стартового размера кучи и максимума в 4 ГБ для наращивания. Подберите размер в соответствии с ресурсами, которые хотите выделить из доступных Вам.

Для самой Android Studio или IDEA идем в меню Help -> Edit Custom VM Options и пишем те же JVM-параметры с нужными Вам объемами.

Этими же способами можно корректировать поведение JVM в случае, если у Вас возникают с ней какие-либо сложности. Полный список аргументов можно получить с помощью команды java -X.

Плагины

Нет каких либо плагинов, которые могут ускорить IDE. А вот избавиться от пары-тройки можно. Это может повысить отзывчивость или уменьшить время запуска. Особенно если Вы установили несколько сторонних.

Конкретных рекомендаций здесь давать не буду- потребности у всех разные. Просто идете в Settings -> Plugins и отключаете то, что вам не нужно, внимательно прочитав описание и очень хорошо подумав. Не факт, что Вам вообще нужно что-то отключать.

Inspections

Отключение некоторого количества пунктов в меню Settings -> Editor -> Inspections может повысить отзывчивость IDE. Иногда существенно.

Здесь тоже не будет конкретных рекомендаций, отключайте с умом. Помните- Вы не робот и допускаете ошибки, а инспекции помогают Вам их избежать.

Power Save mode

Активация этого режима находится в меню File. В нем отключаются все фоновые процессы (индексация, статический анализ кода, Spell Checking и т.д.). И студия начинает вести себя заметно шустрее. Но и по функционалу становится не сильно лучше, например, VS Code.

В общем режим для ситуаций, когда всё совсем плохо.

Settings Repository

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

Если Вы работаете в команде с утвержденным codestyle- то новому разработчику будет удобно сделать свою ветку в Git, поменять в ней copyright и настройки для своей машины, и использовать те же настройки codestyle вместе со всеми остальными.

Можно, конечно, коммитить .idea в репозиторий, но это- плохой подход.

AVD

С самого начала своего существования AVD был неповоротлив и прожорлив. В последние 3 года он был сильно усовершенствован, что позволило запускаться и работать на современных машинах относительно быстро (хотя бы в x86-варианте).

И тем не менее, даже сегодня x86-версия Pie на AVD умудряется тормозить. Даже на мощных железках. Ниже представлены варианты, как исправить ситуацию.

Само собой, включение аппаратной виртуализации и установка HAXM с выделением минимум 2 ГБ RAM обязательны.

В случае, если AVD сильно загружает CPU и при этом тормозит- боюсь, уже ничего не сделать. Однако, если нагрузка на CPU остается не высокой- значит дело в графической подсистеме.

Чаще всего это происходит из-за некорректного определения наиболее подходящего для Вашей машины рендера. Вы можете вручную выбрать наиболее подходящий в меню Settings -> Advanced эмулятора. Конкретные настройки подсказать не смогу, так как всё зависит от конфигурации железа и ОС. Просто смените пункт, закройте эмулятор и вызовите Cold Boot. Остановитесь на наиболее подходящем для Вас варианте.

При наличии дискретного GPU можно попробовать запустить эмулятор на нем, так как по-умолчанию эмулятор запускается на том же GPU, который обрабатывает рабочий стол. Делается это так же, как и с любой игрой. После не забудьте вызвать Cold Boot.

Итог

Так или иначе, не все перечисленные пункты обязательны к применению. Старайтесь решать проблемы по мере их обнаружения.

Время- самый ценный ресурс. Надеюсь, этот материал поможет Вам более продуктивно его расходовать.