What more is there to say about the mobile app start time? I’ve already written about it in the past, describing our research about what makes up the time from the moment you click on an app’s icon until you get a visual feedback.
But when Samsung’s Innovation Center in Tel-Aviv offered us the chance to record a podcast, we knew it had to be about the start time. After all, listening is better than reading, right? So Ronnie Sternberg, Maya Mograbi and myself headed over to Samsung offices to embark on a conversation about the mobile app start time. And what can I tell you? It was fun!
Some interesting points were made, not all of which were covered in my original post…
Previously on “The Strung and the Restless”
A short recap to those joining us half-way through – at SafeDK, we’ve done some extensive research about mobile app start time, specifically in Android (iOS team is on it as we speak), and we found that it’s comprised of two parts: The Application Class and the Launcher Activity. While the application class can be created at any time (since background services and broadcast receivers regularly sit at the popular kids’ table), the launcher activity is created when the user launches the app. Only once the launcher activity’s onStart method was completed, the user receives the first indication of app response.
Listen to the podcast or read more details in my original post.
What can happen during those two classes? Plenty of initialization, by either the app’s or its 3rd party SDKs.
1. SDKs Stalls Your App’s Start Time
The common app is using SDKs. Usually a lot of SDKs. 15 on average, to be exact. For all kinds of features – analytics, crash reporting, tracking, push notifications and of course, the vast majority of free apps – ads. Ads, ads, ads.
We have seen that SDKs affect the start time. As mentioned above, the app start time often contains SDK initialization code – fetching ads, configurations or recommendations via network, reading properties from the APK or filesystem, or just plain objects initialization – SDKs often set-up during the app start time, usually in order to allow the app itself to run much more smoothly.
But that might also be your Achilles heel… Not every initialization or network request is a big deal, but when you sum all of these together, it starts to become an issue. The SDKs you use may enrich your app, but also, potentially, prolong your start time. And hey, let’s not forget about your own code and initializations…
During the podcast, Ronnie revealed an intriguing anecdote: An app that discovered its start time amounted to over 20 seconds, and after some digging it was discovered it was all because of one, single, SDK…
2. No Threads Attached? No Such Thing!
One misconception about computer time in general, and mobile time in specific, is that threads are always cost effective. However, if you bombard the hardware and OS with plenty of threads, you’ll still have to pay for all the massive context switching.
Remember – the phone’s resources and memory are finite and limited, and you are not the only app using these resources.
We brought up exactly that point when discussing whether moving more work to the background is helpful and productive. Usually it is. It really truly is. Especially in order to avoid the dreaded ANR exceptions. But it’s not a magic cure. And it may have some ripple effects and consequences (for instance, device temperature and battery consumption).
There’s an SDK out there, one that’s gaining serious momentum, who we’ve seen consistently, in many apps, opening more than a dozen threads during the app start time alone!
3. Extra Binaries and Code are Loaded during App Initialization – and this Practice is even Worse as Android Progresses
During the podcast, we’ve talked about the behavior of two SDKs that are shipped with a minimal package containing their public APIs, while their core functionality is centered in a secondary dex file as an asset that needs to be unzipped and then dynamically loaded each time the app runs. The result is that we’ve seen each of them taking a third of the start time by itself.
When we ran the app several more times, the ‘orange’ SDK contribution was diminished while the ‘blue’ one didn’t. Why? After exploring it for a bit, we saw that the orange SDK stored the unzipped dex file on the device’s filesystem, therefore only paying for the dynamic loading and not the unzipping every time but the first time.
However during the discussion we also raised an interesting point – starting with Android Lollipop, the dalvik VM is deprecated and Android now runs a VM called ART. The benefit is that the dex bytecode format is translated during installation to the new OAT format, thus saving precious time during the app start time (no need to optimize and load the secondary dex files no more – multidex is slowly becoming an issue of the past).
But these two SDKs (or any others relevant to this discussion) force the new virtual machine to translate and optimize every single time, regardless of if they’re unzipping or not. Basically, by sticking with this old methodology, they’re causing more harm to the start time today than in the previous OSs. With more and more users moving towards Lollipop and Marshmallow, and the Android N preview now available, this affects more and more users’ experience.
By the way, since my original post was written, the ‘blue’ SDK has been significantly improved – it still unzips every single time, however now the work has moved to be done in a background thread. This results in better performance, but, still, it continues to take a significant amount of time (now almost half of what it used to take, yet by no means not negligible):
Well, we’ve had a blast doing the podcast. We hope found it interesting as well. And maybe, hopefully, cheer us on to do another 🙂