What's slow on Android?

by Tomei Ningen » Tue, 13 Jan 2009 06:21:19 GMT

Sponsored Links
 Hello Android developers,

We are building an Android-based device, and would like to know what we should 
try to improve in terms of performance. If you can have just 3 things be much 
faster, what will they be?

.... please be specific (instead of "graphics is too slow", something like 
"drawing red poker dots on translucent canvas is slow")

.... and why are they important (a real-world use case would be good).




What's slow on Android?

by stoyan . damov » Tue, 13 Jan 2009 06:34:27 GMT

 I'd iike to see:

1. Faster GC
2. JIT - if you could jit an entire app the first time it's started
(or better yet - installed)
3. Implement/fix SoundPool


Sponsored Links

What's slow on Android?

by Tomei Ningen » Tue, 13 Jan 2009 06:39:01 GMT

 Thanks Stoyan,

For 1, faster GC, is this related to stuttering in animation due to GC. Is it 
possible to avoid them by calling System.gc() directly (such as when you change 
between different game levels).

For 2, are you writing intensive computation in your app? Do you want to have 
just a few loops run faster? If so, will it be OK if you were able to load 
native code into your app (but otherwise there's no JIT).

----- Original Message ----
From: "stoyan.da...@gmail.com" <stoyan.da...@gmail.com>
To: android-developers@googlegroups.com
Sent: Monday, January 12, 2009 2:28:50 PM
Subject: [android-developers] Re: What's slow on Android?

I'd iike to see:

1. Faster GC
2. JIT - if you could jit an entire app the first time it's started
(or better yet - installed)
3. Implement/fix SoundPool



What's slow on Android?

by Stoyan Damov » Tue, 13 Jan 2009 06:59:44 GMT


Actually it's not. In my hopefully-ready-and-about-to-release game I
preallocate object pools for *absolutely everything* and don't
allocate (directly) *any* objects (except when changing levels, where
I do call System.gc), so no stuttering whatsoever and quite steady
(and very close to 60 fps) frame rate (drawing is *extremely*
expensive on Android, so I draw as less as possible; btw, drawing
images is *very* fast).

However, if you get for example the call log (this has been reported
by someone else, but can't remember the guy's name), if you have a
hundred+ calls and try to scroll it, the stuttering is quite annoying.
I don't know the exact reason for that (other than I know that GC
kicks in 3.5 secs or so) but probably many
not-optimized-as-much-as-possible apps will benefit faster GC.

JIT will allow game writers (or developers of any intensively drawing
apps) to really focus on their games, and not the gory details of how
many instructions this or that costs, especially for extremely simple
things like calling getters/setters.


What's slow on Android?

by Ecthelion » Tue, 13 Jan 2009 23:21:34 GMT

 I'd like to see:

1. JIT, or something else to speed up the applications in general.
2. Implement javax.sound.sampled classes (not really related to


What's slow on Android?

by dmanpearl » Wed, 14 Jan 2009 00:56:53 GMT

 > If you can have just 3 things be much faster, what will they be?

I need to make a custom camera filter display based on the camera
preview run faster than I am currently able to do.  We must get the
display rate up to 5 to 10+ frames per second, through the G1 can
barely display 1 fps.  In order to do this, here are three requests:
1. Faster delivery of individual preview frames to the preview
callback onPreviewFrame.
2. Support another data format that I can decode more quickly than the
current YCbCr_422_SP data and support configurable preview frame size.
3. Faster looping through every pixel in the image in order to process
per-pixel calculations more quickly.
P.S. iPhone suffers the same issues, but many J2ME devices do not.  As
far as I am concerned, this is strictly an issue of camera API support
in the JVM.

 - Regards, David Manpearl


What's slow on Android?

by A T » Wed, 14 Jan 2009 01:05:11 GMT

 s a side note to answer your question (if anyone cares), call log is slow
when scrolling because every time it binds a new list item it checks if its
associated data needs to be updated.... Not a problem unless you're
scrolling super fast, which you do if you have a giant log like *some*
people :)

On Mon, Jan 12, 2009 at 5:59 PM, Stoyan Damov <stoyan.da...@gmail.com>wrote:


What's slow on Android?

by blindfold » Wed, 14 Jan 2009 04:02:16 GMT

 1. JIT compiler, for real-time signal and media processing.
2. Read/write access to audio buffers, to avoid caching to flash
3. Support for at least one of the Bitmap.Config formats in using the
camera preview callback, such that one need not decode an image pixel
by pixel but can instead use BitmapFactory.decodeByteArray().

I hope that 2 and 3 will be covered by Cupcake, because we do not want
code fragmentation to arise from solutions to the current performance



What's slow on Android?

by patg » Fri, 06 Mar 2009 05:19:41 GMT

 I will cast my votes for

1. JIT (AOT if you like)
2. Faster GC
3. API access to all perpherials (e.g. bluetooth and USB)
4. Boot loader to boot from choice of several images; much like a PC
booting different operating systems.

Items 1 and 2 together may very well end up being a platform killer
and are extremely important for google to tackle immediately.  While
we are still evaluating Android, the poor performance of the VM is
likely to end up being a platform killer for us.  Unfortunately I
cannot detect any recent movement in this direction from google.

I am curious why garbage collection is so frequent and so expensive.
I suspect the frequency is tied to the lack of JIT optimizing away
useless memory allocations and a really small heap.  The expense is
more curious.  The typical GC activity takes a little more than 100ms
which seems like an very long time on a 500 Mhz processor (50 million
instructions).  I would think you should be able to get it done in
under 1 millisecond.  Perhaps the GC is written in Java :).


What's slow on Android?

by Dianne Hackborn » Fri, 06 Mar 2009 07:09:55 GMT


Probably because you are allocating too many objects.  If it is causing you
problems, you should start looking at temporary objects and such that your
app is allocating.  Not only will this reduce the amount of garbage
collection, it will generally speed up your app because it is doing less

The typical GC activity takes a little more than 100ms

Um.  It takes on the order of 1 ms just to do an IPC across processes.

1. The CPU is not running at 500 MHz.
2. Garbage collection is very memory bus bound, and the memory bus is going
a fair amount slower (and in general memory buses on mobile devices are far
slower than what you may expect from experience on desktop systems).

Dianne Hackborn
Android framework engineer

Note: please don't send private questions to me, as I don't have time to
provide private support.  All such questions should be posted on public
forums, where I and others can see and answer them.


Other Threads

1. moving Views and View.getWidth(), getHeight(), etc..

Are you trying to get the widthe before it has been displayed on the
screen?  If so it will be 0 because the width doesn't get calculated until
it is displayed

I am working on an app that requires widgets to be repositioned at
runtime. The docs say getWidth() should return the width of View at
runtime but the only value  getWidth() returns is 0. Can someone point
me in the right direction on how to get the dimensions of a view at


2. change security permissions of any application

a) Root your phone

b) Not that I am aware of

There are only 10 types of people in the world...
Those who know binary and those who don't.


3. Installing android SDK

4. moving Views and View.getWidth(), getHeight(), etc..

5. No actions in intent filter at /data/app/ApiDemos.apk

6. Pretty code program (for all developers)...

7. Simulating accelerometer events natively?