[📚정보] 최적화 노하우 공유

[익명(175.197)]

개인적으로 개발관련해서 메모용으로 사용하는 티스토리 블로그에 작성했다가,

꽤 많은 분들에게 도움이 될 것 같아 내용만 똑같이 복붙하여 왔습니다.

다들 고생하세요.

-----

게임 출시를 앞두고, Android플랫폼의 심각한 발열과 낮은 프레임에 대한 최적화를 수행했다.

여러개의 프로젝트를 런칭하면서 쌓인 노하우 및 새로 공부한 지식으로 유의미한 최적화 성과를 거두었기에 최적화 방법을 공유한다.

먼저, 최적화 방법 공유에 앞서 최적화 대상 프로젝트의 스펙은 다음과 같다

-Unity 2021.3.8f로 개발

-URP 프로젝트

-NGUI사용

최적화 성과 (갤럭시 s8기준)

FPS :  20~30 -> 50~60

용량 : 400mb -> 300mb

발열 : S22에서 심각한 발열로 인해 30~40fps가 나옴 -> S22와 같은 심각한 발열 기기에서 거의 발열 없이 수십분 이상 구동 가능. 안정적인 60fps유지.

이와같은 성능을 유지하기 위해선 여러가지 복합적인 이유들이 있겠지만,

untiy editor의 stats기준으로 batch는 많아도 100~200수준을 잡아주는 것이 좋다

(스크립트 병목과 높은 vertex로 인한 성능 하락은 고려하지 않는다)

먼저 최적화에 앞서 본인 프로젝트에 대한 프로파일링을 우선 진행하길 바란다.

필자는 최적화에 Unity Profiler와 Memory Profiler(실험적) 을 사용했다

profiler를 통해 스크립트 병목의 원인을 추적하고, 메모리 스냅샷을 사용해 메모리 사용량을 최적화하라

그리고 최적화의 대상이 CPU처리인지 GPU처리인지도 파악해야 한다.

NGUI관련 최적화

1. UI Atlas의 depth최적화, panel을 최적화한다. 

ngui에서 가장 기본적인 것으로 동일한 panel을 사용하는 widget들의 depth를 정리하여 최적화 해주어야 한다.

무분별한 panel의 사용으로 동일한 atlas를 사용하는 widget이 쪼개져 중복적인 draw call을 야기하지 않도록 해야한다.

ngui에서 A와 B아틀라스 2개를 통해 UI를 구성한다면 흔이 2의 draw call을 예상할 것 이다.

하지만 만약 depth가 A A B A BB이런 식으로 ui를 배치한다면 draw call은 4가 된다

2의 draw call을 얻기 위해선 A A A B B B B와 같이 atlas에 따른 ui depth를 정리해주어야 한다.

하나의 atlas로 draw되다가 다른 atals를 만나면 중간에 batching이 끊기게 된다.

2. 동일한 atlas를 사용하는 widget은 단일 panel에서 최대한 순서를 정렬하여 처리해준다.

필자의 경우 ui atlas를 back / icon / overay / font 이렇게 4가지로 나누어, 정리했으며 

ui가 아무리 많아도 batch는 최대 4만 유지하도록 해주었다.

draw call의 병합 규칙은 두가지가 있는데, 하나는 material, texture, shader가 모두 같다는 것이고 다른 하나는 widget의 레이어가 같거나 인접해야 한다는 것이다.

3. NGUI에서 Transform의 변화, 생성, 삭제가 일어나는 객체를 조심해라

NGUI에서는 Panel에 속한 widget의 Transform이 변화(생성/삭제 포함) 하면 해당 panel에 있는 모든 widget을 다시 rendering한다. 

즉, Panel에 연출을 위한 widget이 tween position, scale등을 한다면 매 lateUpdate에 Panel은 drawcallfill을 다시 호출하는 것이다.

NGUI Widget의 Transform이 정적이지 않거나, 생성/삭제가 자주 일어나는 객체라면 완전히 다른 panel의 하위 객체로 두어 격리해두어야 한다.

즉, NGUI에서는 한 panel에 속한 widget의 상태에 변화가 생기면 해당 panel의 모든 atlas를 다시 렌더링해주게끔 되어있다.

