UI를 끄니 프레임이 나아졌다면 어디부터 손대야 할까요. 아틀라스를 합치거나 반투명 패널을 지우기 전에, 무엇이 줄었는지부터 구분할 필요가 있습니다. UI는 드로우콜을 늘리기도 하지만, 매번 레이아웃을 계산하거나 같은 픽셀을 여러 번 그려서 느려지기도 합니다.
이 글은 Canvas 기반 uGUI를 대상으로 합니다. UI Toolkit과 IMGUI에는 같은 처방을 그대로 적용하지 않습니다. 이전 제목에 있던 ‘70% 감소’는 비교 대상과 측정 조건을 본문에서 확인할 수 없어 제거했습니다. 아래는 특정 프로젝트의 성과 보고가 아니라 원인을 좁히는 절차입니다.
숫자가 비슷해도 느린 이유는 다를 수 있다
배칭이 잘 되면 여러 UI 요소를 묶어서 그릴 수 있습니다. 다만 서로 다른 머티리얼이나 텍스처, 마스크, 겹침에 따른 그리기 순서가 배칭을 나눌 수 있습니다. Frame Debugger에서 배치가 갈라지는 위치를 확인해야 합니다.
오버드로는 같은 화면 영역을 반복해서 처리하는 비용입니다. 화면 전체를 덮는 반투명 패널을 여러 장 겹치면 드로우콜이 적어도 GPU 작업량이 커질 수 있습니다. 알파 값이 있다는 사실만으로 드로우콜이 늘어난다고 단정할 수는 없습니다.
Canvas 갱신은 또 다른 문제입니다. 숫자 하나를 매 프레임 바꾸면서 큰 Canvas의 재계산이 발생한다면 CPU가 바빠집니다. 이때 텍스처 압축을 바꿔도 원인을 해결하지 못합니다.
같은 장면에서 하나씩 꺼 본다
카메라와 게임 상황을 고정한 뒤, HUD 전체를 끈 경우와 켠 경우를 먼저 비교합니다. 차이가 확인되면 팝업, 타이머, 목록처럼 덩어리를 나누어 끕니다. CPU와 GPU 중 어느 쪽 시간이 변하는지도 봅니다.
| 관찰한 변화 | 다음 확인 |
|---|---|
| 타이머 갱신을 멈추자 CPU 시간이 감소 | 텍스트·레이아웃·Canvas 갱신 |
| 큰 패널을 숨기자 GPU 시간이 감소 | 화면을 덮는 면적과 겹치는 레이어 |
| 아틀라스를 맞추자 배치 수 감소 | 머티리얼·마스크·렌더 순서 |
| 창을 열 때만 긴 프레임 발생 | 로딩, 생성, 레이아웃 초기 계산 |
표는 원인을 확정하는 판정표가 아닙니다. 다음에 볼 곳을 정하는 데 사용합니다. 예를 들어 패널을 숨기면 그 아래의 텍스트 갱신까지 중단될 수 있으므로 GPU와 CPU 비용이 함께 변할 수 있습니다.
바꿀 때 생기는 비용도 보자
정적인 배경과 자주 바뀌는 숫자를 서로 다른 Canvas에 두면 갱신 범위를 줄일 수 있습니다. 대신 Canvas 사이에는 배칭이 이어지지 않으므로 너무 잘게 나누면 배치가 늘어납니다. 분리 전후의 CPU 시간과 배치 수를 함께 봐야 합니다.
이미지와 텍스트를 종류별로 몰아놓는 방법도 시각적 겹침과 마스크를 망가뜨릴 수 있습니다. Hierarchy를 재배치한 뒤에는 숫자뿐 아니라 팝업 순서와 스크롤 영역을 확인합니다.
반투명 딤 패널을 불투명 텍스처로 바꾸면 뒤 장면과 섞이던 표현이 사라집니다. 텍스처의 알파를 없앴다고 셰이더의 블렌딩과 렌더 상태까지 자동으로 바뀌는 것도 아닙니다. 먼저 불필요한 겹침을 줄이고, 디자인상 허용되는지 확인하는 편이 낫습니다.
텍스트는 표시할 값이 바뀔 때만 갱신해 보세요. 초 단위 타이머라면 매 프레임 새 문자열을 만들 이유가 없습니다. 이 수정은 구조가 작고 전후 비교도 쉽습니다.
개선율을 적으려면 분모부터 남긴다
UI 배치가 100에서 30으로 줄면 UI 배치 기준 70% 감소입니다. 전체 배치가 300이었다면 다른 조건이 같을 때 230이므로 전체 감소율은 약 23.3%입니다. 둘을 같은 성과로 쓰면 안 됩니다. 이 숫자는 계산 예시입니다.
측정 기록에는 기기·OS, Unity와 렌더 파이프라인 버전, 빌드 설정, 해상도, 재현 동작을 남깁니다. 변경 전후 CPU/GPU 프레임 시간과 UI 배치 수, 측정 구간도 함께 적어야 합니다. 짧은 실행뿐 아니라 기기가 따뜻해진 뒤 같은 구간도 비교하면 실제 플레이에서 유지되는 개선인지 판단하기 좋습니다.