핵심 정리
text
VerticalLayoutGroup
ContentSizeFitter구조 이해
VerticalLayoutGroup,HorizontalLayoutGroup,GridLayoutGroup,ContentSizeFitter는 UI를 빨리 만드는 데 매우 유용하지만, 변경이 일어날 때마다 배치 계산이 다시 돌 수 있다는 점이 비용의 핵심입니다.- 특히 동적 목록에
Layout Group + Content Size Fitter + 자식 크기 변경이 겹치면, 편리함은 크지만 rebuild와 layout 계산이 눈에 띄게 늘 수 있습니다. - 그래서 선택 기준은 단순히 "자동 정렬이 편하다"가 아니라 "이 영역이 자주 바뀌는가, 아이템 수가 많은가, 디자이너가 자주 수정하는가"입니다.
- 고정 HUD, 스코어 프레임, 항상 같은 자리의 버튼은 수동 배치가 더 단순할 수 있고, 채팅 목록, 인벤토리 리스트, 가변 길이 텍스트는 자동 레이아웃이 훨씬 잘 맞습니다.
체크포인트
| 상황 | 적합한 선택 |
|---|---|
| 채팅 로그, 인벤토리처럼 동적 리스트 | Layout Group + Content Size Fitter |
| 고정 HUD, 변하지 않는 메뉴 버튼 | 수동 RectTransform 배치 |
| 텍스트 길이에 따라 컨테이너 크기 조정 | Content Size Fitter |
| Layout Group 있는데 UI 느려짐 | Profiler에서 layout rebuild 비용 확인 |
| 선택지 | 더 잘 맞는 상황 | 경계할 비용 |
|---|---|---|
| 수동 배치 | 구조가 고정되고 자주 안 바뀌는 HUD | 초기 배치는 손이 더 감 |
| Layout Group | 목록 길이와 순서가 자주 바뀜 | 자식 변경 시 rebuild 전파 |
| Content Size Fitter | 텍스트 길이·아이템 수에 따라 컨테이너가 커져야 함 | Layout Group과 겹치면 계산 반복 위험 |
| 둘의 조합 | 툴팁, 채팅처럼 실제로 가변 크기여야 함 | 계층 깊이가 깊을수록 병목이 커짐 |
주의할 점
Layout Group을 전체 UI에 일괄 적용하면 나중에 병목을 찾아도 손댈 곳이 너무 많아집니다. 동적으로 바뀌는 구간에만 국소적으로 적용하세요.
text
// ❌ 고정 HUD에 Layout Group → 불필요한 rebuild 발생
Canvas
└─ HorizontalLayoutGroup (고정 버튼 4개)
└─ Button1, Button2, Button3, Button4 ← 변하지 않는데 매 변경 시 rebuild
// ✅ 수동 배치 vs Layout Group 구분
Canvas
└─ HUDPanel (수동 RectTransform) ← 고정 구조
└─ ChatLogPanel
└─ VerticalLayoutGroup ← 동적 목록에만 적용
└─ ChatEntry (동적 추가)스크롤 목록에 Layout Group + Content Size Fitter + 자식마다 LayoutElement를 겹겹이 얹으면, 아이템 추가 하나가 계층 전체 rebuild로 번질 수 있습니다.
text
// ❌ 채팅 항목 1개 추가할 때마다 상위 전체 레이아웃 재계산
ScrollView
Content (VerticalLayoutGroup + ContentSizeFitter)
ChatEntry (LayoutElement)
ChatEntry (LayoutElement)
ChatEntry (LayoutElement)
// ✅ 정말 가변인 구간만 자동화
ScrollView
Content (VerticalLayoutGroup)
ChatEntry (고정 높이 또는 제한된 LayoutElement)
입력창, 상단 HUD, 배경 패널은 별도 수동 배치참고 링크
3 sources