3-1. 특히 NGUI의 UI Label을 조심해라

UI Label로 데미지 등을 처리할 경우 데미지 연출을 위해 UI Label이 매프레임 tweening하거나 animation을 재생할 수 있다. 이 경우 UI Label은 엄청난 성능 병목을 일으킨다.

매 프레임 움직이는 UILabel이 속한 panel의 draw fill/fill shadow/draw call fill을 야기시킨다.

특히 UI Label에 쉐도우나, 아웃라인 등이 들어가있다면 매프레임 Transform의 변화에 따라 Label을 다시 렌더링 해주게 된다.

이를 방지하기 위해 데미지 폰트 등은 이미지 폰트를 사용하는 것을 추천한다.

4. panel의 static상태 활성화

panel로 구성한 ui에 있는 모든 객체가 정적인 것이 보장된다면, panel의 static옵션을 활성화해주면 좋다.

ngui객체도 기본적으로 mono객체이며, static객체가 아니면 모든 ui객체에서 update/lateUpdate가 호출되기에 성능 병목이 발생한다.

정적인 객체의 경우 3번 방법을 참고하여 동적인 객체만 관리하는 panel등으로 격리해주자

그 외 Unity공통 최적화

1. GC를 줄이자

BinaryFormatter의 Serialize는 엄청난 양의 GC를 야기하며, 디바이스를 freeze시킨다. 이러한 동작은 매프레임 해주지 말고, 스케쥴러를 만들어 처리해주자

BigInteger.Parse(string)과 같은 value copy를 야기하는 처리를 피해주자

특정 타이밍에 GC.Collect를 수동으로 호출해주자

2. URP Setting의 Post Processing의 fast sRGB/Linear Conversions로 gamma공간을 사용하고 있다면 gpu의 부담을 덜어주자

3.  SustainedPerformanceMode를 활성화해 지속가능한 성능 옵션을 켜주어, 발열을 방지하자 (이로 인해 기본적인 fps의 하락이 있을 수 있음)

4. GPU의 병목/부하가 생기는 Project Setting의 옵션은 비활성화 하자 (Compute Skinning, Graphics Jobs...등)

5. Static Batching과 Dynamic batcing을 적극 활용하자

6. Texture compression format : ASTC, normal map encoding : DXT5nm-style

7. Screen.SetResoultion을 통해 화면 해상도를 지정해주자 (HD~FHD). 이를 해주지 않을 경우 기기의 해상도에 따라 렌더링되기 때문에 발열과 배터리소모의 원인이된다.

8. Target Framerate를 설정해주자 (60fps). 만약 프레임상한이 없다면 상위 기기에선 비정상적으로 높은 fps가 발생할 수 있으며 이는 발열/배터리소모의 원인이 될 수 있다.

9. realtime shadow는 최대한 피하고, 눈속임을 통해 그림자를 표시할 수 있는 방법을 찾자

quad를 통해 그림자를 표현하고, 이 quad를 dynamic batcing하는 등이 방법이다.

10. 가능한 많은 object pooling을 해주자. 

또한 NGUI객체의 경우 객체를 pool에서 회수/반환할 때 gameObject.SetActive보단 화면에 rendering되지 않는 먼 영역으로 좌표를 이동시켜 주는것이 좋은 선택지일 수 있다.

NGUI객체는 오브젝트가 enable/disable될 때 많은 병목을 일으키는 처리를 수행한다

11. 거리에 따른 최적화 방법을 숙지하라

Generate mipmap은 기본적을 texture의 용량을 1.3배 정도 부풀린다.

단 한 화면에 render되는 객체가 많을 경우 이는 한 화면의 메모리 부하를 줄여주므로 적극 활용해야한다.

또한 오브젝트에 LOD level을 세팅하면 거리에 따라 3D오브젝트의 렌더링 부하를 줄일 수 있지만 용량이 추가적으로 들어가는 것을 유의해야 한다.

Aniso Level을 주의해라. Aniso Level은 오브젝트를 그릴 때 단일 텍스쳐라도 멀어지면 흐리게 해주는 효과이다.

Aniso Level이 높을수록 선명해지겠지만 ,처리비용이 많이 든다.

