A coworker mentioned that multidexing also take ages and uses huge amounts of memory.

Why do people always talk about multidexing like it's such a nightmare?

https://developer.android.com/studio/build/multidex.html

It's really not that bad, It only gets a little squirrely if you're trying to support super old android versions.

Our app's build time ballooned by 2-3X or more when we went to multidex. We've had some luck reducing it, but we'd still like to axe multidex.

I definitely consider a 3X build time increase (not 30 seconds to 90 seconds, but 1 or 2 min to 5-8) to be a significant problem, bordering on nightmare... especially since we just included a few more libraries that put us past the 65k mark.

Is that what other people have seen?

How is your dev pipeline set up such that an 8 minute release build becomes such a problem?

I guess I'm thinking of builds on my machine taking that long, not even release builds.

Surely that's just a release build, though...? How would this bottleneck productivity for a team?

When you deploy release-like builds to your QA team (as you should), a tripled-build time is a bit problematic if you're trying to iterate quickly.

Who needs to "iterate" so quickly that several minutes added to your build time becomes a huge issue?

Me? I work on embedded android installations that have over a thousand years combined of running with 0 software crashes. Once I get to a certain point in developing an app for our installations I start profiling for the slightest memory leaks by watching changes in memory usage profiles for different user flows.

And I can only do that with release builds if I want useful numbers. I've had us split up apps over build times because of Multidex (for example, most of our AWS centric code lives in a separate app that exposes specific functions via an AIDL interface because the SDK was bringing in too many methods)

Are there any legitimate use cases for that many methods?

It sounds like a ridiculous number of methods until you realize just importing Guava brings in 20k methods, using half the Amazon SDKs would probably bring another 20k-40k, Apache's main utils bring about 10-20k, etc.

I mean, it means you can't pull in Scala. I mean, you can, but pull in enough bloated Java 3rd party libraries and you might be hitting that limit pretty quickly. Google broke Google Play Services out into a large number of small dependencies once they were past the 15k method mark. Mind you, certain compilation settings will totally strip out unused methods, but it's still annoying.

For example, the amazon sdk jar has 40,000 alone or something insane. You can hit if you're using a few large libraries.

That said, you can use proguard to strip your unused methods and it usually fine even for large applications.

Java's crippled generics, lack of tuple support, and lack of default parameters encourage interface bloat in utility libraries.

Given how bloody good Java IDEs are (By which I mean to say - how good IntelliJ is), the cognitive cost of this interface bloat is very low... Until you start developing for Android.

Wouldn't Java's crippled generics actually help reduce the method count since due to type erasure they're all the same method at the VM level anyway?

On the one hand yes, on the other hand Java also generates Bridge methods when you implement a generic interface. A MyType implementing Comparable<MyType> will contain a compareTo( MyType ) method and a generated compareTo( Comparable ) bridge method.

It is more likely that generated classes, countless getters and setters and a tendency to small methods has a higher impact.

For reference types probably yes, but Java also often needs extra methods or overloads for handling primitive types, which would get unnecessarily boxed when used in generic methods.

IIRC the Facebook app had many more than that at one point, and had to use multi-dexing. Not sure if that's still the case.

I've also heard that scala apps on Android can sometimes hit the limit, because pulling in the scala stdlib greatly bloats the method count.

Wasn't that the initial reason behind splitting off Messenger into a separate app?

I don't know, but I would doubt it. Making such a huge product decision based on an engineering limitation (that has a workaround) seems like a poor idea.

Because of "single responsibility principle" it's better if classes and methods do one thing. That usually leads to lots of small classes and small methods.

Ad SDK's have tons of methods.