Optimize a custom view
Stay organized with collections
Save and categorize content based on your preferences.
When you have a well-designed view that responds to gestures and transitions between states, make
sure the view runs fast. To avoid a UI that feels sluggish or stutters during playback, make sure
animations consistently run at 60 frames per second.
Speed up your view
To speed up your view, eliminate unnecessary code from routines that are called frequently. Start
with
onDraw()
,
which gives you the biggest payback. In particular, eliminate allocations in onDraw()
,
because allocations might lead to a garbage collection that causes a stutter. Allocate objects
during initialization or between animations. Never make an allocation while an animation is
running.
In addition to making onDraw()
leaner, 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()
.
Another very expensive operation is traversing layouts. When a view calls
requestLayout()
, the
Android UI system traverses the entire view hierarchy to find how big each view needs to be. If it
finds conflicting measurements, it might traverse the hierarchy multiple times. UI designers
sometimes create deep hierarchies of nested
ViewGroup
objects. These deep view
hierarchies cause performance problems, so make your view hierarchies as shallow as possible.
If you have a complex UI, 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 therefore avoid traversing its children to calculate measurements.
For example, if you have a custom ViwGroup
that doesn't adjust its own size to fit
all its child views, you avoid the overhead of measuring all the child views. This optimization
isn't possible if you use the built-in layouts that cater to a wide range of use-cases.
Content and code samples on this page are subject to the licenses described in the Content License. Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.
Last updated 2024-02-22 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2024-02-22 UTC."],[],[],null,["# Optimize a custom view\n\nWhen you have a well-designed view that responds to gestures and transitions between states, make\nsure the view runs fast. To avoid a UI that feels sluggish or stutters during playback, make sure\nanimations consistently run at 60 frames per second.\n\nSpeed up your view\n------------------\n\nTo speed up your view, eliminate unnecessary code from routines that are called frequently. Start\nwith\n[onDraw()](/reference/android/view/View#onDraw(android.graphics.Canvas)),\nwhich gives you the biggest payback. In particular, eliminate allocations in `onDraw()`,\nbecause allocations might lead to a garbage collection that causes a stutter. Allocate objects\nduring initialization or between animations. Never make an allocation while an animation is\nrunning.\n\nIn addition to making `onDraw()` leaner, make sure it's called as infrequently as\npossible. Most calls to `onDraw()` are the result of a call to\n[invalidate()](/reference/android/view/View#invalidate()), so eliminate\nunnecessary calls to `invalidate()`.\n\nAnother very expensive operation is traversing layouts. When a view calls\n[requestLayout()](/reference/android/view/View#requestLayout()), the\nAndroid UI system traverses the entire view hierarchy to find how big each view needs to be. If it\nfinds conflicting measurements, it might traverse the hierarchy multiple times. UI designers\nsometimes create deep hierarchies of nested\n[ViewGroup](/reference/android/view/ViewGroup) objects. These deep view\nhierarchies cause performance problems, so make your view hierarchies as shallow as possible.\n\nIf you have a complex UI, consider writing a custom `ViewGroup` to perform its layout.\nUnlike the built-in views, your custom view can make application-specific assumptions about the size\nand shape of its children and therefore avoid traversing its children to calculate measurements.\n\nFor example, if you have a custom `ViwGroup` that doesn't adjust its own size to fit\nall its child views, you avoid the overhead of measuring all the child views. This optimization\nisn't possible if you use the built-in layouts that cater to a wide range of use-cases."]]