Improving build speed in Android Studio

Improving Build speed

In Android studio, we need to make you the most productive developer you can be. From various discussions and overviews with developers , we know that waiting for slow build speed takes away from that productivity. In this article, Android training in Chandigarh trainee share some of the new analytics we’ve put in place to better pinpoint what is truly improve build speed in Android studio and offer progressively about what we're doing about it, just as what you can do today to help keep your build from slowing down.

Measuring speed differently

The main thing we did was to make internal benchmarks utilizing open source projects to measure the build speed impact of different 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 examined "real world" data, focusing on the improving build speed of the two or three debug builds before and after an upgrade of the Android Gradle plug in.

We used it as a proxy for the real improvement of a new release.

This was a really good improvement with the new release and helped reduce build time by about 50% from 2.3.

Last, we examined the evolution of build time over time, regardless of version.

We utilized this as a proxy of what your actual builds speed is over time.

If builds are indeed getting quicker with each release, and we can see it in our data, for what reason would they say they are as yet getting slower after some time?

We dug a little deeper and understood that things occurring in our ecosystem are causing build to slow down quicker than we can improve.

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

Spectre and Meltdown patches At the end of 2017 had some impact on new processes and I / O, which slow down clean build between 50% and 140%.

Third party & custom Gradle plugins: 96% of Android Studio developers utilize some extra Gradle plugin (some of which may not be utilizing the most recent best practices).

Most used annotation processors were non-incremental,prompting a full re-assemblage of your code each time you make an alter.

Utilization of Java 8 language features will cause desugaring to happen, which will impact build time. However, we have relieved the desugaring sway with D8.

Utilization of Kotlin, particularly annotation processing in Kotlin (KAPT), can also impact build performance. We are proceeding to work with JetBrains to minimize the impact here.

What are we doing about it?

Fixing internal process & continued performance improvements

We additionally recognize that numerous 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. According to this post, glide, dagger and auto service are incremental and we are working on others.

We additionally included R light class generation, lazy task and worker API in recent releases and a are proceeding to team up with Gradle inc. also, JetBrains to keep improving build Speed and performance in Android studio 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 need to improve tooling in Android studio to raise awareness and transparency around build time impact in the community.

We are exploring how to all the more likely give information about the impact of plugins & tasks on your improving build speed time directly in desugaring.

What can you do today

While configuration time can differ dependent on the quantity of variations, modules and different things, we needed to share, as reference point, the configuration time associated with the Android Gradle Plugin from “real-world” data

If you think your setup time is slower, you probably have custom build logic (or third party Gradle plugins) that will affect your setup time.

Tools to use

Gradle gives a lot of free tools to help analyze what is happening in your build.

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

Optimize your build configuration and tasks

There are some best practices to be aware of when examining and improving build speed in Android studio. You can also always check the latest best practices.

Configuration

Use the configuration only to set up tasks, and do not do I / O or other work.

Set up all the tasks in your configuration. The configuration does not recognize what is actually built.

Optimize tasks

Ensure each task declares inputs / outputs (even non-file), and is steady just as cacheable.

Split complex strides into numerous tasks to help instrumentality and cacheability.

Make sure tasks don't compose into or erase other task outputs

Write the task in Java / Kotlin in plugins / buildSrc, not groovy in build.gradle.

We care about your productivity as a developer. As we keep on taking a shot at making builds faster, ideally the tips and rules here will enable you to keep your build times down so you can focus more on developing amazing apps.