Profiling
프로파일러로 유니티에서 사용할 수 있다.
존재만 있고 막상 못 써요 ㅋㅋㅋ
최적화를 단순히 맹목적으로 하지마세요.
프로파일러로 꼭 측정을 하고 최적화를 진행을 해라.
최적화의 주체적인 역할을 프로그래머에요. 항상 TA에게 맡기는건 정상적은 방법은 아니라고 생각해요.
출시 직전에 프로파일러를 돌리는 경우도 있어요.
물론 프로토타이핑 단계에서는 필요 없지만, 본 개발에 들어가면서 게임을 개발하면서 분기에 한번씩, 한달에 한번씩 주기적으로 해야해요. 프로파일링을.
그리고 타겟 기반에서 돌려야 합니다.
에디터의 측정치는 부정확합니다. 최저 사항 기기에서도 테스트 하고 돌려본다.
IOS에서는 XCode에서 돌려보는 걸 추천드려요.
성능 측정을 할 떄 FPS로만 많이 따진다.
러프하게는 좋은데 디테일한 병목을 따질때는 부족하다. ms 단위로 성능 병목을 체점하는 것이 좋다.
한 프레임을 걸릴 때 몇초가 거리는가 ? ms.
FPS = 1000/ms
ms = 1000/FPS
GPU 바인더런지 CPU 바인더러인지 체크를 하셔야 한다.
PC 같은 경우에는 쿨러로 발열이 없어지는데, 모바일은 그런 처리가 잘 안된다.
회사에서는 따로 스마트폰 쿨러를 배치해 항상 일정한 성능을 유지하게 하기도 한다.
미니먼 타겟 디바이스도 항상 테스트 해봐야한다.
갤럭시 폴드 같은 경우에는 해상도가 1536 x 2152와 같이 굉장히 크다
모바일 기기들 마다 해상도가 다르다. 병목 위치가 달라질 수 있다.
Memory
모바일은 PC에 비해 메모리 부분에 굉장히 취약하다.
PC에서는 Strange(저장장치) 공간을 일부 램 공간 처럼 사용할 수 있기 때문에 Ram을 많이 사용한다고 해도 게임이 느려질언정 뻗지는 않는다.
하지만 폰은 그런거 없다. 그냥 게임이 한계치를 넘으면 OS가 죽여버린다.
모바일에서는 메모리를 굉장히 타이트하게 사용해야 한다.
가비지 컬렉터.
C#은 메니지드 메모리
CPP같은 경우에는 delete로 메모리를 명시적으로 지워줄 수 있다. 프로그래머가 책임지고 이걸 지워줘야 한다.
C#에는 GC가 있다.
메모리 압축. 빈공간을 없앤다.
주기적으로 돌면서 가비지를 날린다.
메모리 할당이 일어날 수 록 가비지 컬렉터의 부담이 많아진다
JSON이나 XML을 동적으로 파싱하게 되면 이것들이 문자열이 되고 다 가비지의 대상이 된다.
그래서 파싱하고 바로 데이터 객체로 할당하지말고, 사전 처리를 거쳐서 scriptable Object 라던가 에셋 데이터로 변경하여 데이터로 사용하면 좋다.
Animatior 에서도 파라미터에 직접 string을 입력하는 것이 아니라 ID를 얻어와서 그 ID를 파라미터로 직접 사용할 수 있다.
어쩌다가 한번 일어나는건 상관없어요. 근데 이 작업이 매 프레임마다 일어나면 무리가 될 수 있겠죠.
Hash 값을 사용할 수 도 있다.
GameObject tag를 직접 string에 비교하지 말고 CompareTag 함수를 사용할 수 있다.
코루틴 같은 경우도 yield ~ new ~ 하면서 또 가비지가 발생한다.
그렇기 때문에 이것도 new 한 오브젝트를 저장해서 그걸 매번 return 시켜주면 가비지가 발생하지 않는다.
Adaptive Performance
명시적으로 핸드폰의 발열 상태, 쓰로틀링 상태 등을 API를 통해 명시적으로 알 수 있다. 온도나 퍼포먼스등을 가변적으로 얻어올 수 있음.
안드로이드에서는 AP를 사용하는게 필수적이다! 할 수 있다.
Programming and code architecture
프로그래밍 코딩할 때 신경써야 하는 부분
Script 실행순서를 알고 있어야 한다.
Start 나 Update 함수가 비어있어도 어느정도 성능을 먹는다. 비어 있을 땐 지워주자.
에디터에만 사용할 때는 define(전처리기)를 통해 처리해주자.
Debug.Log는릴리즈 하여도 호출된다.
public static class Logging()
{
[System.Diagnostics.Conditional("ENABLE_LOG")] // 이런 컨디셔너로 묶어주면은
static public void Log(object message)
{
Debug.Log(message);
}
}
스크립트 컴파일러에서 처리 가능.
Component를 실시간으로 붙였다 땠다 하는게 성능을 생각보다 많이 먹는다.
몬스터 베리언트가 필요하면 베리언트마다 프리팹을 만들어라
게임오브젝트나 컴포넌트를 얻어올 때 변수에 할당해라.
라이더에서는 이런걸 다 제한해줘요. 결론은 라이더 짱 (?) 근데 비쥬얼스튜디오도 제한해주는 걸로 알고 있어요 (← 나중에 따로 찾아보기)
Object Pool 메모리풀.
오브젝트 풀 패턴 사용. 주의할 점은 리페어런팅(ReParenting) 이슈가 있을 수 있습니다.
하이라이키에서 이쁘게 보이기 위해서 활성화, 비활성화 오브젝트들의 하위 객체로 왔다갔다 옮겨둘 수 도 있다. 하이라이키에서는 이쁘게 보일 수 있다. 그때 여기서 SetParent 함수를 사용하게 된다. 이것을 리페어런팅이라고 한다. 부모를 바꾸는. 근데 이것이 비용을 먹는다. 버전마다 조금씩 성능 영향이 다르긴 하지만. 이런 리페어린팅은 안하는게 좋다. 그냥 마음을 비우세요. 이쁘다 이쁘다 하면서.
Scriptable Object
HP등의 공통되는 속성을 상속을 사용하면 구조적으로 이쁘긴 하지만, 성능적으로 안 좋을 수 도 있다.
원래 직렬화가 되어 있어서 성능적으로 좋다.
Project configuration
player 칸에 굉장히 뭐가 많은데 Reduce or disable. 끄거나 줄여라. 이것만 기억하세요.
우리 프로젝트에 안 쓰는거 같아 이러면 바로 그냥 끄세요
내 게임 중력센서나 그런거 안 쓰는 게임이다. 하면 그냥 가속계 같은거 바로 끄세요.
플레이어 퀄리티도 여러개 필요없다. 다 끄세요.
Auto Graphics API 같은 것도 필요한 것만 넣으세요. 필요없는거 뺴세요.
물리쪽에서도, Auto Simulation 이나 Auto SyncTransforms 등 필요 없는거 다 빼세요. 아래의 연동하는 작업을 해주는 처리를 자동으로 할 것인지에 대한 내용이다
unity 공간과 Physics (물리) 공간을 동기화 시켜주는 작업은 보통 Fixed Update에서 일어난다.
다음 FrameRate
연산을 하면 할 수 록 폰이 뜨거워진다.
발열이 심해져도 발적화가 있다.
액션 게임이면 프레임이 잘 나와야 한다. 40. 퍼즐은 잘 안나와도 돼 30. 이런식으로.
Frame Rate란, 앞서 말했던 게임의 60프레임이 나올 수 있어도 최소 프레임으로 강제로 고정해놓고 프로세스 CPU등에 쉬는시간을 주는거다.
Large hierarchies
A라는 오브젝트가 움직이면 그 하위 객체들도 Transform 재 연산이 필요. 하이라이키는 복잡할 수 록 성능에 악영향을 끼친다.
오브젝트가 서로 종속적으로 되어 있지 않는다면 멀티 스테드를 활용해서 따로따로 처리를 할 수 도 있다.
Transform은 한 프레임에 한번씩만 좋다.
이렇게 따로따로 있는데. 이 코드가 매번 transform을 건드리면 궁극적으로 캐릭터는 하나인데 transform 연산은 매번 일어나고 있는 것이다.
transform과 rotation을 따로따로 하면 또 따로 연산이 계산된다.
Instantiate(prefab,parent,postion,rotatin); // 이렇게 한번에 처리해주는 것이 좋다.
Transform.SetPostionAndRotation(); // 과 같은 함수도 있다. Vsync 가 항상 Enable 되어 있다고 생각해라 모바일 같은 경우에서는 하드웨어에서 강제로 키게 한다.
