If you’ve read some of my posts in the past, you know I have a near-obsession with mobile app start time. And I know I’m not alone there. It’s this generation “We can lend a man on the moon” most favorite complaint – It’s 2016, how can it be we’re still waiting for apps to launch?

Well, looks like indeed I’m not alone. I’m in good company with the nice folks over at Google / Android, who are doing some nice things to improve app start time.

One of the most interesting things I’ve heard in both keynote and sessions at Google I/O two weeks ago was how the ART virtual machine has improved and how well it’s going to affect both start time and system update time. Alongside the introduction of Android Instant Apps, it looks like Android is looking to dispose of any unnecessary waiting time.

AOT and ART: Thinking Ahead

The introduction of ART way back in Android Lollipop was a real game changer for Android, and not just in terms of trying to eradicate the 65K limit problem.

ART introduced the concept of AOT (Ahead-of-time) compilation. You see, all Android apps are compiled to dex bytecode format – a bytecode more suitable to the mobile operating system. However, different devices have different architectures and the bytecode is still too common. So when ART translates dex to the new bytecode format, dubbed oat, it also compiled it to be much more specific to the device on which it is being installed. The bottom line is this – ART compiled dex to native code suited for the hardware architecture running on the device.

One of the bigger advantages is that the process happens only once during the app install, and not every time the app is launched.

But there are some drawbacks to AOT: The native code is larger is size and takes up storage; it tends to use more RAM space; the install process could get very long; and the list goes on.

Android_LollipopAndroid’s Lollipop introduced ART and the concept of Ahead-of-time compilation

Back to the JIT

Before ART, there was Dalvik. The Dalvik virtual machine would use JIT (Just-in-time) compilation – it would compile the dex bytecode that’s about to run to native code suited for the specific hardware device running the app. The decision to move to AOT was based on the need to speed apps up and thus avoid doing this compilation process every single time.

Well, Android N is sticking with ART but including JIT back inside it.

Basically with Android N’s ART, the code will cease to be permanent. Yes, there will still be AOT compilation, however it will be limited. Instead of compiling the entire code to native, the app will be profiled and only the hot methods – the ones that are likely to be executed (frequently) – will be compiled. While the app runs, should a method that hadn’t been optimized be encountered, it will be compiled to native on the spot and the app’s code stored on the device shall be replaced with the new code.

But wait, that’s not all. What if you encounter a new method that hadn’t been translated yet but the device is low on either memory or battery? Well, ART will also try to anticipate which methods are “close to being used” in the near future and would go ahead and translate them as well while the device is both idle and charging.

The Impact on System Updates

One of the biggest implications that the new AOT-JIT marriage brings us has to do with System updates. Now System updates are always a painful dilemma – you want to stay current have the latest security patches applied ASAP, but losing your device for the duration is the equivalent of holding your breath. With system updates lasting about 15 minutes, that’s quite a dilemma.

Now if you’ve ever gone through the process of System Update you might have noticed that the update itself may last a minute, but it’s that optimization of apps process that’s taking forever.  The more apps you have, the longer it takes. Looking at that spinner, telling you it’s optimizing, it might as well be taunting you with your device held captive.

Android N won't need to optimize all apps after system updateStarting with Android N, you will no longer have to wait for apps optimization after System Updates.

Well, no more. The optimization process is gone. Why? Because JIT is responsible for optimizing the app. No need for AOT compilation to achieve better performance after the system update, the profiling done on apps will provide JIT with all it needs in order to optimize your apps in due time.

So if you migrate to Android N for the first time, you’ll still have AOT compilation for the hot methods but the overall process should take about a third of the time. And once you’re already on N and receive a system update, the process shouldn’t take longer than a minute. Just downloading, installing and restarting the device. No optimization process.

At SafeDK we’ve seen SDKs that extract new code during the app’s run, damaging the new AOT and JIT running time. With SafeDK’s In-App Protection, you can get live data on your SDKs, as well as remotely deactivate them. Get a free trial now!

Summary: Two Hands, No Waiting

There’s more stuff ART is doing different in N in order to make things faster, but the reintroduction of JIT is definitely the biggest of them all. The others vary from memory IO optimizations, through further enhancement of Doze and even moving the dex verification stage during app install.

It’s hard to predict at this stage how Android users would react once N is made available, and if the non-technical users would even notice the difference. However, it’s becoming clearer that the general public isn’t the only one wondering why waiting for devices and apps is still a thing in 2016, and Google is making is attempting to remedy just that.