Optimizing the View

This lesson teaches you to

You should also read

Try it out

Now that you have a well-designed view that responds to gestures and transitions between states,
you need to ensure
that the view runs fast. To avoid a UI that feels sluggish or stutters during playback, you must
ensure that your
animations consistently run at 60 frames per second.

Do Less, Less Frequently

To speed up your view, eliminate unnecessary code from routines that are called frequently. Start
by working on
onDraw(), which will give you the biggest payback. In particular
you should eliminate
allocations in onDraw(), because allocations may lead to a garbage
collection that
would cause a stutter. Allocate objects during initialization, or between animations. Never make an
allocation while an
animation is running.

In addition to making onDraw() leaner, you should also make sure
it's called as
infrequently as possible. Most calls to onDraw() are the result of
a call to invalidate(), so eliminate unnecessary calls to invalidate(). When possible, call the four-parameter variant of invalidate()
rather than the version that takes no parameters. The no-parameter variant invalidates the entire
view, while the
four-parameter variant invalidates only a specified portion of the view. This approach allows draw calls to
be more efficient and
can eliminate unnecessary invalidation of views that fall outside the invalid rectangle.

Another very expensive operation is traversing layouts. Any time a view calls requestLayout(), the Android UI system needs to traverse the entire view hierarchy to find out how
big each view needs
to be. If it finds conflicting measurements, it may need to traverse the hierarchy multiple times.
UI designers
sometimes create deep hierarchies of nested ViewGroup objects in
order to get the UI to
behave properly. These deep view hierarchies cause performance problems. Make your view hierarchies
as shallow as
possible.

If you have a complex UI, you should consider writing a custom ViewGroup to perform
its layout. Unlike the built-in views, your custom view can make application-specific assumptions
about the size and
shape of its children, and thus avoid traversing its children to calculate measurements. The
PieChart example shows how
to extend ViewGroup as part of a custom view. PieChart has child
views, but it never
measures them. Instead, it sets their sizes directly according to its own custom layout
algorithm.

Use Hardware Acceleration

As of Android 3.0, the Android 2D graphics system can be accelerated by the GPU (Graphics
Processing Unit) hardware
found in most newer Android devices. GPU hardware acceleration can result in a tremendous
performance increase for many
applications, but it isn't the right choice for every application. The Android framework
gives you the ability to finely control which parts of your application are or are not
hardware accelerated.

See Hardware Acceleration
in the Android Developers Guide for directions on how to enable acceleration at the
application, activity, or window level. Notice that in addition to the directions in
the developer guide, you must also set your application's target API to 11 or higher by
specifying <uses-sdk
android:targetSdkVersion="11"/> in your AndroidManifest.xml file.

Once you've enabled hardware acceleration, you may or may not see a performance increase.
Mobile GPUs are very good at certain tasks, such as scaling, rotating, and translating
bitmapped images. They are not particularly good at other tasks, such as drawing lines or curves. To
get the most out of GPU acceleration, you should maximize the number of operations that the GPU is
good at, and minimize the number of operations that the GPU isn't good at.

In the PieChart example, for instance, drawing the pie is relatively expensive. Redrawing the pie
each time it's
rotated causes the UI to feel sluggish. The solution is to place the pie chart into a child
View and set that
View's
layer type to LAYER_TYPE_HARDWARE, so that the GPU can cache it as
a static
image. The sample
defines the child view as an inner class of PieChart, which minimizes the amount of code
changes that are needed
to implement this solution.

After this code change, PieChart.PieView.onDraw() is called only when the view is first
shown. During the rest
of the application's lifetime, the pie chart is cached as an image, and redrawn at different
rotation angles by the GPU.
GPU hardware is particularly good at this sort of thing, and the performance difference is
immediately noticeable.

There is a tradeoff, though. Caching images as hardware layers consumes video memory, which is a
limited resource.
For this reason, the final version of PieChart.PieView only sets its layer type to
LAYER_TYPE_HARDWARE
while the user is actively scrolling. At all other times, it sets its layer type to
LAYER_TYPE_NONE, which
allows the GPU to stop caching the image.