Sprite Atlas의 사용과 UI 최적화

Sprite Atlas

기본적인 사양과 내용은 유니티 메뉴얼 참고

• 다만, allow rotation시 이미지끼리 겹치는 상황이 발생할 수 있다
  • 그경우 Custom outine으로 경계선을 정해주고
  • Image Component에서 Use Sprite Mesh 옵션을 켜야 피할 수 있다.
  • 다만 이 경우는 image Type이 simple일때만 가능함.

• Atlas에서 특정 sprite를 script로 가져올 수 있음 (lazy binding)
  • GetSprite해서 바인딩 하는 시점에서 atlas를 load하기에 lazy하다는 표현.

---

UI최적화 관련 정리

빌드사이즈관련 - asset이 무압축일 경우 빌드사이즈 증가경향, png 권장.

 

UGUI는 Canvas마다 각자의 Vertex buffer를 가지고 있기 때문에 Canvas가 두개면 최소 두번의 Draw Call이 일어납니다. 이는 Canvas 하위에 Canvas가 존재하는 경우에도 증가하게 됩니다.

한번에 그려야 할 경우 하나의 캔버스 안에 넣어 주면 드로우콜을 줄일 수 있습니다.

 

Text(폰트) 는 별도의 TExture를 사용하기 때문에 별도의 Drawcall로 발생 합니다.

폰트당 생성이므로, 종류를 줄이면 드로우콜이 줄어듬

 

https://youtu.be/_wxitgdx-UI

문제: UI 캔버스에서 한두 가지 요소를 변경하면 캔버스 전체가 변경된 것으로 인식됩니다.

캔버스는 유니티 UI의 기본 컴포넌트입니다. 캔버스에 배치된 UI 컴포넌트를 나타내는 메시를 생성하고, UI 컴포넌트가 변경되면 메시를 다시 생성하며, GPU에 드로우 콜을 발행하여 UI가 실제로 표시되도록 합니다.

이러한 메시를 생성하는 데는 많은 자원이 소모될 수 있습니다. UI 요소를 배치로 수집하여 드로우 콜 횟수를 가능한 한 줄여야 합니다. 배치 생성에는 많은 자원이 소모되므로 필요한 경우에만 재생성하는 것이 좋습니다. 여기서 문제는 캔버스에서 하나 이상의 요소가 변경되면 전체 캔버스를 다시 분석하여 요소를 드로우하는 최적의 방식을 파악해야 한다는 점입니다.

​

솔루션: 캔버스를 분할합니다.

각 캔버스는 포함된 요소를 다른 캔버스의 요소로부터 분리하는 섬과 같습니다. 따라서, 기본 툴에서 캔버스를 분할하면 유니티 UI의 배칭 문제를 해결할 수 있습니다.

캔버스를 중첩할 수도 있습니다. 그러면 디자이너가 여러 캔버스에 걸쳐 다양한 요소가 화면의 어느 위치에 표시되는지 고민할 필요 없이 대규모의 계층적 UI를 생성할 수 있습니다. 자식 캔버스도 부모 캔버스와 형제 캔버스 모두로부터 콘텐츠를 분리할 수 있으며, 자체적으로 지오메트리를 유지하고 자체 배칭을 수행합니다.

캔버스를 자식 캔버스로 더 세분화하는 경우, 동적 요소를 정적 요소와 분리하는 등 업데이트 시점에 따라 요소를 그룹화하는 것이 좋습니다. 비디오의 29분 36초 부분에 스마트한 캔버스 세분화의 좋은 예를 설명합니다.

 

문제: 최적의 그래픽 레이캐스터 사용법

그래픽 레이캐스터(Graphic Raycaster)는 입력 사항을 UI 이벤트로 변환하는 컴포넌트로, 화면/터치 입력을 이벤트로 변환한 다음 관련 UI 요소로 전송합니다. 하위 캔버스를 비롯하여 입력이 필요한 모든 캔버스에 그래픽 레이캐스터가 있어야 합니다.

