
A Closer Look at Android RunTime (ART) in Android L - cpeterso
http://anandtech.com/show/8231/a-closer-look-at-android-runtime-art-in-android-l
======
rcthompson
It's kind of funny to hear AOT compilation being heralded as the next step
after JIT that will bring better performance because you only have to compile
once, since we spend so much time hearing exactly the opposite, especially in
the context of Javascript.

(Notwithstanding that, as other comments have pointed out, JIT vs AOT is at
best a gross oversimplification of the difference between Dalvik and ART.)

~~~
AshleysBrain
Apps and web pages are different use cases. An app you expect to spend a
moment "installing" and are likely to use regularly, so AOT compiling is
useful. Web pages on the other hand are often visited briefly and a few
seconds delay can make a huge difference difference, and often contain lots of
script executed only once or not at all - so AOT compilation would actually
hurt performance.

~~~
lenkite
Not really true with all the HTML5 apps based on Phonegap and WebView.

------
mwcampbell
I wonder if it would make sense to rewrite some native components of Android
in Java now. Presumably, whole-program optimization means that the ART
compiler is more effective if more of the code is in Java (or technically, Dex
bytecode) rather than having opaque native parts with JNI overhead.

~~~
pjmlp
That is already the case. When you look at the NDK, you can only have access
to game related API (audio, graphics and sensors) almost everything else
involves JNI.

~~~
jordanthoms
Actually quite a bit of the view code is native still - start reading the
source for View etc and you hit a level where it's mostly calls out to native
libraries. e.g
[https://github.com/android/platform_frameworks_base/blob/mas...](https://github.com/android/platform_frameworks_base/blob/master/core/java/android/view/GLES20Canvas.java)

~~~
pjmlp
Well, graphics code eventually needs to speak to the graphics card.

I imagine outside graphics, audio and hardware integration APIs, there is very
little done at C level.

------
melling
"This also means that Android is finally able to compete with iOS in terms of
application fluidity and performance, a big win for the consumer."

Does anyone actually have any real comparisons between Android and iOS? Was
there an acknowledged 2x performance benefit for iOS on the same hardware? For
games and Ui, for example, wouldn't the GPU be more important?

------
Roboprog
Interesting that the new on-device output is a Linux ELF binary. I suppose
this opens the door for a more flexible cross-compiler system that could in
the future better support languages that are less Java-like. E.g. - something
like Swift that doesn't use a GC at all, for example. Or at least an option to
develop in Go?

It will be interesting to see what sort of extensions Google adds to the dex
format in the next few years. Hopefully, there will be some efficient lower
level language bindings for the UI calls, perhaps?

------
vii
This architecture is insane from an overall system point of view.

Why ship DEX proprietary bytecode to be compiled by the same compiler in the
same way on hundreds of millions of devices to produce the same output?

It would seem far more logical to compile all the versions needed, one for
each device architecture, just once. As other aspects of the apk need to be
customised for each device class already, there is not really new overhead.

Going native is a great idea, doing it this way is plain bonkers.

~~~
krschultz
It took less time to recompile 200+ apps on my phone when I switched from
dalvik to ART than it does to download 2 or 3 more new apps. CPUs are fast,
even on mobile.

~~~
ygra
Also the largest part of the packages are probably not code, but assets which
presumably don't get compiled further ;-)

~~~
MBCook
That's a great point. It would be interesting to see a list of largest mobile
apps by code size instead of just code + resources.

------
TheLoneWolfling
This seems familiar:

[https://news.ycombinator.com/item?id=7738223](https://news.ycombinator.com/item?id=7738223)

------
hexleo
ART is a good news for Android users, but it's really optimize the
performance? I watched someone use Android L to run some popular social
app(like WeChat), you can't open it normally. Some big bug sure be fixed.

~~~
on_and_off
I am testing the L build on a Nexus 5. Our app has a feed full of very rich
views. We already implement a lot of optimizations (not all of those that are
possible though, namely flat custom views, simply because we don't have the
engineering ressources to do it right now) but it scrolling is not perfectly
smooth on 4.4. We lose a couple of frames each second when scrolling rapidly
(interestingly, in addition to its native code, iOS also limits scrolling
speed in order to deliver a smooth experience). This is no longer the case
with Android L. Without changing anything in our code, this feed is now smooth
as hell.

About the app you mentioned, L is right now a preview build, there are indeed
a lot of bugs everywhere. It is not really surprising since we are months away
from the release. It does not have anything to do with perfs though.

~~~
hexleo
I think you are right. I'm not a pure Android developer, just do some works
with Android. Your test give us a good news, we happy to see Android more
smooth.

