유니티 6 빌드 테스트 해보다가 느낀점

나는 애플리케이션 개발하는 도중에 중간중간 실제 빌드로 출력해서 앱을 패키징해서 테스트해보곤한다.

React Native를 개발할 때는 기본이 안드로이드나 웹 앱이 베이스였기 때문에,

뭐 하나 수정하면 자동으로 적용되는 핫 리로드가 상당히 익숙한 상태엿고, 졸작 발표 하기 직전에 빌드 테스트해본다고 5일 내내 라이브러리 호환 안되서 버전 맞추고 뭐한다고 다 뜯어고쳣었다.

그때 당시 최종 빌드로 처음 테스트를 시작하면, 종속성 버그 하나 수정하면 새로운 종속성 버그가 생길 수도, 안 생길 수도 있는 기적의 운빨에 맡겨야 했다는 걸 상기해보면, 중간중간 앱을 패키징해서 테스트해보는 것도 괜찮은 방법인 것 같다.

이렇게 테스트 하면 적어도 이전 버전까지는 호환성이 모두 보증되니까 추가로 확장된 기능에 대해서만 호환성을 맞춰주면 되서 수정 규모가 줄어드니까 내 생각에는 꽤 괜찮은 방법인것 같다.

잡설은 각설하고 어제의 앱 빌드 테스트를 진행했을 때 당시에 알아낸 것을 적어보고자한다.

1. 유니티 에디터에서 프로파일링 하지 않기

→ 반드시 빌드된 실행 파일로 프로파일링하자.

이유는 배틀로얄짬뽕 개발할 때도 느꼇던거지만 유니티 에디터가 낑기고 멀티플레이어 테스트가 생기면 단일 앱에 대한 테스트가 아니라 전체 개발 환경에 대한 테스트 종속이 생기기 때문에 실제 패키징된 애플리케이션의 성능보다 절반 이상 하락한 성능이 나오는 것 같다. 

대표적으로 프레임 레이트인데,

에디터상에서 프레임이 20까지 떨어지길래 프로파일러 키고 테스트 하다가 그걸 본 선생님의 조언

“에디터상에서 프로파일링하면 어떻게 하니... 빌드해서 테스트해봐.”라고 조언해주셨고, 바로 적용해보니 프레임 레이트가 140까지 올라가더라....← 지금도 에디터상에서는 60~90프레임대 밖에안나옴
뭐 극단적인 예이긴 한데 그만큼 에디터가 성능을 많이 잡아먹는다고 보면 된다.

2. 디버그 로그는 꼭 필요한 곳에만 남기자

맨 앞에 잡소리에서 내가 RN환경과 핫리로드에 익숙하다고 했었다.

RN 개발에서는 비주얼 코드로 개발을 진행했기 때문에 디버깅 툴에 익숙하지 않았다.

대신 Hremes 엔진이 자동으로 디버그 콘솔 창을 출력하여 그곳에서 실제 애플리케이션의 디버그 로그를 출력하여 디버깅을 진행할 수 있었다. 이 때의 습관이 현재까지 남아 간간히 디버그로 출력해서 확인하는 경우가 종종 있다. 

이건 이번에 테스트하면서 이상하게 빌드 테스트했을 때 프레임 레이트가 250에서 놀다가 50으로 훅떨어지는 지점이 있어서 프로파일러로 확인을 진행해 보았다.

평균치에 대한 지피티 분석돌리기

좋아, 이미지 기준으로 보면 —

• 상단의 Profiler Highlights → Target Frame Rate: 120 FPS
• 실제 Frame Time Median = 3.809 ms

이 두 값을 조합하면 평균 프레임레이트는 대략 이렇게 계산돼 👇

FPS = 1000 ÷ FrameTime(ms)
FPS ≈ 1000 ÷ 3.809 ≈ 262.4 FPS

즉, 평균 약 260 FPS 정도 나오는 상황이야.

평소에는 스크립트 실행 타임레이트가 2~4ms인데 갑자기 50ms로 훅 튀는곳이 있다.

게임오브젝트의 경우 SetActive/Deactive를 통해 On/Off하고 있기 때문에 초기 생성지점이 아니라면 부담이 갈 수가 없다.

그래서 리소스 로드 코드인가 싶어서 확인해봤더니 그것도 아니더라. 

원인은 디버그용 로그 출력이었다.

여기서 왜 Pope Kim이 assert를 적극 권장하시는지 알 것 같았다.

3. 입출력은 항상 느리다.

이건 유니티 이벤트 시스템에 종속된거기 때문에 내가 뭐 어떻게 할 수가 없는 부분이다.

보면 평균적으로 유니티의 인풋 시스템과 이벤트 시스템에 의해 실행되는 타이밍에는 코드 실행이 550ms으로 확 튀는걸 볼 수 있다.

다행인건 이벤트 큐가 유니티 자체적으로 따로 제공되기 때문에 동프레임에 작용하는게 아니라면 성능에는 영향이 미미할 것이라는 점? 정도가 될 것 같다. 

4. Others 항목은 대부분 Profiler에게 데이터를 전달하는 비용이다.

CPU Usage중에 간혹 훅 튀는 부분이 또 있는데 바로 메인스레드가 아닌 JobSystem에서 발생하는 Idle상태에서의 프로파일러에게의 데이터 전송이다.

실제 앱 성능에는 영향을 미치지 않을것 같으니 이 항목은 그냥 그렇구나 하되 간혹 들어오는 외부 요인이 있으니 확인정도는 해보자.

5. 메모리 항목 확인하기

나는 현재 어드레서블과 Resources 시스템을 병행해서 사용하고 있다.

지금은 어드레서블 데이터가 거의 없긴 한데 이번에 완성되는 InputManager 관련한 리소스들이 전부 동적 할당으로 로드되고 있기 때문에 애플리케이션 기본 패키징에서 빼도 될 것 같다는 느낌이 든다. 

뭐 그래봣자 1.2mb밖에 안되서 기본으로 넣어줘도 될거 같긴 한데 배틀로얄 짬뽕이 앱 시동시 사용 메모리가 400에서 시작해서 700mb까지 올라갓던걸 생각하면 현재의 고정 800Mb는 좀 많다고 느껴진다. 나중에 어드레서블 리소스 추가되면 여기서 더 커질텐데 1.2Gb 이하로 유지하는걸 목표로 해보기로 하자

※ 여담

처음에 모노 빌드로 테스트를 진행했다가 평균 프레임이 60에서 놀더라...

아마 고정 프레임레이트로 앱을 빌드했던거 같은데....

어지간하면 IL2CPP로, 목표 프레임 고정 없이 빌드하도록 하자