Android studio improve performance

⚡ Is Your Android Studio Always Slow? 🚀Here’s How to Speed Up Immediately.

A very quick and effective trick to boost Android Studio

As an android developer, we get to spend a huge chunk of our time on Android Studio, the Google’s official compiler for developing native Android apps. Over the years, it has evolved into a very powerful IDE with lots of features and functionalities. But there are still some problems, which hasn’t been fixed yet for a lots of developers due to various reasons such as Gradle build time, Android Studio speed etc.

There have been many articles including official documentation on how to speed up. Some works and some not. But this article is not about gradle build time. Rather this is about more common but frustrating problem: slow Android Studio. Let’s see how to speed it and make it faster in some very easy ways.

There is a supporting video for this blog post if you would prefer to learn about this trick to speed up Android Studio.

⚙️ Android Studio Requirements

According to Android Studio’s official system requirements, it takes at minimum 3 GB RAM to run smoothly. Honestly, its a lot and I believe that is the biggest cause of being it too slow all the time.

The android developers are always complaining about the speed of Android Studio and how its slow ALL THE TIME. This makes overall development slow and frustrating. It affects productivity negatively.

So enough chit chat. Let’s see how to make it a lot faster in a very easy way.

🚀Speeding Up Android Studio

You might have read different tricks such as Offline Gradle, increasing memory in gradle.properties file, disabling Instant Run and so on. Let me show you a very easy way, shared by none other than Jake Wharton on Reddit about a year ago.

So, let me show you how to do this.

First, click on File -> Settings -> Plugins to open dialog like this.

Now, disable or Check Off all the plugins which not usable for you. I have disabled following:

Источник

Improving build speed in Android Studio

Posted by Leo Sei, Product manager on Android Studio

Improving Build speed

In Android studio, we want to make you the most productive developer you can be. From various discussions and surveys with developers , we know that waiting for slow build speed takes away from that productivity.

In this article, we’ll share some of the new analytics* we’ve put in place to better pinpoint what is really affecting build speed and share more about what we’re doing about it, as well as what you can do today to help prevent your build from slowing down.

* This is possible thanks to many developers opting-in to sharing their usage statistics with us in “preference > data sharing”

Measuring speed differently

The first thing we did was to create internal benchmarks* using open source projects (SignalAndroid, Tachiyomi, SantaTracker & skeleton of Uber) to measure the build speed impact of various changes to the project (code, resources, manifest etc).

For example, here is the benchmark looking at build speed impact of code change, showing great improvement over time.

We also looked at “real-world” data, focusing on build speed of a couple of debug build right before and right after an upgrade of the Android Gradle plugin. We used this as a proxy of the actual improvement of a new release.

This showed really good improvement with new releases**, helping reduce build time by almost 50% since 2.3.

Last, we looked at the evolution of build time over time, regardless of versions. We used this as a proxy of what your actual builds speed is over time. This shows, sadly, that build speed are slowing over time.

If builds are indeed getting faster with each release, and we can see it in our data, why are they still getting slower over time?

We dug a little deeper and realized that things happening in our ecosystem are causing build to slow down faster than we can improve.

While we knew that project growth — with more code, more resource usage, more language features — was making build slower over time, we also discovered that there are many additional factors beyond our immediate control:

1. Spectre and Meltdown patches late in 2017 had some impact on new processes and I/O, slowing clean builds between 50% and 140%.
2. Third party & custom Gradle plugins: 96% of Android Studio developers use some additional Gradle plugin (some of which may not be using the latest best practices).
3. Most used annotation processors were non-incremental, leading to a full re-compilation of your code every time you make an edit.
4. Use of Java 8 language features will cause desugaring to happen, which will impact build time. However, we have mitigated the desugaring impact with D8.
5. Use of Kotlin, especially annotation processing in Kotlin (KAPT), can also impact build performance. We are continuing to work with JetBrains to minimize the impact here.

* Those projects, unlike real world projects, are not growing over time. The benchmarks simulate changes and undo them afterwards to only measure impact of our plugin over time.

** 3.3 focused on foundational work for future improvements (eg., namespaced resources, incremental annotation processor enablement, Gradle workers) hence the 0% improvement.

What are we doing about it?

Fixing internal process & continued performance improvements

We also acknowledge that many issues come from Google owned / promoted features and we have changed internal process to better catch build regression earlier in the launch process.

We’re also working to make annotation processors incremental. As of this post, Glide, Dagger and Auto Service are incremental and we’re working on the others.

We also included R light class generation, lazy task and worker API in recent releases and are continuing to collaborate with Gradle inc. and JetBrains to continue improving build performance overall.

