Optimizing the View

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.

   private class PieView extends View {

       public PieView(Context context) {
           super(context);
           if (!isInEditMode()) {
               setLayerType(View.LAYER_TYPE_HARDWARE, null);
           }
       }
       
       @Override
       protected void onDraw(Canvas canvas) {
           super.onDraw(canvas);

           for (Item it : mData) {
               mPiePaint.setShader(it.mShader);
               canvas.drawArc(mBounds,
                       360 - it.mEndAngle,
                       it.mEndAngle - it.mStartAngle,
                       true, mPiePaint);
           }
       }

       @Override
       protected void onSizeChanged(int w, int h, int oldw, int oldh) {
           mBounds = new RectF(0, 0, w, h);
       }

       RectF mBounds;
   }

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.

Finally, don't forget to profile your code. Techniques that improve performance on one view might negatively affect performance on another.