이름과는 달리 그래픽 레이캐스터는 실제로 레이캐스터가 아니며, 기본적으로 UI 그래픽만 테스트합니다. 그래픽 레이캐스터는 특정 캔버스에 입력을 수신하는 UI 요소를 포착하고 교차 지점을 확인합니다. 즉, 그래픽 레이캐스터 캔버스에 포함된 각 UI 요소의 RectTransform에 대해 입력 이벤트가 발생하는 지점이 인터랙티브로 표시되는지 확인합니다.

여기서 일부 UI 요소의 경우 업데이트 수신과 관련이 없다는 점이 문제가 됩니다.

​

솔루션: 정적 요소나 비인터랙티브 요소에 대한 레이캐스트 타겟을 비활성화합니다.

텍스트 또는 버튼이 이러한 요소에 해당합니다. 레이캐스트 타겟을 비활성화하면 그래픽 레이캐스터가 각 프레임에 대해 수행해야 하는 교차 지점 검사 횟수가 즉시 감소합니다.

​

문제: 그래픽 레이캐스터가 어떤 측면에서는 레이캐스터의 역할을 합니다.

캔버스에서 렌더 모드를 월드 공간 카메라나 화면 공간 카메라로 설정하는 경우 차단 마스크를 설정할 수도 있습니다. 차단 마스크는 레이캐스터가 2D 또는 3D 물리를 통해 레이캐스트를 수행할지 결정하여 일부 물리 오브젝트가 사용자와 UI 간의 상호작용을 차단하는지 확인합니다.

​

솔루션: 2D 또는 3D 물리를 통한 레이캐스트는 많은 자원을 소모하므로 최대한 적게 사용합니다.

또한, 인터랙티브 이벤트를 확인할 필요가 없는 비인터랙티브 UI 캔버스에는 그래픽 레이캐스터를 추가하지 않음으로써 그래픽 레이캐스터의 수를 최소화하세요.

 

문제: 상호작용 이벤트를 전송한 카메라 정보가 월드 공간(World Space) 캔버스에 제공되어야 함.

월드 공간 또는 카메라의 스크린 공간에서 렌더링하도록 캔버스를 설정하는 경우, UI의 그래픽 레이캐스터를 위한 상호작용 이벤트를 생성하는 데 사용할 카메라를 지정할 수 있습니다. 이 설정은 “스크린 공간 - 카메라” 캔버스에 필요하며, "렌더 카메라"라고 불립니다.

그러나 “월드 공간” 캔버스의 경우 이 설정은 선택 사항이며, "이벤트 카메라(Event Camera)"라고 불립니다.

월드 공간 캔버스의 이벤트 카메라 필드를 비워 두는 경우에도 캔버스는 게임의 기본 카메라를 사용하여 이벤트를 수신하며, 어느 카메라가 기본 카메라인지 파악하기 위해 카메라 기본 속성에 액세스합니다.

유니티가 사용하는 코드 경로에 따라 캔버스는 프레임당, 그래픽 레이캐스터당, 월드 공간 캔버스당 Camera.main에 7~10회 접속합니다. Camera.main은 액세스될 때마다 Object.FindObjectWithTag를 호출하므로 이로 인해 런타임이 지연될 수 있습니다.

​

솔루션: Camera.main 사용을 지양합니다.

카메라 레퍼런스를 캐싱하고 기본 카메라를 추적하는 시스템을 구축하세요. 월드 공간 캔버스를 사용하는 경우 항상 이벤트 카메라를 할당하세요. 이 설정을 절대 비워두지 마세요. 이벤트 카메라를 변경해야 하는 경우 이벤트 카메라 프로퍼티를 업데이트하는 코드를 작성하세요.

 

문제: GetComponents 호출을 최소 1회 수행하여 레이아웃을 변경하려고 하는 모든 UI 요소

레이아웃 시스템에서 하나 이상의 자식 요소가 변경되면 레이아웃 시스템이 변경된 것으로 인식됩니다. 변경된 자식 요소는 해당 자식 요소를 가지는 레이아웃 시스템을 무효화시킵니다.