Attribution tools

A recent survey showed us that

60% of developers do not analyze build impact or do not know how to. Therefore we want to improve tooling in Android studio to raise awareness and transparency around build time impact in the community.

We are exploring how to better provide information about the impact of plugins & tasks on your build time directly in Android Studio.

What can you do today

While configuration time can vary based on the number of variants, modules and other things, we wanted to share, as reference point, the configuration time associated with the Android Gradle Plugin from “real-world” data

If you find your configuration time to be much slower, you likely have custom build logic (or 3rd party Gradle plugin) affecting your configuration time.

Tools to use

Gradle provides a set of free tools to help analyze what is going on in your build.

We recommend you use Gradle scan, that provides the most information on your build. If having some of your build information uploaded to Gradle servers is an issue, you can use Gradle profiler which provides less information than scan but keeps everything local.

Note: Build scans are not as helpful to investigate configuration delays. For those you may want to use traditional JVM profilers

Optimize your build configuration and tasks

As you investigate build speed, here are a couple of best practices to pay attention to. You can also always review our latest best practices.

• Only use configuration to set up tasks (with lazy API), avoid doing any I/O or any other work. (Configuration is not the right place to query git, read files, search for connected device(s), do computation etc)
• Set up all the tasks in configuration. Configuration is not aware of what actually gets built.

• Ensure each task declares inputs / outputs (even non-file), and is incremental as well as cacheable.
• Split complex steps into multiple tasks to help incrementality and cacheability.
  (Some tasks can be up-to-date while others execute, or run in parallel).
• Make sure tasks don’t write into or delete other task outputs
• Write your tasks in Java/Kotlin in a plugin/buildSrc rather than in groovy directly inside build.gradle.

We care about your productivity as a developer. As we continue to work on making builds faster, hopefully the tips and guidelines here will help you keep your build times down so you can focus more on developing amazing apps.

Источник

Уменьшаем время сборки ваших Android-проектов

Доброе утро! Начинаем понедельник с материала, перевод которого подготовлен специально для студентов курса «Android-разработчик. Продвинутый курс».

Недавно я переносил кодовую базу Android в Kure на AndroidX. Мне показалось, что это прекрасная возможность поработать над скоростью сборки проекта. У Gradle всегда была плохая репутация из-за медлительности и ресурсоемкости, но я был очень удивлен, что незначительные изменения в конфигурации сборки могут так значительно увеличить ее скорость.

Посмотрите на показатели сканирования сборки до/после оптимизации

до оптимизации

после оптимизации ️️

Снизились с 5,5 минут до 17 секунд?? С ума сойти!

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

Прежде всего!

Перед тем, как начать оптимизацию, важно протестировать наш проект, чтобы узнать, сколько времени требуется на его сборку. Gradle имеет удобную опцию сканирования, которую вы можете использовать для анализа производительности вашей задачи. Запустите терминал в Android Studio и выполните следующую команду:

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

На сайте есть довольно много опций, но для краткости мы рассмотрим только то, что является наиболее важным.

В Summary отображается сводная информация о выполненных задачах и времени их выполнения. Но что нас здесь интересует, так это раздел Performance. Он делает более подробную разбивку общего времени сборки, как показано ниже.

В разделе Performance есть вкладка Settings and suggestions, в которой приведены рекомендации по улучшению скорости сборки. Давайте посмотрим на них.

В этом разделе мы можем найти несколько простых исправлений для повышения скорости. Итак, давайте продолжим и применим эти исправления в нашем проекте.

Шаг № 1: Обновите инструменты

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

Во время этого рефакторинга наш проект был на версии 3.2.1 плагина Gradle для Android Studio (на несколько версий старше, чем последний выпуск).

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

Но здесь есть подвох, о котором мы должны помнить:

(Примечание: При использовании Gradle версии 5.0 или выше размер памяти демона Gradle по умолчанию уменьшается с 1 ГБ до 512 МБ. Это может привести к снижению производительности сборки. Чтобы переопределить этот параметр по умолчанию, укажите размер памяти для демона Gradle в файле gradle.properties вашего проекта.)

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

Откройте файл build.gradle верхнего уровня, который вы найдете в корне вашего проекта, и добавьте следующую строку в раздел зависимостей:

Вам также необходимо обновить distribution URL-адрес в файле свойств Gradle Wrapper, который находится по адресу gradle/wrapper/gradle-wrapper.properties . Обновите URL-адрес до следующего.

