핵심 정리
text
Canvas
Static HUD Canvas
Dynamic Popup Canvas구조 이해
- UGUI에서는 같은 Canvas 아래 UI가 바뀌면 geometry, layout, batching이 함께 다시 계산될 수 있습니다. 그래서 성능 문제는 "UI가 많다"보다 "변경 범위가 너무 넓다"에서 자주 시작됩니다.
- 자주 바뀌는 수치 텍스트, cooldown, 알림, 인벤토리 목록을 고정 배경, 프레임 장식, 거의 변하지 않는 HUD와 같은 Canvas에 두면 작은 변화가 큰 rebuild로 번집니다.
- 실무에서는
Static HUD,Dynamic HUD,Popup,Overlay처럼 변경 빈도와 표시 수명으로 Canvas를 나누는 편이 읽기 쉽습니다. - 다만 Canvas를 무한정 잘게 쪼개는 것도 해답은 아닙니다. 관리 복잡도와 draw 구조가 늘 수 있으니, "같이 갱신되는가"를 기준으로 의미 있게 경계를 잡아야 합니다.
체크포인트
| 상황 | 적합한 선택 |
|---|---|
| 배경·프레임처럼 거의 안 바뀌는 HUD | Static Canvas로 분리 |
| 숫자·타이머처럼 매 프레임 바뀌는 UI | Dynamic Canvas로 분리 |
| 열고 닫힘이 뚜렷한 팝업 UI | 독립 Popup Canvas |
| Canvas 분리 효과 있는지 확인 | Profiler에서 Canvas.SendWillRenderCanvases 비용 실측 |
| 분리 기준 | 더 잘 맞는 방식 | 이유 |
|---|---|---|
| 같은 주기로 같이 갱신되는가 | 같은 Canvas에 유지 | rebuild 경계를 자연스럽게 맞출 수 있음 |
| 자주 바뀌는가 vs 거의 안 바뀌는가 | Static/Dynamic 분리 | 작은 변경이 전체로 번지는 걸 막음 |
| 열고 닫히는 수명주기가 독립적인가 | Popup Canvas 분리 | 토글 비용과 추적 범위를 줄일 수 있음 |
| 요소 하나하나가 독립적인가 | 무조건 분리하지 않음 | Canvas를 너무 잘게 쪼개면 관리 복잡도만 증가 |
주의할 점
Canvas를 무분별하게 쪼개면 hierarchy만 복잡해집니다. Profiler에서 rebuild가 실제 병목인지 먼저 확인하고 분리하세요.
text
// ❌ 모든 UI를 하나의 Canvas에 — 숫자 하나 바뀌어도 전체 rebuild
Canvas (Root)
└─ BackgroundImage ← 고정
└─ HPBar ← 자주 바뀜
└─ TimerText ← 매 프레임 바뀜
└─ InventoryPanel ← 토글 가능
// ✅ 변경 빈도 기준으로 Canvas 분리
Canvas (Static HUD) ← 배경, 프레임
Canvas (Dynamic HUD) ← HP, Timer — rebuild 범위 격리
Canvas (Popup) ← 열고 닫히는 UI 독립반대로 버튼 하나, 아이콘 하나마다 Canvas를 따로 두는 식의 과분할도 좋지 않습니다. 같은 빈도로 갱신되는 UI는 묶고, 갱신 주기가 다른 덩어리만 나누세요.
text
// ❌ 요소마다 Canvas 분리
Canvas (HP Label)
Canvas (HP Bar)
Canvas (Ammo Text)
Canvas (Crosshair)
// 관리와 정렬은 복잡해졌지만 실제 rebuild 경계 이점은 작을 수 있음
// ✅ 의미 있는 덩어리로 분리
Canvas (Static HUD Frame)
Canvas (Dynamic Combat HUD)
Canvas (Popup)참고 링크
2 sources