Introducing the new Android Runtime - ART

I have been using ART for 2 days on my N5, everything runs amazing though honestly it probably would on Dalvik too I'll switch back if I run into any stability issues though.

Switched over on mine yesterday and I've yet to see anything even remotely like a problem.

To take full advantage of this, do you need to factory reset and reinstall apps. I am under the impression that ART works in part by doing something when the app installs, but this is a bit over my head. Probably won't be trying until I am sure how everything works normally on the N5, but I'm curious. Then again, this phone is so damn fast I'm not sure I would notice the difference.

Hook said:

Then again, this phone is so damn fast I'm not sure I would notice the difference.

Click to expand...

I still can't get over the speed.

EarlyMon said:

When the Dalvik is clear, it updates at boot up.

According to the Android Police article, ART works the same way; they warned that boot up could take some ten minutes to compile your existing apps.

Thereafter, apps are compiled when installed, just as the Dalvik cache is updated when apps are installed.

Based on that, a factory data reset ought not be required.

Click to expand...

I've been running it for 2 days; no issues so far. Correct, factory reset is not required. It just needs to reboot. It goes through its "Android is updating" routine. From reboot, to up and running, it took 8 minutes.

Today I finally ran into my first set of issues. Dead Trigger 2 and Kingdom Rush Frontiers both crash on ART. I switched back for now, seems like games aren't built to work with it yet.

Very cool. I always thought "Just In Time" was a misnomer

Been running it for about 24 hours now.

Haven't had any issues yet, but I've read of greenify and titanium backup incompatibilities.

Same goes for custom kernels. If your a tinkerer, its probably best to leave it be until devs get more time with it.

Its been reported this has been worked on over the last 2 years, so is it safe to assume it isn't something flexycore was in on (at least until recently)?

EarlyMon said:

Google engineers have been in talks with FlexyCore people for the last year.

Google said their engineers did this - thanks to the acquisition, FlexyCore's engineers are Google engineers.

FlexyCore stated in 2010 that they were compiling apps into native code (and demonstrated it, I can post a YouTube on that), and that their target was the OEM level, not end users, for revenue.

I could be wrong, but I don't see how this wouldn't be at least a piece of FlexyCore's DroidBooster.

Click to expand...

Certainly sounds like it fits the bill

Indeed there is a limit to any optimization. And some stuff just has to be done at runtime.

I wonder if some of the aggressive compression AAPT does could be one place they might be able to gain performance. i.e. I wonder if another one of the optimizations might be uncompressing the resources like PNGs to the bitmap format the device's screen supports like ARGB_8888/ALPHA_8/RGB_565 etc.

EarlyMon said:

I'd also love to see some real memory profiling of the difference here so far.

Click to expand...

It only takes a reboot to go back and forth, so if you've got anything specific you'd like compared I'll see what I can do

EarlyMon said:

Please try your favorite monitor - something like Quick System Info Pro will do - and let's see if anything stands out at a zero-level check.

In QSIP, Processes tab, note some memory sizes of favorite apps run both ways (make sure Show Memory Usage is checked under Preferences from that tab/page).

QSIP also allows you to place a memory-used notification in your task bar and start that at boot-up - see Preferences from the main page, Task Killer Notification.

Check memory free after a reboot and some reasonable settling time - you decide, 10 minutes maybe - for both configurations.

Final point is anecdotal, but check that memory pull down while trying to run some things in the same way (not terribly important for a first look - refresh gmail, visit our home page and search for something in the Play Store for example).

That will tell us two things on a very rough sampling - individual app memory used in a few cases and free memory while running.

Click to expand...

I'll have some free time to tinker tomorrow AM, I'll do that and get back to you then. :thumbup:

Has anyone done this yet? I'm reading how it helps speed things up over using Dalvik. Still don't really know what it does. Just did it on my Gnex running Shiny's 4.4 ROM.
To do it, head into Developer Options and swap over Dalvik to ART. Some are reporting FC's though so tread softly.

Edit: Heads up, if you have a lot of apps and you enable it, the reboot takes a LONG time. It's not bootlooping, just swapping all the cache over.

2nd Edit: Some reading here:
http://www.androidpolice.com/2013/1...-in-secret-for-over-2-years-debuts-in-kitkat/
(FYI, I have 172 apps and it's coming up on 10min to optimize them and still not done)

Okay, reading helps!
Do not do this on a custom ROM. Everything crashes.

I had stability issues with a lot of my apps so I had to go back to dalvik. It was really fast tho.

EarlyMon said:

Indeed.

It makes sense that this would save time loading apps.

Prior to this, Google's position has been that, aside from anything computationally intensive, native code holds no advantage over Java.

Source for that, the NDK, emphasis from Google -

Android NDK | Android Developers



FlexyCore said that they performed optimizations beyond just compiling and Google says that this is a work in progress.

Certainly interesting to see what other optimizations are coming.

I'd also love to see some real memory profiling of the difference here so far.

There seems to be an assumption that the new compiled code will be more compact, reducing the memory footprint.

There are a number of ways to compile code, I don't think that the assumption is automatically true.

As you point out, it's easy to conceive of an optimization that trades space for speed.

Other classic examples are loop unrolling and vectorization.

We know it's not a simple case of precompiling to get the same output as the JIT compiler as evidenced by the earlier report that some games didn't work (yet) under this scheme.

We also need to look at the future impact here.

Pretty clear that 64-bit Android is coming.

Java in a virtual machine is immune to 32/64-bit differences, it's up to the virtual machine to sort that out.

Whether this approach has the same immunity remains to be seen.

Likewise for backup restoration to a new phone architecture.

Click to expand...

Interesting point about the NDK! Also I could have sworn I read the JNI overhead was not insubstantial. That was the reason I thought to avoid JNI (that, and much of what is thought to be computationally expensive is already translated to a native implementation by the framework/VM itself).

And definitely the loops are translated by the VM to a native implementation -- it would be interesting to see how this gets optimized. This could certainly gain some performance for large loops (100+ iterations). Could be interesting too, if lambdas come to Android's flavor of Java.

For non-game apps the two biggest performance drags I have noticed are layout and image rendering.

Image optimizations could better prepare the data for something like skia to send it to the surface flinger, but I'm not sure how they would optimize layout. A lot of that happens because of Android's dynamic nature requires several measurement passes through the view tree. I think this is something they improved behind the scenes in 4.3.

I haven't done memory profiling on any apps I have developed in awhile. But I seem to remember that image decoding is performed on the system heap, but still counts against the app's memory usage limit. I'm curious what the optimization would be here.

Another choke point seems to be reflection/method invocation and object access. Then of course there is file IO and Network IO. Network IO has been aided by libraries like Volley, and hopefully more stuff like that will come along. But I suspect platform specific optimizations could certainly help here, though I'm not sure exactly how.


This is certainly an interesting thread though -- even though much of it happens beyond my little sphere of app-dev specific knowledge.