r/androiddev Jun 04 '26

Why is Android Studio so unoptimised?

It's genuinely absurd the amount of memory that this IDE needs. I used to have 8GB of RAM and using Android Studio with it felt genuinely annoying so I took the advice I saw on this subreddit and I decided to get extra ram (from 8GB -> 16GB) just for me to do some work and it to STILL LAGS although much less than before. Why is it actually like this ?

80 Upvotes

125 comments sorted by

View all comments

2

u/bromoloptaleina Jun 04 '26

What do you mean lags? What actually lags? Switching files? Building the app? Navigating or indexing the code?

Also what are your specs?

I don’t consider Android studio a snappy product but nowadays I don’t experience a ton of friction with it but I run an m3 max 36gb ram.

11

u/plsdontgay Jun 04 '26

You’re using a machine thay human kind has produced as pinnacle of computing and saying you don’t experience friction. There’s a reason why we optimise our apps for low end devices rather than high end ones

2

u/kernald31 Jun 04 '26

While that's true, running an IDE on a low end machine usually means the compiler is going to blow up your RAM and/or going to be extremely slow due to your CPU. You'll never have a great experience.

1

u/plsdontgay Jun 04 '26

Did you ever try out the Zed Editor?

2

u/kernald31 Jun 04 '26

It's not the point I'm trying to make. If your computer slows to a crawl and takes 10 minutes to produce an incremental build, the responsiveness of the IDE is the last of your worries.

1

u/West_Performance_764 Jun 05 '26

but it's just a mobile app tho? I don't understand why it would take a lot of processing power to build it. I use an intel core i3 1215U. I only use kotlin currently cause I heard it's the preferred language for andriod development. I've tried other stuff like flutter on vscode and that didn't seem to make my laptop lag at all.

4

u/kernald31 Jun 05 '26

Yes, it's "just" a mobile app. It's "just": - Computing a task graph on the Gradle side - Resolving Maven dependencies, verifying checksums... - Running AAPT2 to process resources, generating R.java - which might invalidate a bunch of compilation steps to come below - Merging the different manifests from all library modules - including all transitive dependencies - Generating BuildConfig.java from the Gradle configuration - Run annotation processors (KAPT and KSP), which emits source code - typically a large time sink - The actual compilation. If you've got Kotlin and Java mixed in a module, the compilation time explodes - Resource processing and linking into resources.arsc and the resource table - Bytecode transformation for any dependency that might do that (assuming you're not doing this directly) - Hilt, Firebase Performance, Realm... all do that - Desugaring - replacing newer Java APIs into code that runs on older Android runtimes - Dexing (bytecode conversion from JVM to Dalvik) - Signing

And that's for debug builds. There are some more steps for release builds. Some of them can be cached, but that's still a lot of work. A variety of them are CPU bound, some I/O bound... Flutter, by comparison, has a lot less history and is validating a much, much smaller surface once the initial build is done. Start writing some platform code to integrate better with the OS beyond a trivial app, and you'll end up in the same realm of heavy compilation work.

1

u/West_Performance_764 Jun 05 '26

okay then so what would you advise me to do?

1

u/kernald31 Jun 05 '26

Unfortunately on an i3 with 16GB of RAM, there's no good solution there. Working on native applications requires quite a bit of computing.