프로젝트 세팅에서 확인하라 (기본값은 Forced On이다)

12. Asset의 Read/Write옵션을 주의하라

이 옵션은 기본적으로 비활성화지만 활성화 시 GPU메모리 뿐만 아니라 메인 메모리에도 복사되므로 소비량이 2배로 증가한다.

꼭 필요한 오브젝트의 경우만 식별하여 사용할 것

13. 파티클의 shader/material에 따라 render order를 조정해주어라.

NGUI와 같은 개념으로, 파티클에서 사용되는 shader/material도 render order를 조정해주어 batching되도록 해주자

14. Resources.Load를 매니징하자

디바이스로 부터 불러온 자원의 경우 사용 빈도에 따라 GC가 발생하지 않도록 상시 메모리에서 들고있는 등의 방법으로 최적화 해줄 수 있다.

15. Debug.Log를 주의해라

런타임 빌드 시 프로젝트 세팅에서 로깅 옵션을 완전히 비활성화 하거나, 스크립트에서 define으로 처리를 격리해주어라.

Unity Crash관련 팁

이 항목은 필자가 서비스중인 게임의 크래시 문제를 해결한 경험으로 작성되었기에, 지극히 주관적입니다.

1. Android환경에서 Vulkan API는 아직 불안정하다. Vulkan내부에서 native crash를 야기할 수 있다. (필자는 opengles 3을 권장)

2. Multithread rendering과 compute skinning도 native crash를 야기할 수 있다. 

3. 빈번한 Scene Load는 잦은 크래시를 야기할 수 있다.

맵의 전환 등으로 Scene이 load될 때 전 scene의 unload와 새로운 scene의 load중 스크립트가 unload된 scene의 객체 혹은 아직 preload상태의 scene에 접근할 경우 크래시가 발생한다.

추가적으로, unity의 scene 로드 구조는 순간적으로 폭발적인 메모리 사용량을 불러올 수 있다.

A장면에서 B장면으로 넘어갈 때 A장면과 B장면이 동시에 메모리에 올라가있는 순간이 존재하며 이 때 메모리 부족으로 크래시가 발생할 수 있다.

A장면에서 B장면으로 넘길 때 빈 장면(C)을 넣어 A장면의 메모리가 모두 해제되고, GC가 Collect되게 한 후 B장면을 로드해주는 방식은 아주 유용하다

4. Strip Engine Code옵션은 무조건 끄자

압축된 스크립트 dll을 참조하는 순간 native crash가 발생한다

[o o(210.104)]

굿.

[호시타(posita)]

크래시 관련 팁에서 3번을 위해 tempscene에서 시간을 주고 gc collect 수동으로 불러내는 거 좋네요! 바로 써봐야겠네요 안 써도 되는 플젝이지만

[익명(175.197)]

도움이 되었다니 다행입니다~

[익명(39.124)]

지식글 개추

[익명(14.42)]

UGUI가아니라 NGUI를??

[익명(175.197)]

UGUI의 고질적인 크래시, 병목문제들과 손에 너무 익숙한 NGUI때문에 아직까지 ngui를 애용하네요..ㅎㅎ

[익명(14.32)]

뭔지모르겠지만 추

[ㅐㅐㅋㄷ(ooze86)]

논문추

[꿀복한행벌(shlifedev)]

경험글 메모

[개발하고있습니다(wngjdl1212)]

유니티가 gc 세대구분이 없는걸로 알아서 상관 없을수도 있지만 .net플랫폼으로 개발시 Gc호출하는건 지금 가비지 세대를 승격하면서 가까운 시일에 쓰지 않을 가비지가 오래 남게 될수있습니다 gc는 clr이 관리하도록 하는게 좋습니다 그리고 호출될때 gc트리를 추적해야되기에 모든 (소프트웨어적인)스레드가 멈추게 됩니다(이건 유니티 모노도 포함됩니다) 그리고 오히려 감마로 쓰는게 큰차이는 없지만 성능에 더 좋습니다 큰 차이는 색감입니다 - dc App

[개발하고있습니다(wngjdl1212)]

그리고 추가적으로 달자면 ugui 캔버스는 부모가 바뀌면 자식을 새로 그리기때문에 나누는게 좋습니다 - dc App