Google I/O 2012 - For Butter or Worse: Smoothing Out Performance in Android UIs
608 8 60704
Chet Haase, Romain Guy
Great user experience requires buttery smoothness in rendering and animating your interface; your app must have a good, consistent frame rate. This session deep-dives into our work on the Android framework to find and fix performance issues, along with tips on how you can do the same for your applications.
For all I/O 2012 sessions, go to https://developers.google.com/io/
By anonymous 2017-09-20
As mention by Guykun and kcoppock, if you are only using the View widgets or Canvas you normally don't look for FPS to determine visual performance.
As you don't mention what you are doing other than 'not a game' you may want to review how Android does drawing.
Most of the performance issues come from doing stuff on the UI thread. Use Strict Mode for finding problems.
Also use the tools to find performance hot spots:
[Edit August 2017: Google has improved the training documentation regarding performance]
And if you want more details of what's going on under the hood see the Google IO session on what they did for Hardware Accelerated Rendering
[Post Google IO 2012 Update]
For Jelly Bean, Google has done additional work on UI performance. See the Google IO 2012 session:
By anonymous 2017-09-20
I've been puzzling over an animation glitch and stumbled upon this question. Tried to answer below:
What is the next display frame?
This is when all the drawing, layouts and inputs are processed.
The concept of vertical syncing (VSync) is used in the Choreographer class after Android 4.1. This is a signal that is sent traditionally from hardware to say the screen is ready to be redrawn. (It's originates in Cathode Ray Tubes) This is typically around 60Hz on monitors.
The Choreographer is the 'UI threads' message handling loop. On every VSync, the UI messages are processed. These messages will handle inputs and redraw the display. (The Choreographer will also do other things such as skipping frames if the UI is running too slow - this is a common message on the debug console!)
This message loop handling constitutes a frame. When will it be called - every 1/60th of a second on a 60Hz frame rate.
This video from Google I/O 2012 describes this vsync and the choreographer in more detail.
What is the difference between postInvalidateOnAnimation() over postInvalidate()?
When smooth animations are required use postInvalidateOnAnimation, when redraw is required use postInvalidate().
This was quite hard to answer, both of these methods are for threads communicating with the UI Thread. So I dug into the Choreographer code
and found this in doFrame()
doCallbacks(Choreographer.CALLBACK_INPUT, frameTimeNanos); doCallbacks(Choreographer.CALLBACK_ANIMATION, frameTimeNanos); doCallbacks(Choreographer.CALLBACK_TRAVERSAL, frameTimeNanos);
postInvalidateOnAnimation will put a callback into the animation callbacks and postInvalidate will will put into the traversal callbacks.
The key difference for me is that the animation callbacks are called before the traversal callbacks (layouts, draws).
This means that animation call backs will be called at almost exactly 60fps (processed first) whereas the traversal callbacks may have some small jitter as the layouts and view drawing is done (less than 1/60 second jitter but probably still noticeable)