Комфортная работа с Android Studio


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


Насколько производительно работает 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.


860 EVO до включения R.A.P.I.D. и два прогона после

R.A.P.I.D. выключен



Первый прогон



Второй прогон



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


860 EVO + R.A.P.I.D. + 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. Остановитесь на наиболее подходящем для Вас варианте.


Меню выбора рендера в AVD


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


Итог


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


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

Реклама
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее

Комментарии 21

    +1
    Могу добавить, что тормозной телефон может многократно увеличивать время установки и запуска приложения на себе.
      0
      Согласен. Но часть этого времени уходит на передачу APK по ADB. Этап Installing apk длится достаточно долго если девайс общается с ПК по USB 2.0. Для отладки желательно иметь USB 3.0-3.1 type A или type C на ПК и девайс с type C с той же реализацией. Есть еще девайсы с USB 3.0 и type B, но из таких помню только SGS 5.

      В общем, такая конфигурация дает большую вероятность того, что установка пройдет мгновенно т.к. медленные ПЗУ с контроллером 3.0 ставят редко. На руках Nokia 6.1. Время билда до полного запуска (проекта, который в статье) около 3х секунд.

      0
      Пока любая уважающая себя IDE запускается и прилично вертится на калькуляторах средней древности, разработчики AS не только не считают унизительной такую производительность, но еще и ухудшают ее год от года. What a time to be alive.
        0
        любая уважающая себя IDE запускается и прилично вертится на калькуляторах средней древности
        Можно пример?
        Просто по функционалу с IDEA-based может сравниться наверно только Visual Studio. И та в той же мере прожорлива и неповоротлива. XCode по-легче, но и функционал там по-беднее. Что тогда?
        0

        Ну ещё можно посоветовать для JVM опцию включить -XX:+UseG1GC.

          +1
          До Вашего комментария не приходила в голову идея использовать G1. Попробовал ради интереса.
          К сожалению, только с этим параметром студия не запускается. Но сразу нагуглил решение в виде
          -XX:-UseParallelGC
          -XX:-UseConcMarkSweepGC
          -XX:+UseG1GC

          Так же добавил только этот параметр в jvmargs gradle.
          Не могу сказать, что увидел прирост- ребилд в пределах погрешности, в краткосрочных операциях тоже изменений не увидел. Может получится увидеть разницу в долгосрочной перспективе
          0
          SSD решает большинство проблем со временем запуска и компиляции. Конечно, если ПК не с 2Гб RAM.
            0
            Согласен, любой SSD дает серьезный прирост. Но есть много дешевых и дорогих моделей, которые проектируются только для достижения высокой линейной скорости чтения или записи, что, в контексте работы AS, большой роли не играет
              0
              Скорее всего в обзорах отметят такую особенность и не поставят высокую оценку.
            0
            Еще две опции в Windows о которых не все знают «Enable write caching on the device»/«Turn off Windows write-cache buffer flushing on the device».
            Они должны влиять на производительность записи на диск, но на сколько сильно, я не проверял.
            Включать опции можно только если у ПК есть ИБП (батарея).
              0
              Попробовал. С включенным RAPID результат ухудшился. А вот с выключенным есть прирост около 20 секунд при полном повторном ребилде. Это не так много, но ощутимо. Так что мера рабочая.

              Но в надежности есть сомнения. Я бы поостерегся в такой конфигурации работать даже с ИБП. Потеря данных дороже обойдется.
              0
              Проделал те же манипуляции с Visual Studio — ощутил прирост, хотя думал, что и так все достаточно быстро работает по сравнению с предыдущими ПК. Спасибо за статью!
                0
                По-моему, весь камень преткновения заключен в используемом железе. Рассчитывал узнать что-то большее из этой статьи
                  +2
                  В плане ускорения сборки — мои эксперименты (может и пригодится кому то).

                  Софт:
                  • Android studio 3.6.3 stable, в vmoptions добавлено -Xmx4096m
                  • Dataram RAMDisk 4.4.0.36, опция про background update при создании диска ставилась(как бы день с git checkout начинать не стоит все же), диск создавался на системном M.2 SSD (потому что программа не умеет по другому либо этот диск надо монтировать руками каждый раз).
                  • SoftPerfect RAMDisk 4.1.0,'Hard drive emulation' при создании диска — выключен, галочка сохранять содержимое стоит, и отдельно стоит галочка сохранять содержимое каждые 60 мин, настройки про NUMA-ноду не включены

                  Все диски в NTFS
                  Системный M.2 SATA SSD Samsung 860 EVO M.2 250 Gb
                  'Второй' SATA SSD Smartbuy 480Gb
                  Возможности в NVMe — нет

                  Диск во всех случая — в NTFS.

                  Каталог проекта после сборки где то 3.5 Gb (сразу после checkout/после clean — 1.3 Gb)
                  org.gradle.caching=true,
                  android.enableBuildCache=true,
                  kapt.incremental.apt=true,
                  org.gradle.parallel=true,
                  kapt.incremental.apt=true
                  20+ модулей
                  Менять что-то в файлах проекта если нет возможности обосновать текущей задачей — придется объяснять на code review.
                  Проект в процессе сборки пытатся качать например material-null и так далее (видимо ошибка в конфигах)

                  Все каталоги в исключениях Windows Defender, 64 Gb RAM, Win 10, Ryzen 5 1600 6 core
                  В фоне до кучи всего висит. Включая хром с парой сотен вкладок.

                  В примерах где RAMDisk 6 Gb — там одновременно запущены и DataRam и SoftPerfect и их диски смонтированы. В примерах с 24 Gb RAMDisk — только SoftPerfect загружен.
                  Запускалось сборка несколько раз и средняя бралась в уме
                  • Исключения в Windows Defender НЕ прописаны. .gradle на системном M.2 SATA SSD + проект (где то 3.5 Gb со всеми сборочными каталогами) + Android SDK + AndroidSDK Home на втором SATA SSD — full rebuild примерно 8 минут
                  • .gradle на системном M.2 SATA SSD, проект на Dataram RAMDisk (диск 6 Gb), Android SDK + AndroidSDK Home на втором SSD. сжатие для RAM Disk НЕ включено. full rebuild примерно 4 минуты
                  • .gradle на системном M.2 SATA SSD проект на SoftPerfect RAMDisk(диск 6 Gb, '),Android SDK + AndroidSDK Home на втором SSD. Cжатие для RAM Disk НЕ включено. full rebuild примерно 4 минуты (хотя по CrystalDiskMark он быстрее в 3 раза чем Dataram)
                  • SoftPerfect RAMDisk(24 Gb, настройки те же), .gradle и проект на RAM Disk, ,Android SDK + AndroidSDK Home на втором SSD. Сжатие для RAM Disk НЕ включено. Full rebuild примерно 2 минуты 30 секунд
                  • SoftPerfect RAMDisk(24 Gb), .gradle и проект на RAM Disk ,Android SDK + AndroidSDK Home на втором SSD. Включено сжатие NTFS для RAMDisk. Full rebuild — нет существенно разницы с предыдущим пунктом.
                  • SoftPerfect RAMDisk(24 Gb), .gradle и проект на RAM Disk ,Android SDK + AndroidSDK Home на втором SSD. Включено сжатие NTFS для RAMDisk. Чекбокс Offline work — стоит. Full rebuild 1 минута 30 секунд
                  • SoftPerfect RAMDisk(24 Gb), .gradle на RAM Disk ,Android SDK + AndroidSDK Home на втором SSD, проект тоже на на нем же (ну — для проверки), включено сжатие NTFS и все файлы на RAMDisk — сжаты (на SSD — нет). чекбокс Offline work. Full rebuild — скачет — 3 — 4 минуты 4 минуты 10 секунд

                    +2
                    Дополнение к прошлым замерам.
                    Android Studio 4.0
                    Проект немного эволюционировал.
                    PrimoCache 3.2.0 подцеплен

                    • .gradle ,Android SDK, AndroidSDK Home, проект на втором SSD. Чекбокс offline work не стоит. Rebuild — 3m 30s — 4m 30s
                    • Подключен PrimoCache 3.2.0 (22 Gb L1 кэш, L2 нет) 16 Kb block, включен defer-writes с latency 10 секунд, все равно бесперебойник есть и бекап тоже есть раз в сутки), .gradle ,Android SDK, AndroidSDK Home, проект на втором SSD. Чекбокс offline work не стоит. Rebuild — 3m 20s — 3m 30s — и смысл?, ну кроме того что время пересборки не скачет, кэш по статистике в GUI PrimoCache используется где то процентов на 30. Изменение block size не особо меняет результат.
                    • Подключен PrimoCache 3.2.0 (22 Gb L1, L2 нет, 16 Kb block, включен defer-writes с latency 300 секунд), .gradle ,Android SDK, AndroidSDK Home, проект на втором SSD. Чекбокс offline work не стоит. rebuild 3m 30s — особого смысла поднимат latency — нету
                    • Подключен PrimoCache 3.2.0 (22 Gb L1, L2 нет, 16 Kb block, включен defer-writes с latency 300 секунд, .gradle ,Android SDK, AndroidSDK Home, проект на втором SSD. Чекбокс offline work стоит. rebuild 3m 30s — в gradle offline в данном случае тоже мало смысла
                    • Подключен PrimoCache 3.2.0 (22 Gb L1, L2 нет, 16 Kb block, включен defer-writes с latency 300 секунд), .gradle ,Android SDK, AndroidSDK Home, проект на втором SSD. Чекбокс offline work не стоит. rebuild 3m 30s — особого смысла поднимать latency — нету

                    Особо роста эффективности full rebuild от PrimoCache нет (обычные debug запуски, пуск эмуляторов — чуть побыстрее). И от памяти выделенной — не зависит.

                    Замечание — это именно в плане сборки, для некоторых других, не имеющих отношения к разработке, задач, PrimoCache помогает неслабо (хотя бы тем что, что там данных под сотню гигабайт, активная работа со считанными гигабайтами обычно но вот только — обычно).
                    Замечание 2 — 22 Gb кеша для PrimoCache — избыточно (он все равно в лучшем случае чуть больше половины использует)
                    Замечание 3 — L2 кэш запросто может замедлить (для тестов получилось только внешний USB3 SSD найти на 256 Gb — получалось незначительное замедление) — ну L2 кеш это для HDD видимо а на этой машине HDD это только диск для бекапов.

                    Интересно, Intel Optane, в PCIe 3.0 x1 (потому что у меня нет других свободных слотов, только пара x1, x16 занят видеокартой) — поможет (если туда содержимое 'второго SSD' скопировать)?
                      +1
                      Android Studio 4.0.1, эволюция того же проекта, со скоростью сборки стал творится ужас, 20+ минут не редкость (и уже вопросы что делать раздаются). Для меня рамдиск в 26gb все же слишком большие затраты памяти.

                      Новые эксперименты:
                      — без ramdisk'ов/PrimoCache, но в %HOME%/.gradle/gradle.properties добавлено
                      org.gradle.jvmargs=-Xmx4096M -Dkotlin.daemon.jvm.options\="-Xmx10240M" — XX\:MaxPermSize\=10240m + принудительно включен gradle daemon
                      (в самом проекте gradle.options использует значительно меньшие лимиты и демон отключен — есть причины) — full rebuilld от 8 до 20 минут. а вот make project/run debug — 1-4 минуты.

                      Ну и для интереса (использовать это я пока не могу — эмулятор ж не запустить из WSL, а для запуска на устройстве надо решить кое какие проектоспецифичные проблемы)

                      Android Studio 4.0.1 for Linux, WSL2, дефолтное ядро WSL2, Ubuntu 18.04 из MS Store(обновленная), X Server — X410 (тоже из MS Store), в оконном режиме.
                      — проект на ФС WSL (а не монтированной через /mnt/ ФС хоста), без правки gradle.properties:
                      full rebuild 16m, make project 19s
                      — проект на ФС WSL (а не монтированной через /mnt/ ФС хоста). c правкой gradle.properties как выше: нет существенных отличий

                      — проект на /mnt/ (ФС хоста монтированная) — gradle sync проекта идет более 6 минут (который во всех остальных случаях шел менее минуты). не вижу смысла дальше что-то мерять

                        0
                        У меня давно подозрение, что дело идет к тому, что разработчики AS предполагают, что компилировать приложение будут на неком удаленном сервере, а за терминалом просто пишут код. Возможно даже планируется коммерческая опция — загрузи на Google Play код и приложение автоматически скомпилируется и опубликуется.
                          +1

                          Дополнение очередное.
                          Проект в стадии активного выкидывания всего в модули, очередного редизайна.
                          Android Studio 4.1.2 теперь как основная.


                          Замеры (указаны более менее средние числа)
                          • Mac Mini 2020 (Apple Silicon)/16 Gb RAM + Android Studio 4.1.2: full rebuild 13m, после правок в app 3m
                          • Mac Mini 2020 (Apple Silicon)/16 Gb RAM + IDEA 2021.1 Beta EAP CE for Apple Silicon / Project JDK:Azul 15 for Apple Silicon: full rebuild: 12m, после правок в app 1m 20s
                          • Mac Mini 2020 (Apple Silicon)/16 Gb RAM + IDEA 2021.1 Beta EAP CE for Intel / Project JDK:Azul 15 for Intel: full rebuild: 16m, после правок в app 2m 20s
                          • Mac Mini 2020 (Apple Silicon)/16 Gb RAM + IDEA 2021.1 Beta EAP CE for Apple Silicon / Project JDK: встроенный: сборка работает странно. очень. Ну правда это EAP. Full rebuild:14m если соберется, после правок в app — 40s-1m 30s
                          • та же Win10 машинка что и раньше (проект на дополнительном SSD, SDK и прочее — на системном), все SATA(в NVMe эта машинка не умеет)/Android Studio 4.1.2 / Project JDK: встроенный: full rebuild 18m, после правок в app 3m
                          • Mac Mini Late 2012. 16 Gb RAM (Больше не лезет), Samsung 860 EVO 1 Tb (lifetime left где то 50%, Android Studio 4.1.2 / Project JDK: встроенный: full rebuild:26m, после правок в app — 1m 40s

                          Возможные недостатки теста:
                          • не проверялась та же сборка IDEA на остальных машинах. Но вообщем то
                          • все SSD в тестах кроме как на новом Mac Mini — SATA. Нет возможности проверить на машинках с NVMe.

                          Замечания
                          • Android Emulator на Apple Silicon не было даже желания проверять. WiFi debugging на реальных устройствах.
                          • Кэш gradle — чистился.
                          • у других разработчиков проекта — цифры примерного того же порядка.
                          • в том файле viewmodel что правился в app — куча даггровских инжектов в контструктор и он сам по себе 'мелкий'. Всего то ~1800 строк.

                          Модификации для сборки в IDEA на Apple Silicon / вообще
                          • Пришлось править (возможно это повлияло на результаты), модификации делятся на 2 группы:


                            • правки самого кода проекта (там есть странности которые мешают собирать в IDEA, быстрее было повырубать например некоторые тесты)


                            • адаптация под Apple Silicon:


                            • Room:


                              • перед kapt "androidx.room:room-compiler:${versions.room}"


                              • во всех gradle файлах добавлено


                              • //Temp fix for M1 per https://issuetracker.google.com/issues/174695268
                                kapt("org.xerial:sqlite-jdbc:3.34.0")

                              • иначе вылетает No native library is found for os.name=Mac and os.arch=aarch64. path=/org/sqlite/native/Mac/aarch64



                            • Protobuf:


                              • в https://github.com/protocolbuffers/protobuf/issues/8062 сказано что сборки будут через некоторое время (а у нас еще и не последняя версия).


                              • качаю нужные для Intel бинарники (система скажет какие) и /usr/loca/bin а затем правлю .gradle-файл (собрать рукам быстро — не получилось, с Ruby на Apple Silicon какие то отдельные заморочки если без Rosetta 2, а в сборке Protobuf он используется) примерно по мотивам


                              • protobuf {
                                  protoc {
                                      //M1 fix, надо локально собранный/скачаный protoc 3.0.0  который запустится на машине
                                      //это может быть обычный x86-64-protoc
                                      path = '/usr/local/bin/protoc'
                                      //artifact = 'com.google.protobuf:protoc:3.0.0'
                                  }
                                  plugins {
                                      javalite {
                                          //M1 fix, надо локально собранный/скачаный protoc 3.0.0  который запустится на машине
                                          //это может быть обычный x86-64-protoc
                                          path = '/usr/local/bin/protoc-gen-javalite'
                                          //artifact = 'com.google.protobuf:protoc-gen-javalite:3.0.0'
                                      }
                                  }

                              • решение конечно только для тестов. для вливания в dev — тут надо как то по другому решить вопрос.





                          Выводы
                          • возможная ошибка при импорте проекта в IDEA (похоже что-то лишнее собирается)
                          • Mac Mini / Apple Silicon рулит (еще бы стоил подешевле). Но очень возможно что например win-машинка с быстрыми NVMe была бы лучше. И вероятно — дешевле (тем более что видеокарта бы точно переехала в новую, а в старую встала бы заглушка 1050)
                          • Rosetta 2 работает очень очень хорошо в данном случае.
                          • особого смысла даже на Apple Silicon вот так срочно на IDEA CE Beta for Apple Silicon видимо нет, с учетом необходимых правок.
                            0
                            Спасибо большое. Думаю многим эти замеры пригодятся.
                            По поводу мини на m1 — при том же энергопотреблении и тепловыделении на x86, наверно, ничего собрать не получится. Однако, если не учитывать этот параметр, правильно подобранная машина на NVME будет быстрее за те же деньги.
                            Мини хорош для небольших и средних проектов. Единственный минус, который вижу — максимальный объем RAM в 16GB. Для крупных долгостроев этого уже будет мало.
                              0

                              IDEA у меня был выставлен объем 2048 Mb.
                              AS везде в 1920 Mb
                              Жалоб не было от IDE.
                              Открывается только не очень быстро.


                              У мака еще преимущество в том что "правильно подбирать" не надо и рисков ошибиться поменьше.
                              Вот только даже эту машину с 16 Gb не так просто было купить (диск там тоже не 256 Gb). Это хорошо что ситилинк берет заказы вообщем то на любые конфиги и доставляет в разумные сроки.


                              А энергопотребление меня волнует только в том плане что на mac mini с m1 новом сейчас (браузер и прочее, по сути в покое) температура('общий' индикатор iStat Menus) 34 градуса. При сборке проекта — 50 градусов.


                              на старом (Late 2012) — 65-70 градуса (опять же по сути в покое) (ладно, возможно мой цвет волос -:) повлиял при монтаже SSD и было нарушено обтекание воздуха). Кулер при этом уже не родной (старый тупо сдох) и работает он на 4500-5500 оборотов. и 99 градусов и 5500 оборотов при сборке проекта.

                              0

                              Mac Mini 2020 (Apple Silicon)/16 Gb RAM + Android Studio 4.1.2
                              Проект перенесен на подключенный по USB Samsung T5 SSD 1 Tb (он USB3 с внутренним SATA ), gradle cache и Android Studio — на прежнем месте — full rebuild — 15m (одна из причин зачем это может быть надо — у как минимум некоторых macmini m1, включая мой, ресурс SSD расходуется достаточно активно, а он там — не заменяемый).


                              С Samsung X5 (который TB3 с внутренним NVMe) пока нет возможности потестить.

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

                        Самое читаемое