맞춤 뷰 최적화
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
동작과 상태 간 전환에 응답하는 잘 디자인된 뷰가 있는 경우 뷰가 빠르게 실행되는지 확인합니다. 재생 중에 UI가 느려지거나 버벅거리는 일을 방지하려면 애니메이션이 초당 60프레임으로 일관되게 실행되어야 합니다.
보기 속도 높이기
뷰 속도를 높이려면 자주 호출되는 루틴에서 불필요한 코드를 제거합니다. onDraw()
로 시작하면 최대의 효과를 얻을 수 있습니다. 특히 할당은 버벅거림을 유발하는 가비지 컬렉션으로 이어질 수 있으므로 onDraw()
에서 할당을 제거합니다. 초기화 중 또는 애니메이션 사이에 객체를 할당합니다. 애니메이션이 실행되는 동안에는 절대로 할당하지 마세요.
onDraw()
를 간소화하는 것 외에도 최대한 자주 호출되지 않도록 해야 합니다. 대부분의 onDraw()
호출은 invalidate()
호출의 결과이므로 불필요한 invalidate()
호출을 제거합니다.
큰 비용이 드는 또 하나의 작업은 레이아웃 순회입니다. 뷰에서 requestLayout()
를 호출하면 Android UI 시스템은 전체 뷰 계층 구조를 순회하여 각 뷰의 크기가 얼마나 되어야 하는지 찾습니다. 충돌하는 측정이 발견되면 계층 구조를 여러 번 순회할 수 있습니다. UI 디자이너는 중첩된 ViewGroup
객체의 심층 계층 구조를 만듭니다. 이러한 심층 뷰 계층 구조로 인해 성능 문제가 발생하므로 뷰 계층 구조를 가능한 한 얕게 만들어야 합니다.
복잡한 UI가 있다면 레이아웃을 실행할 맞춤 ViewGroup
작성을 고려해 보세요.
기본 제공 뷰와 달리 맞춤 뷰는 애플리케이션별로 하위 요소의 크기와 모양을 가정할 수 있으므로 측정값을 계산하기 위해 하위 요소를 순회하는 것을 피할 수 있습니다.
예를 들어 모든 하위 뷰에 맞게 자체 크기를 조정하지 않는 맞춤 ViwGroup
가 있는 경우 모든 하위 뷰를 측정하는 오버헤드가 방지됩니다. 다양한 사용 사례에 적합한 기본 제공 레이아웃을 사용하는 경우에는 이러한 최적화가 불가능합니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-27(UTC)
[[["이해하기 쉬움","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"]],["최종 업데이트: 2025-07-27(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."]]