In this video, +Colt McAnlis​​ gives a refreshingly candid take on the enum "problem". Almost everything about this video is fantastic. Almost. Watch it before reading more, because it does a great job of outlining the pros and cons of enum usage: https://youtu.be/Hzs6OBcvNQE

Ok. So what's wrong here?

In the middle of the video an absolutely ridiculous and sensational number is dropped whose sole purpose is to create a shock-statistic which leads to an incorrect perception of an enum's effect: 2556 bytes.

What app, in the entire history of apps written for Android, has ever had a dex size of 2556 bytes? Zero. Not one. Ever.

The video goes on to show that adding an enum bloats this fictitious app to a whopping 4188 bytes. Why that's basically 2x. I added a single enum and my app doubled in size!

Open Android Studio, go to File > New Project, select a minSdk of 16, select a 'Blank Activity' template, and click Finish. On a clean compile, how large is the dex file of this completely empty app? Two million, five-hundred and sixteen thousand, five-hundred and eighty-two bytes. That's 2,512,582 bytes. 1000x times larger than the "base" example used in the video.

Of course, this size stems from the default dependency of the extremely-useful AppCompat which in turn depends on the also useful fat cow support-v4. If you remove these two dependencies, what does our dex size become? The answer may surprise you: who cares? It's an empty app.

Even if this library-free app perfectly matches up to 2556 bytes as mentioned in the video then adding an enum is completely justified as it would be the only thing in the app.

Whatever random SHA of Square Cash I have sitting on my machine currently clocks in at 6.4MB of dex. How much of that is from enums? Maybe it's 0.01MB. Or maybe it's 0.001MB.

Like I said, this video presents the pros and cons of using enums accurately and does show the relative size difference which is what is important. It is a good video. But, the overall dex size comparison is needless and serves only to mislead you to believe the impact is greater than it really is which just destroys all that credibility it built.

As a library developer, I recognize these small optimizations that should be done as we want to have as little impact on the consuming app's size, memory, and performance as possible. But it's important to realize that throwing away an Iterator allocation vs. an indexed loop, using a HashMap vs. a binary-searched collection like SparseArray, and putting an enum in your public API vs. integer values where appropriate is perfectly fine. Knowing the difference to make informed decisions is what's important and the video nearly nails that except for this one stupid stat.
Shared publiclyView activity