66cd54a6e6
benefits for optimizing views. bug: 18356775 Change-Id: Ideac15f1eb42fe4c2e291800458bf739cd6a9b4a
73 lines
2.9 KiB
Plaintext
73 lines
2.9 KiB
Plaintext
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>
|