레이아웃 시스템 간략 정보 : 레이아웃 시스템은 레이아웃 요소 바로 위에 있는 인접한 레이아웃 그룹입니다. 레이아웃 요소 컴포넌트뿐만 아니라 UI 이미지, 텍스트, 사각 스크롤 영역 역시 레이아웃 요소에 해당됩니다. 또한, 사각 스크롤 영역은 레이아웃 그룹에도 해당됩니다.

문제로 다시 돌아가서, 레이아웃을 변경하려고 하는 각 UI 요소는 최소 1회의 GetComponents 호출을 수행합니다. 이 호출은 레이아웃 요소의 부모 수준에서 유효한 레이아웃 그룹을 찾습니다. 유효한 레이아웃 그룹을 찾으면 더 이상 레이아웃 그룹을 찾을 수 없거나 계층 구조의 루트에 도달할 때까지(어느 쪽이든 먼저 발생할 때까지) 변환 계층 구조 상위로 계속 진행합니다. 따라서 각 레이아웃 그룹은 각 자식 레이아웃 요소의 변경 프로세스에 1회의 GetComponents 호출을 더함으로써 중첩된 레이아웃 그룹의 성능을 극도로 저하시킵니다.

​

솔루션: 가능한 한 레이아웃 그룹을 지양합니다. (layout group)

비례 레이아웃의 경우 앵커를 사용하세요. 요소 개수가 변화하는 핫 UI의 경우 레이아웃을 계산하는 자체 코드를 작성하되 변경 사항이 발생할 때마다 사용하지 말고 필요한 경우에만 사용하도록 하세요.

 

문제: UI 오브젝트를 잘못된 방식으로 풀링합니다.

대부분의 경우 UI 오브젝트의 부모 수준을 변경한 다음 비활성화하여 풀링하지만 이러한 방식은 불필요한 변경을 초래합니다.

​

솔루션: 먼저 오브젝트를 비활성화한 다음, 부모 수준을 풀로 변경합니다.

그러면 기존의 계층 구조를 1회 변경하게 되지만, 부모 수준을 바꿀 때에는 기존 계층 구조를 다시 변경하지 않으며, 새로운 계층 구조는 전혀 변경하지 않게 됩니다. 풀에서 오브젝트를 제거할 때(가져올때)에는 먼저 부모 수준을 바꾼 다음 데이터를 업데이트하고 활성화하세요.

 

문제: 캔버스를 숨기는 방법

일부 UI 요소와 캔버스를 최대한 효율적으로 숨기는 방법은 무엇일까요?

​

솔루션: 캔버스 컴포넌트 자체를 비활성화합니다.

캔버스 컴포넌트를 비활성화하면 캔버스가 더 이상 GPU에 드로우 콜을 발행하지 않으므로 캔버스가 보이지 않게 됩니다. 하지만 캔버스는 버텍스 버퍼를 폐기하지 않으며 모든 메시와 버텍스를 유지하므로, 캔버스를 다시 활성화하면 리빌드를 트리거하지 않고 다시 드로우하게 됩니다.

또한 캔버스 컴포넌트를 비활성화하더라도 캔버스의 계층 구조에서 많은 자원을 소모하는 OnDisable/OnEnable 콜백이 트리거되지 않습니다. 단, 많은 자원을 소모하는 프레임당 코드를 실행하는 하위 컴포넌트를 반드시 비활성화하세요.

 

문제: UI에서 애니메이터 사용

애니메이터는 애니메이션의 값이 변경되지 않더라도 모든 프레임의 요소를 변경하며, 무연산 검사 기능이 없습니다.

​

솔루션: 항상 변화하는 동적 요소에만 애니메이터를 적용하세요.

변화 빈도가 낮거나 이벤트에 대한 반응으로만 단기간 동안 변화하는 요소의 경우 자체 코드를 작성하거나 트위닝 시스템을 구축하거나 사용하세요.

 

참고

docs.unity.cn/kr/2018.4/Manual/class-SpriteAtlas.html

m.blog.naver.com/PostView.nhn?blogId=ateliersera&logNo=221287315106&proxyReferer=https:%2F%2Fwww.google.com%2F