1 page.title=Optimizing the View 2 parent.title=Creating Custom Views 3 parent.link=index.html 4 5 trainingnavtop=true 6 previous.title=Making the View Interactive 7 previous.link=making-interactive.html 8 9 @jd:body 10 11 <div id="tb-wrapper"> 12 <div id="tb"> 13 14 <h2>This lesson teaches you to</h2> 15 <ul> 16 <li><a href="#less">Do Less, Less Frequently</a></li> 17 </ul> 18 <h2>Try it out</h2> 19 <div class="download-box"> 20 <a href="{@docRoot}shareables/training/CustomView.zip" 21 class="button">Download the sample</a> 22 <p class="filename">CustomView.zip</p> 23 </div> 24 </div> 25 </div> 26 27 <p>Now that you have a well-designed view that responds to gestures and transitions between states, 28 ensure that the view runs fast. To avoid a UI that feels sluggish or stutters during playback, 29 ensure that animations consistently run at 60 frames per second.</p> 30 31 <h2 id="less">Do Less, Less Frequently</h2> 32 33 <p>To speed up your view, eliminate unnecessary code from routines that are called frequently. Start 34 by working on 35 {@link android.view.View#onDraw onDraw()}, which will give you the biggest payback. In particular 36 you should eliminate 37 allocations in {@link android.view.View#onDraw onDraw()}, because allocations may lead to a garbage 38 collection that 39 would cause a stutter. Allocate objects during initialization, or between animations. Never make an 40 allocation while an 41 animation is running.</p> 42 43 <p>In addition to making {@link android.view.View#onDraw onDraw()} leaner, also make sure 44 it's called as 45 infrequently as possible. Most calls to {@link android.view.View#onDraw onDraw()} are the result of 46 a call to {@link 47 android.view.View#invalidate() invalidate()}, so eliminate unnecessary calls to {@link 48 android.view.View#invalidate() 49 invalidate()}.</p> 50 51 <p>Another very expensive operation is traversing layouts. Any time a view calls {@link 52 android.view.View#requestLayout() 53 requestLayout()}, the Android UI system needs to traverse the entire view hierarchy to find out how 54 big each view needs 55 to be. If it finds conflicting measurements, it may need to traverse the hierarchy multiple times. 56 UI designers 57 sometimes create deep hierarchies of nested {@link android.view.ViewGroup ViewGroup} objects in 58 order to get the UI to 59 behave properly. These deep view hierarchies cause performance problems. Make your view hierarchies 60 as shallow as 61 possible.</p> 62 63 <p>If you have a complex UI, consider writing a custom {@link android.view.ViewGroup 64 ViewGroup} to perform 65 its layout. Unlike the built-in views, your custom view can make application-specific assumptions 66 about the size and 67 shape of its children, and thus avoid traversing its children to calculate measurements. The 68 PieChart example shows how 69 to extend {@link android.view.ViewGroup ViewGroup} as part of a custom view. PieChart has child 70 views, but it never 71 measures them. Instead, it sets their sizes directly according to its own custom layout 72 algorithm.</p> 73
