I still remember when I saw my first multidex app. It was almost two years ago and ho so rare. It was an almost religious experience – seeing something you didn’t think could exist with your very own eyes. And yet today I’m surprised when I stumble upon an app and it only has one dex file. Seriously, it’s like finding an oasis in the Sahara. A sight for sore eyes.
Which is why I was so surprised when our saleswoman told me about a meeting she had, where the developers in question specifically asked about it. They were determined to stay single dex no matter what.
You see, silly me, I thought the 65k limit was like one of those things you read about in history books or see in old movies. But it turns out I was living in a bubble. But hey, can you really blame me? Even Android’s own new compiler – Jack – refers to it in both code and documentation as “legacy”.
Which leads me to really think – is the 65K limit in Android still a big deal?
Once Upon a Dex
Two years ago, we were all struggling with the 65K limit , fighting to keep our method count down, careful of any new ones we might add. But then the multidex solution was introduced. I was wowed when I saw an app that came with 2 dex files (yes, people told me to close my mouth or the flies would get in 🙂 ). And when I managed to actually make my own app spill over to a secondary dex file? Forget about it. I felt like King of the Androids. If you haven’t been Androiding back then or were blessed with a low method count you might think I’m exaggerating, but I’m not. I promise you, I’m not.
And then things started changing. The multidex solution became more and more easy to implement, the general public got wind of it and before you knew it – everyone were multidexing. Like a new fashion sweeping through our bytecode nation, all the cool kids were doing it. Or were they? I still encountered app developers here and there that were worried about it and didn’t want or even know how to multidex. I encountered SDK developers that were afraid of adding too many methods themselves. I certainly did my best to keep my own method count as low as possible. Yes, even today.
In the meantime, the world continues to turn on its axis. The multidex solution was met with a complete reinvention of the Android virtual machine, and Google were moving fast as they could to put this unfortunate limit behind them. But even today, Google’s own numbers show that 50% of devices are not yet compatible with these changes. Which means that legacy or no, app developers still have to consider half the market when building their app.
Starting with Lollipop, multidex should have history’s concern. But two years later, half of the devices are still older than Lollipop.
To Multidex or Not to Multidex, That is the Question
I’ve used this subheading once before, when I wrote about the Unbearable Lightness of Multidexing over a year ago. I find the question to be as prominent today as it was back then.
On the Pros column we have, obviously, that it solves the 65K limit. Hurray.
On the cons column we have two major possible disadvantages – it prolongs compilation time and it prolongs app start time. In the constant debate of whether or not these are truly significant disadvantages, I somehow always end up being on the side that shrugs, claiming these are negligible. But then again, I was living in a fantasy bubble world that thought multidex was a thing of the past, remember?
As someone who mostly uses new devices, where the multidex repercussions are truly a thing of the past, I don’t encounter it often. I’m also white and male, so I’m privileged to the bone. Which is why it may have caught me by surprise that people are still adamant to stay single dex in this day and age.
Prolonged compilation process is an unpleasant little thing but overall with Instant Run, the ability to set minSdkVersion to 21 and all kinds of cool Android Studio and Gradle changes, it is much better. Ho, who am I kidding? No one’s really going to set their minSdkVersion to 21, fearing bugs that would only be found too late in the process. And Instant Run and Gradle changes and all that, it’s helpful but it covers only a small portion of development cycle. The real reason I was so quick to dispose of taking that into account is that the Gradle build is already usually so slow, what’s another 30 seconds?
And prolonged Start Time? The process of installing the secondary dex files can become monumental for older, slower and less state-of-the-art devices. I barely see it because of all my privileges, but I’m sure people are experiencing that nonetheless. But then again, they’re experiencing everything slow and irritating. This is just a drop in the ocean. However I can’t say that with certainty – I haven’t witnessed it with my own eyes.
But wait, here’s another little disadvantage that might not be so little – while available all the back to Gingerbread, multidex does have some documented hiccups before finally becoming stable on Ice Cream Sandwich. In a recent survey of apps we recently did as SafeDK, we found that 23% of apps are still compatible for Gingerbread. So maybe app developers that want and need to support so many users all the way back, without prejudice, do really want (and perhaps should) avoid becoming multidex.
Multidex is a Fact of [Android] Life
So why was I so shocked to realize the 65K limit is still an issue? Mostly, because it’s not only common seeing an app with two dex files these days, seeing apps with three dex files is not that big of a deal. Not that common, but not that rare as well. Yep, some apps are definitely seeing the 65K limit in the rearview mirror.
And it has some great advantages as well. Apps today can be enriched beyond their wildest dreams, adding capabilities, features and SDK libraries without worrying about something as trivial as their method count. You can take on several ad-networks, for example, comparing between them or letting one mediate over the others without feeling constrained. You can evaluate different aspects of your product without too much overhead. Honestly, you can A/B test your app with so many different scenarios on a single APK. That’s great. Amazing, even.
Google Play Services, the mother of all mega SDKs, has now reached well over 44,000 methods with the introduction of Firebase. And while the number of apps using it as a whole has dropped from 50% to 20%, that’s still quite a lot. But multidex allows developers to disregard their unused SDKs, as long as they’re also willing to disregard their compilation time.
Our survey found that nearly one third of Android apps are in fact already on multidex, with 20% more being just on the cusp of it. So multidex is definitely a fact of Android life.
So… Is It Still a Big Deal?
Unfortunately, I have to say yes. It is still a big deal.
It’s a big deal because 50% of devices are still requiring you to implement the multidex solution yourself if you want to exceed the 65K limit.
It’s a big deal because supporting at least some of these 50% of devices prolongs your compilation.
It’s a big deal because a vast number of apps still continue to support very old Android versions, Gingerbread and up, where issues like start time are very important to user experience.
It’s a big deal because we want to be profitable and reach users living far from us, all over the globe, with who knows what kind of phones and conditions and notions.
It’s a big deal because not thinking it’s a big deal is simply a dangerous practice. Even if you are multidex, there’s nothing wrong with that – unless you stopped caring. You mustn’t forget about a large portion of your users, their experience and how you impact their device. You must never be indifferent to your compilation process in terms of time, complexity, and memory and CPU usage and so on. You must constantly be vigilant. Because if you won’t be, who will? After all, it’s your app.
I’ll admit. I was a bit callous in my thinking that multidex was the vaccine. In all honesty, I still kept fearing the 65K limit. I slept better, sure, but it was always present in my everyday typing.
So multidex if you must. Just be wise about it.