Вы столкнетесь с ошибкой при использовании Kotlin, если версия плагина Kotlin Gradle меньше 1.3.0. Если это так, воспользуйтесь подсказкой IDE, чтобы обновить Gradle плагин для Kotlin до последней версии (на момент написания этой статьи это версия 1.3.31).

Хорошо, давайте снова запустим сборку из терминала, чтобы посмотреть, добились ли мы каких-нибудь улучшений.

Шаг № 2: Обновите конфигурации

Итак, мы смогли срезать около 2,5 минут от времени сборки, но это все еще недостаточно хорошо. Изучив логи сборки в терминале, я наткнулся на одну строку, которая нас заинтересует:

Gradle может отключить инкрементную компиляцию, так как следующие процессоры аннотаций не являются инкрементными: butterknife-compiler-10.1.0.jar (com.jakewharton:butterknife-compiler:10.1.0), dagger-compiler-2.9.jar (com.google.dagger:dagger-compiler:2.9).

Рассмотрите возможность установки экспериментального флага android.enableSeparateAnnotationProcessing-true в файле gradle.properties для запуска обработки аннотаций в отдельной задаче и выполнения инкрементной компиляции.)

Инкрементная компиляция в основном предотвращает расточительную компиляцию всего набора исходных файлов и вместо этого компилирует только те файлы, которые были изменены. Из логов видно, что мы не пользуемся этой функцией. Он предлагает нам использовать android.enableSeparateAnnotationProcessing=true , но, в любом случае, мы не должны использовать конфигурацию «annotationProcessor» поскольку в нашем проекте используется Kotlin.

К счастью, в версии 1.3.30 Kotlin добавлена поддержка пошаговой обработки аннотаций.

(Инкрементная обработка аннотаций (с 1.3.30)

Начиная с версии 1.3.30, kapt поддерживает инкрементную обработку аннотаций в качестве экспериментальной функции. В настоящее время обработка аннотаций может выполняться инкрементально, только если все используемые процессоры аннотаций являются инкрементными.
Чтобы включить инкрементную обработку аннотаций, добавьте эту строку в файл gradle.properties :

Обратите внимание, что инкрементная обработка аннотаций требует, чтобы инкрементная компиляция также была включена.)

1. 1. Измените конфигурацию annotationProcessor на kapt
2. 2. Включите экспериментальный флаг инкрементной обработки аннотации

Откройте файл build.gradle уровня вашего модуля и добавьте следующую строку в начало файла:

apply plugin: ‘kotlin-kapt’

Затем измените все конфигурации annotationProcessor в разделе зависимостей для использования kapt. Например:

//До
annotationProcessor ‘com.google.dagger:dagger-compiler:2.9’
//После
kapt ‘com.google.dagger:dagger-compiler:2.9’

Теперь откройте файл gradle.properties, расположенный в корне вашего проекта, и добавьте следующую строку:

Давайте снова запустим сборку.

Хорошо, похоже, мы еще немного продвинулись.

Шаг № 3: свойства Gradle

Мы на последнем этапе. Помните подвох, с которым мы столкнулись при обновлении версии плагина Gradle? Оказывается, более новые версии Gradle уменьшают размер используемой памяти до 512 МБ. Это сделано для того, чтобы слабые машины не расходовали слишком много памяти. У меня компьютер с 16 гигабайтами оперативной памяти, поэтому я могу позволить себе скормить около 2-3 гигов демону Gradle, но ваши цифры могут отличаться.

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

org.gradle.jvmargs=-Xmx3072m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8

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

Вот как выглядит мой окончательный вариант файла gradle.properties :

• org.gradle.parallel — этот флаг позволяет Gradle собирать модули внутри проекта параллельно, а не последовательно. Это полезно только для многомодульных проектов.
• org.gradle.configureondemand — этот флаг настраивает только те модули, которые необходимы для проекта, а не собирает их все.

Сделав это, давайте посмотрим, какие у нас теперь показатели скорости сборки:

Заключительные замечания

Это ни в коем случае не обширный охват всех способов оптимизации скорости сборки. Есть множество других вещей, которые я не рассмотрел в этом посте, таких как использование minSdk 21 при использовании MultiDex, предварительная индексация библиотек, отключение сжатия PNG и т. д., — это всего лишь некоторые из них.

Но большинство из этих конфигураций требуют более глубокого понимания системы сборки Android и опыта работы с крупными многомодульными проектами (где преимущества наиболее очевидны). Шаги, которые я упомянул выше, легко внедряются в проект даже джуниор разработчиками и имеют значительные выгоды. Я надеюсь, что это поможет вам увеличить скорость сборки!

Источник