优化自定义视图
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
如果您有一个精心设计的视图可以响应手势和状态之间的转换,请确保该视图快速运行。为避免播放过程中界面响应缓慢或卡顿,请确保动画始终以每秒 60 帧的速度运行。
加快观看速度
为了提高视图的运行速度,可从频繁调用的例程中剔除不必要的代码。从 onDraw()
开始,这将为您带来最大的回报。特别是应消除 onDraw()
中的分配,因为分配可能会导致垃圾回收,从而造成卡顿。请在初始化期间或动画之间分配对象。切勿在动画运行期间进行分配。
除了精简 onDraw()
之外,还应确保尽可能降低调用它的频率。对 onDraw()
的大多数调用都是调用 invalidate()
的结果,因此可以避免不必要的 invalidate()
调用。
另一种成本非常高昂的操作是遍历布局。当视图调用 requestLayout()
时,Android 界面系统会遍历整个视图层次结构,以确定每个视图所需的大小。如果发现冲突的测量值,可能会多次遍历层次结构。界面设计人员有时会创建由嵌套的 ViewGroup
对象组成的深层次结构。这些深层视图层次结构会导致性能问题,因此应尽可能浅层视图。
如果您的界面比较复杂,不妨考虑编写自定义 ViewGroup
来执行其布局。与内置视图不同,自定义视图可以对其子项的尺寸和形状做出特定于应用的假设,从而避免遍历其子项以计算测量值。
例如,如果您有一个自定义 ViwGroup
,它不通过调整自身大小来适应其所有子视图,就可以避免测量所有子视图所产生的开销。如果您使用适合各种用例的内置布局,则无法进行此优化。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-07-27。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["没有我需要的信息","missingTheInformationINeed","thumb-down"],["太复杂/步骤太多","tooComplicatedTooManySteps","thumb-down"],["内容需要更新","outOfDate","thumb-down"],["翻译问题","translationIssue","thumb-down"],["示例/代码问题","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-07-27。"],[],[],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."]]