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. qtrace.insn

I need to get a trace of dynamic instructions and the corresponding
static instructions executed for applications on teh ARM emulator. I
am using Android 2.1 as my backend. I see that startNativeTracing
produces qtrace.insn, qtrace.bb, qtrace.pid and qtrace.static. How do
I parse these files ?

In general, if I want to generate instruction traces for my
application then what would be a good way to do it?



2. Recovery RA-hero-v1.6.2

Yang punya Hero, silahkan ke :



   - full ADB access in recovery mode
   - Awesome Care-Bear version! (Blame packetlss for talking me into it )
   - Busybox v1.15.3
   - HW-Key navigation (volume keys + CALL-ANSWER) option
   - Extended menu :
      - Reboot system now :: reboot your phone
      - Go to console :: bring up the console
      - USB-MS Toggle :: enable/disable USB mass storage (use when the phone
      is connected to your PC)
      - Backup/Restore (recovery partition not included!)
         - Nand backup :: Make a Nand backup
         - Nand + ext backup :: Make a Nand + ext backup
         - Nand restore :: Restore a Nand backup
         - BART backup :: Make a BART backup (Nand + ext)
         - BART restore :: Restore latest BART backup
      - Flash zip from sdcard :: Flash a zip update file from your sdcard
      - Wipe
         - Wipe data/factory reset :: Wipe /data and /cache
         - Wipe Dalvik-cache :: Wipe Dalvik-cache both on /data and ext
         - Wipe SD:ext partition : Wipe the ext partition on your sdcard
         - Wipe battery stats : Wipe the battery stats in /data
         - Wipe rotate settings : Wipe the sensor settings in /data
      - Partition sdcard
         - Partition SD :: Interactive SD partitioning
         - Repair SD:ext :: Repair the ext partition
         - SD:ext2 to ext3 :: Convert ext2 to ext3
         - SD:ext3 to ext4 :: Convert ext3 to ext4
      - Other
         - Fix apk uid mismatches :: Does extacly that
         - Move apps+dalv to SD :: Moves all apps and Dalvik-cache to sdcard
         (This will NOT enable apps2sd!)
         - Move recovery.log to SD :: Moves the recovery log file to your
         sdcard. (Use when you want more detailed recovery log information)
      - Power off :: Powers off your phone
   - Scripts available from console :
      - Nandroid
      enter "nandroid-mobile.sh" to start.
      - BART 
      and Restore Tool) : enter "utility" to start.
      - switchrom.sh
      enter "switchrom" or "u" to start.
      - sdparted
      enter "sdparted" to start.


"Indonesian Android Community [id-android]" 

3. Help: Magic 32A, setelah join latitude maps jadi force close

4. About using Hierarchy Viewer

5. DDMS on windows stop detecting Emulator after sometime

6. Battery events

7. any ideas about how to lunch the Account and sync settings screen from within my app main activity