군대 훈련을 훈련을 끝마치고나서 모바일 게임을 한번 제작을 해보고 싶어서 이렇게 이론적으로나마 모바일 최적화에 대해서 공부를 하고 있다.
https://youtu.be/1mJtoceqvro
해당 동영상으로 공부를 진행했다.
Profiling
Profiling은 최적화의 기본 중에 기본이다!
Unity에서는 기본 Profiler가 존재한다. Development Build를 할 때 Autoconnect to Profiler를 활성화하면 디바이스에 게임을 띄우고 해당 게임을 프로파일링 할 수 있다. 또는 editor에서 profiling을 할 수도 있다. 이러한 profiling기능의 존재는 알고 있지만 저를 포함해 많이 사용하지 않는다.
최적화하기 전에 반드시 Profiling해야한다. 최적화를 Profiling하지 않고 맹목적으로 하면 안된다. (Don’t optimize bindly) 예시로 프로그래머가 게임이 느려서 원인을 파악하지 않고 아티스트에게 가서 게임이 느려서 Texture를 줄여달라는 요구를 하는 것과 같다. 이때 아티스트는 프로그래머에게 사이즈를 줄여서 제공해도 결과적으로 눈에 띄는 변화가 없을 수 있다.
이러한 상황을 방지하기 위해 Profiler로 측정을 하고 병목현상을 찾아낸 다음 어떤 부분이 최적화가 필요한지 찾아내고 최적화를 진행해야한다. 그렇기 때문에 최적화를 하기 전에 Profiling은 필수적이다.
Profiling을 할 때 가끔 Profiler를 누가 해야하는지에 대한 문제가 제시된다. 요즘 QA, TA 등 직군에서 Profiling하는 경우가 있고 물론 할줄 알아야한다. 하지만
Profiling의 주 책임자는 프로그래머다.
그 이유는 성능이 항상 그래픽에서만 일어나는것이 아니라 Logic, 물리작업 등의 부분에서 성능을 많이 잡아먹기 때문이다. 그렇기 때문에 프로그래머가 프로젝트를 전반적으로 볼 수 있는 시야를 가지고 있기 때문에 프로그래머가 먼저 Profiling을 진행하고 그래픽이 문제라면 TA랑 함께 협업해서 고쳐야한다. 처음부터 QA, TA에게 Profiling을 맡기는 것을 정상적인 방법이 아니다. 사람마다 여기에 대한 의견은 다를 수 있지만 저는 Profiling은 프로그래머가 시작해야한다고 생각합니다.
Profiling시 자주 일어나는 일이 출시 직전에 최적화를 위해 Profiling하는 것이다. 그렇다면 예시로 개발기간이 2년이었다면 문제가 되는 사항을 발견했을때 그 2년동안 진행했던 것들을 바꿔야한다. 그러므로 최적화는 수시로 해야한다. Profiling도 마찬가지이다.
Target Device에서 Profiling
Profiling할 때 Target device에서 돌리는 것이 좋다. 앞에서 editor에서 Profiling을 할 수 있다고 했는데 아무 의미 없는것은 아니지만 Target device에서 돌리는 것이 더 효과적이다. Editor의 측정치는 Target device가 모바일이라고 가정했을 때 모바일의 병목과 성능 그리고 editor를 돌리는 PC의 성능이 다르기 때문에 병목 지점이 다르다. Editor같은 경우는 editor처리를 하기 위한 overhead가 나타나기 때문에 대략적으로는 볼 수 있지만 정확하게 보기 위해서는 Target device에서 Profile을 해야한다. 모바일이 Target device일 경우 최저사양 기기를 구해서 최저사양에서도 돌아가는지 확인을 해보고 주로 타겟팅하는 device에서도 확인 해봐야한다.
ios에서 Profiling할때 Mac이 있다면 꼭 Xcode로한번 해보는 것을 추천한다. 그 이유가 Unity내부 Profiler는 깊이의 한계가 존재하는데 Xcode는 더 깊은 단계까지가서 볼 수 있기 때문이다. Android 경우에도 Snapdragon Profiler또는 Android Studio등을 활용해 자세히 측정이 가능하다.
Profile Analyer
Profile Analyer라는 것이 있는데 이것은 Unity의 기본 Profiler외에 확장툴을 제공한다고 보면 된다. Profiling하고 수정 후 다시 Profiling하는 과정을 반복을 하는데 이때 Profiling의 결과물의 snapshot을찍을 수 있다. 그래서 수정전 수정후 또는 1번 Scene, 2번 Scene으로 상황에 따라 비교가 가능하다. 이것도 필요시 활용하면 유용하다.
FPS / MS
많은 분들이 간과하는 것 중 하나가 성능 측정시 FPS로만 따지는 것이다. 이 FPS라는 측정치는 대략적인 수치를 볼 수 있지만 디테일하게 병목을 탐지하고 병목을 수정하고 병목에 대한 대안을 세우기에 좋은 측정치는 아니다. 측정을 할 때 ms(1/1000초)라는 단위로 표시가 되는데 이 표시로 성능 병목을 측정하는 것이 좋다. 여기서 측정되는 ms는 한 프레임을 그리는데 몇초가 걸리는지 표시한 것이다. FPS = 1000/ms이고 ms = 1000/FPS인것이다. 서로 역의 상관관계이다. FPS는 1초에 몇 프레임을 그리냐의 수치이다.
그럼 왜 ms로 봐야하냐면 한 프레임을 그릴 때 30ms가 걸렸다고 가정하자. 이때 자세하게 살펴보니 Rendering에 5ms, Update 5ms, Phygics에 20ms가 걸렸다. 그러면 딱 봤을 때 우리가 최적화를 해야하는 부분은 Phygics이다. 다른 2개를 최적화해도 Phygics를 최적화하는 것이 더 효율이 좋을 것이기 때문이다. 이처럼 ms로 측정을 해야 어떤 부분이 우선시되고 어떤 부분이 수정이 필요한지를 명시적으로 알 수 있다. 그렇기에 Profiler에서 측정되는 단위가 ms이다. 계속 반복하지만 Profiler는 항상 돌려봐야하고 계속 이 글에서 강조하지만 Profiling한 후 원인을 찾고 최적화 작업을 해야한다.
CPU-boundary, GPU-boundary Check
측정을 할 때 CPU-boundary인지 GPU-boundary인지 체크를 해야한다. 아까도 설명했지만 게임이 느려서 Texture size를 줄였음에도 변화가 없어서 다시 찾아보니 물리현상이 문제인것을 찾아냈다고 하자. 이때 GPU쪽이 병목이라면 CPU쪽을 줄여도 크게 변화가 없고 반대로 CPU쪽이 병목이라면 GPU쪽을 건들여도 큰 변화가 없다.
CPU와 GPU는 서로 병렬적이다. Timeline상으로 보면 서로 병렬적으로 돌아가는 것을 확인할 수 있다. 그렇기 때문에 CPU가 널널한데 CPU쪽을 최적화하고 GPU는 여전히 빽빽하다면 최종성능에는 큰 변화가 없다. 따라서 최적화의 효율을 위해 CPU-boundary인지 GPU-boundary인지 항상 따져봐야한다.
Device temperature (디바이스 온도)
PC같은 경우는 큰 쿨러가 돌아가면서 발열을 없애주는 역할을 해준다. 근데 모바일의 경우 작은 디바이스에 큰 쿨러가 존재하지 않는다. 대신 냉각판 정도가 들어가있다. PC와 비교했을 때 매우 작은 쿨링 시스템이 들어가있기 때문에 발열에 취약하다. 그렇기 때문에 모바일은 조금만 게임을 해도 뜨거워진다.
모바일이 뜨거워지면 프로세서는 기기를 보호하기 위해서 성능을 낮춰버린다. 왜냐면 연산을 하면 할수록 열이 나오기 때문이다. 성능을 낮춰서 열이 덜 발생하게 한다는 의미이다. 이런 상태가 되는 것을 서멀 스로틀링(Thermal Throttling)이라 한다.
모바일에서 스로틀링 상태에 빠지는것이 비일비재하기 때문에 지금 내가 측정을 하고 있는 상황이 스로틀링에 빠진 상황인지 아닌지 확인을 하면서 성능을 측정해야한다. 왜냐면 스로틀링에 빠졌을 때 측정을 하는 것과 스로틀링에 빠지지 않았을 때 측정을 하는거랑 결과물이 완전 달라지기 때문이다. 프로그래머 입장에서 이를 고려하지 않는다면 아무것도 수정하지 않았는데 어쩔때는 성능이 잘나오고 어쩔때는 성능이 잘 안나오는 상황이 생긴다. 이러면 전혀 측정을 할 수가 없다. 보통 게임개발사에서는 스마트폰 쿨러를 많이 비치를 한다. 그래서 항상 외부 쿨러를 돌려서 일정한 온도를 유지시켜주는 환경을 마련하기도 한다.
해상도에 따른 병목
요즘 모바일의 해상도는 너무나도 다양한데 모바일과 테블릿 해상도에 따라 병목이 일어나는 위치도 달라질 수 있다. 작은 모바일에서는 GPU에서 병목현상이 일어나지 않았는데 테블릿으로 돌려보니 GPU쪽에서 병목이 발생할 수 있다. 이러한 이유는 방금 나왔던 해상도 때문이다. 테블릿이 해상도가 더 높고 그만큼 처리해야할 픽셀 수가 늘어나기 때문이다. 그렇기 때문에 주로 Target으로 생각하는 Target device와 최저사양을 모두 측정해보아야한다.