docs/html/training/custom-views/optimizing-view.jd

page.title=Optimizing the View
parent.title=Creating Custom Views
parent.link=index.html

trainingnavtop=true
previous.title=Making the View Interactive
previous.link=making-interactive.html

@jd:body

<div id="tb-wrapper">
    <div id="tb">

        <h2>This lesson teaches you to</h2>
        <ul>
            <li><a href="#less">Do Less, Less Frequently</a></li>
        </ul>
        <h2>Try it out</h2>
        <div class="download-box">
            <a href="{@docRoot}shareables/training/CustomView.zip"
                class="button">Download the sample</a>
            <p class="filename">CustomView.zip</p>
        </div>
    </div>
</div>

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

<h2 id="less">Do Less, Less Frequently</h2>

<p>To speed up your view, eliminate unnecessary code from routines that are called frequently. Start
by working on
{@link android.view.View#onDraw onDraw()}, which will give you the biggest payback. In particular
you should eliminate
allocations in {@link android.view.View#onDraw 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.</p>

<p>In addition to making {@link android.view.View#onDraw onDraw()} leaner, also make sure
it's called as
infrequently as possible. Most calls to {@link android.view.View#onDraw onDraw()} are the result of
a call to {@link
android.view.View#invalidate() invalidate()}, so eliminate unnecessary calls to {@link
android.view.View#invalidate()
invalidate()}.</p>

<p>Another very expensive operation is traversing layouts. Any time a view calls {@link
android.view.View#requestLayout()
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 {@link android.view.ViewGroup 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.</p>

<p>If you have a complex UI, consider writing a custom {@link android.view.ViewGroup
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 {@link android.view.ViewGroup 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.</p>