기본 레이아웃 구조를 사용하면
설계하는 것입니다. 그러나 앱에 추가하는 각 위젯과 레이아웃은
초기화, 레이아웃, 그리기가 필요합니다. 예를 들어
인스턴스
LinearLayout
뷰 계층 구조가 지나치게 깊어질 수 있습니다 또한 여러 개의
layout_weight를 사용하는 LinearLayout 인스턴스
매개변수는 각 하위 요소를 두 번 측정해야 하므로 특히 비용이 많이 들 수 있습니다.
이는 다음과 같이 레이아웃이 반복적으로 확장될 때 특히 중요합니다.
에서 사용되는 경우
RecyclerView
사용 가능한 기기 및 실행 중인 기기 목록을 보여주는 Layout Inspector
구성할 수 있습니다. Windows 탭에서 구성요소를 선택하고
Layout Inspector를 사용하여 선택한 구성요소의 레이아웃 계층 구조를 확인합니다.
예를 들어 그림 2는 그림에 표시된 목록 항목의 레이아웃을 보여줍니다.
1.
그림 2. 레이아웃의 레이아웃 계층 구조
그림 1: LinearLayout의 중첩된 인스턴스 사용
레이아웃 수정
중첩 레이어로 인해 이전 레이아웃 성능이 느려지기 때문입니다.
LinearLayout를 사용하는 경우
즉, 레이아웃을 얕고 넓게 만드는 것이 아니라
좁고 깊습니다. 가
ConstraintLayout
루트 노드가 이러한 레이아웃을 허용하기 때문입니다. 이 디자인을 사용하도록 변환하면
ConstraintLayout를 사용하면 레이아웃이 2단계 계층 구조가 됩니다.
대부분의 차이는 다음과 같이 layout_weight를 사용하기 때문입니다.
LinearLayout 설계로 인해 측정 속도가 느려질 수 있습니다. 이것은 1
각 레이아웃이 어떻게 사용되는지 보여주는 예입니다. 주의 깊게
50개가 넘는 로드를 구현해야 합니다
일부 복잡한 레이아웃에서는 시스템에서 동일한 UI를 측정하느라 시간을 낭비할 수 있습니다.
요소를 두 번 이상 사용할 수 없습니다. 이 현상은 이중 과세라고 합니다. 대상
이중 과세 및 이를 방지하는 방법에 대한 자세한 내용은
실적
및 뷰 계층 구조를 참조하세요.
린트 사용
린트 도구를 실행하는 것이 좋습니다.
를 사용하여 가능한 뷰 계층 구조 최적화를 검색합니다. 린트
layoutopt 도구를 대체하고 더 많은 기능을 제공합니다. 다음은
린트 예시
규칙:
복합 드로어블을 사용합니다. 다음과 같은 LinearLayout를 처리할 수 있습니다.
포함
ImageView
및
<ph type="x-smartling-placeholder">TextView</ph>
더 효율적으로 처리할 수 있습니다.
루트 프레임을 병합합니다. 레이아웃의 루트가
FrameLayout
배경이나 패딩을 제공하지 않는 경우
병합 태그가 약간 더 효율적입니다.
쓸모없는 잎은 제거하세요. 하위 요소가 없는 레이아웃을 삭제하거나
눈에 띄지 않으므로 배경이 없어 더 평평하게 할 수 있습니다.
효율적인 레이아웃 계층 구조를 만듭니다.
쓸모없는 부모 삭제 다음 요소가 없는 하위 요소가 있는 레이아웃을 삭제할 수 있습니다.
형제 자매는
ScrollView
또는 루트 레이아웃이 있고 배경이 없습니다. 또한 포드의 상태를
하위 뷰를 상위 요소에 직접 표시하여 더 평평하고 효율적으로 할 수 있습니다.
레이아웃 계층 구조로 되어 있습니다.
깊은 레이아웃은 피하세요. 중첩이 너무 많은 레이아웃은
확인할 수 있습니다 다음과 같이 더 평평한 레이아웃을 사용해 보세요.
ConstraintLayout,
성능을 개선할 수 있습니다 린트 검사의 기본 최대 깊이는 10입니다.
린트 도구의 또 다른 이점은 Android 스튜디오에 통합한다는 것입니다. 린트
프로그램을 컴파일할 때마다 자동으로 실행됩니다. Android 스튜디오를 사용하면
특정 빌드 변형이나 모든 빌드에 대해 린트 검사를 실행할 수도 있음
있습니다.
또한 GCP 내에서 검사 프로필을 관리하고 검사를 구성할 수 있습니다.
Android 스튜디오에서 File > 설정 > 프로젝트
설정 옵션을 선택합니다. 'Inspection Configuration'(검사 구성) 페이지가
검사:
그림 4. 검사 구성 페이지
린트는 일부 문제를 자동으로 수정하고 다른 문제에 관한 제안을 제공할 수 있습니다.
문제의 코드로 바로 이동하여 검토를 받으세요.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 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 layout hierarchies\n\nTry the Compose way \nJetpack Compose is the recommended UI toolkit for Android. Learn how to work with layouts in Compose. \n[Layout Inspector in Compose →](/jetpack/compose/tooling/layout-inspector) \n\nIt's a common misconception that using the basic layout structures leads to\nthe most efficient layouts. However, each widget and layout you add to your app\nrequires initialization, layout, and drawing. For example, using nested\ninstances of\n[LinearLayout](/reference/android/widget/LinearLayout)\ncan lead to an excessively deep view hierarchy. Furthermore, nesting several\ninstances of `LinearLayout` that use the `layout_weight`\nparameter can be especially expensive, as each child needs to be measured twice.\nThis is particularly important when the layout is inflated repeatedly, such as\nwhen used in a\n[RecyclerView](/reference/androidx/recyclerview/widget/RecyclerView).\n\nThis document shows how to use\n[Layout Inspector](/studio/debug/layout-inspector) and\n[lint](/studio/write/lint) to examine and optimize your layout.\n\nInspect your layout\n-------------------\n\nThe Android SDK tools includes the\n[Layout Inspector](/studio/debug/layout-inspector) tool, which lets\nyou analyze your layout while your app is running. Using this tool helps you\ndiscover inefficiencies in the layout performance.\n\nLayout Inspector lets you select running processes on a connected device or\nemulator, then display the layout tree. The traffic lights on each block\nrepresent its Measure, Layout, and Draw performance, helping you identify\npotential issues.\n\nFor example, figure 1 shows a layout that's used as an item in a\n`RecyclerView`. This layout shows a small bitmap image on the left\nand two stacked items of text on the right. It is especially important that\nlayouts like this that are inflated multiple times are optimized, as the\nperformance benefits are multiplied.\n**Figure 1.** Conceptual layout for an item in a [RecyclerView](/reference/androidx/recyclerview/widget/RecyclerView).\n\nLayout Inspector shows a list of available devices and their running\ncomponents. Choose your component from the **Windows** tab, and click\n**Layout Inspector** to view the layout hierarchy of the selected component.\nFor example, figure 2 shows the layout for the list item illustrated by figure\n1.\n**Figure 2.** Layout hierarchy for the layout in figure 1, using nested instances of `LinearLayout`.\n\nRevise your layout\n------------------\n\nBecause the preceding layout performance slows down due to a nested\n`LinearLayout`, you might improve performance by flattening the\nlayout---in other words, making the layout shallow and wide, rather than\nnarrow and deep. A\n[ConstraintLayout](/develop/ui/views/layout/constraint-layout)\nas the root node allows for such layouts. When you convert this design to use\n`ConstraintLayout`, the layout becomes a two-level hierarchy: \n\n```xml\n \u003candroidx.constraintlayout.widget.ConstraintLayout\n xmlns:android=\"http://schemas.android.com/apk/res/android\"\n xmlns:app=\"http://schemas.android.com/apk/res-auto\"\n xmlns:tools=\"http://schemas.android.com/tools\"\n android:id=\"@+id/root\"\n android:layout_width=\"match_parent\"\n android:layout_height=\"52dp\"\n android:background=\"#e4e6e4\"\n android:padding=\"4dp\"\u003e\n\n \u003cImageView\n android:id=\"@+id/image\"\n android:layout_width=\"48dp\"\n android:layout_height=\"48dp\"\n android:background=\"#5c5c74\"\n android:contentDescription=\"An example box\"\n app:layout_constraintBottom_toBottomOf=\"parent\"\n app:layout_constraintStart_toStartOf=\"parent\"\n app:layout_constraintTop_toTopOf=\"parent\" /\u003e\n\n \u003cTextView\n android:id=\"@+id/title\"\n android:layout_width=\"0dp\"\n android:layout_height=\"0dp\"\n android:layout_marginStart=\"4dp\"\n android:background=\"#745c74\"\n app:layout_constraintBottom_toTopOf=\"@+id/subtitle\"\n app:layout_constraintEnd_toEndOf=\"parent\"\n app:layout_constraintStart_toEndOf=\"@id/image\"\n app:layout_constraintTop_toTopOf=\"parent\" /\u003e\n\n \u003cTextView\n android:id=\"@+id/subtitle\"\n android:layout_width=\"0dp\"\n android:layout_height=\"0dp\"\n android:background=\"#7e8d6e\"\n app:layout_constraintBottom_toBottomOf=\"parent\"\n app:layout_constraintEnd_toEndOf=\"parent\"\n app:layout_constraintStart_toStartOf=\"@id/title\"\n app:layout_constraintTop_toBottomOf=\"@+id/title\" /\u003e\n \u003c/androidx.constraintlayout.widget.ConstraintLayout\u003e\n \n```\n\nInspection of the new layout looks like this:\n**Figure 3.** Layout Inspector 3D mode.\n\nThe benefits of this are multiplied, because this layout is used for every\nitem in a list.\n\nMost of the difference is due to the use of `layout_weight` in the\n`LinearLayout` design, which can slow down measurement. This is one\nexample of how each layout has appropriate uses. Carefully consider whether\nusing layout weight is necessary.\n\nIn some complex layouts, the system might waste effort measuring the same UI\nelement more than once. This phenomenon is called *double taxation* . For\nmore information about double taxation and how to prevent it, see\n[Performance\nand view hierarchies](/topic/performance/rendering/optimizing-view-hierarchies).\n\nUse lint\n--------\n\nIt's good practice to run the [lint](/studio/write/lint) tool\non your layout files to search for possible view hierarchy optimizations. Lint\nreplaces the layoutopt tool and has greater functionality. The following are\nexamples of lint\n[rules](http://tools.android.com/tips/lint-checks):\n\n- Use compound drawables. You can handle a `LinearLayout` that contains an [ImageView](/reference/android/widget/ImageView) and a [TextView](/reference/android/widget/TextView) more efficiently as a compound drawable.\n- Merge root frame. If the root of a layout is a [FrameLayout](/reference/android/widget/FrameLayout) that doesn't provide background or padding, you can replace it with a merge tag, which is slightly more efficient.\n- Remove useless leaves. You can remove a layout that has no children or no background---since it's invisible---for a flatter and more efficient layout hierarchy.\n- Remove useless parents. You can remove a layout with a child that has no siblings, isn't a [ScrollView](/reference/android/widget/ScrollView) or a root layout, and doesn't have a background. You can also move the child view directly into the parent for a flatter and more efficient layout hierarchy.\n- Avoid deep layouts. Layouts with too much nesting are bad for performance. Consider using flatter layouts, such as [ConstraintLayout](/develop/ui/views/layout/constraint-layout), to improve performance. The default maximum depth for lint checks is 10.\n\nAnother benefit of the lint tool is its integration into Android Studio. Lint\nautomatically runs whenever you compile your program. With Android Studio, you\ncan also run lint inspections for a specific build variant or for all build\nvariants.\n\nYou can also manage inspection profiles and configure inspections within\nAndroid Studio with the **File \\\u003e Settings \\\u003e Project\nSettings** option. The Inspection Configuration page appears with the\nsupported inspections:\n**Figure 4.** Inspection Configuration page.\n\nLint can automatically fix some issues, provide suggestions for others, and\njump directly to the offending code for review.\n\nFor more information, see\n[Layouts](/guide/topics/ui/declaring-layout) and\n[Layout\nresource](/guide/topics/resources/layout-resource#include-element)."]]