#50 최적화
게임의 최적화에 대한 부분을 작성해보았다
game창에서 우측상단 stats를 클릭하면 진행 중 정보를 볼 수 있다.
하지만 완벽히 믿을수는 없다. 왜냐하면 에디터에서 돌아가기 때문에 Scene에서 렌더링되는 모습도 성능에 영향을 미치고 있기 때문이다.
따라서 정확하게 확인하기 위해서는 우측상단 fps표시를 해주는 코드를 만들고, 빌드를 한 뒤에 확인해 보는것이 좋다.
현재 200~300프레임이 나오고 있는데, 실제로 이정도의 fps는 필요가 없다. 모바일게임이 주 타겟이라면 fps제한은 필요하다
위 코드를 추가하는 것으로 fps제한을 걸어줄 수 있다. 에디터상에서는 60~70을 오가지만, 빌드를 하면 60근처에 존재한다.
이런 제한이 존재하지 않으면 기기에서 낼수있는 최고의 성능으로 연산이 들어가 부하가 걸릴 수 있다.
메모리 관리또한 최적화에 중요하다.
텍스처의 이미지 사이즈를 변경하면 메모리 용량을 매우크게 줄여줄 수 있다.
가로/세로 배수가 4의 배수여야 압축이 가능하다고 작성되어 있다. 압축이 되는것과 안되는 것의 차이는 매우 극적이기 때문에 맞춰주는 것이좋다. (약 0.9mb-> 256kb수준)
스테이터스에서 Batches와 setpass calls가 존재한다.
batches는 DrawCall + 렌더 상태 변화들을 더한 것을 의미한다. 정확히는 Command Buffer내부에 존재하는 DrawCall과 SetPassCall(셰이더 등등)이다.
이런 부분은 머테리얼과 관련이 있다.
batches를 낮추기 위해서는 우선 FrameDebugger를 통해서 확인해봐야 한다. 변화하는 과정을 단계로 확인할 수 있다. 이 단계들이 각각 DrawCall이다.
스프라이트들을 하나의 이미지로 만들어둔 경우, 해당 이미지들은 한번에 로딩된다. 이미지를 합칠땐 SpriteAtlas를 이용할 수 있다.
해당 기능을 통해 각종 UI요소들을 하나의 이미지로 합쳐주면 Batches를 줄여 로딩양을 극적으로 줄일 수 있다.
동일 Atlas에 들어가 있더라도 다른 배치에 그려지는 경우가 있다. 이런 부분은 계층구조때문에 그렇다. 다른 계층에 존재하는 경우에 batch가 달라진다...
sprite들을 atlas로 묶어두었을때, 해당 atlas내부의 모든 sprite들이 사용되지는 않는다. 특히, atlas내부에 하나의 스프라이트만 사용하는경우, 전체의 atlas를 불러와야하다보니 배보다 배꼽이 큰 상황이 나타날 수도 있다...
따라서 atlas는 적절한, 필요한 상황인 애들끼리만 정리해두는 것이 좋다.
버튼같은경우, 개별로도 쓸수있기때문에 버튼의 사이즈를 4의 배수로 만들어 두는것이 좋다.
스크립트 최적화
이전에 작성했듯이 Profiler를 통해 성능을 확인해 볼수있다.
사용량이 올라는 부분에서 어떤 스크립트로 인해 올라가는지 확인할 수 있다.
yield return의 경우 garbage를 생성한다
new Wait for seconds이기 때문에 객체가 계속하여 생성된다.
따라서 미리 객체를 생성하고, new가 아닌 생성된 객체로 yield return wait;의 형태로 만들어주는것이 좋다.
StartCoroutine또한 garbage를 생성해버린다고 한다. unitask나 unirx와 같은 패키지로 가비지가 생성되지 않는 코루틴 사용이 가능하다고 한다.
build버전에서는 Debug.log를 지워줘야한다고 한다. 빌드버전에서도 실행되기도 하고, 성능을 꽤많이 잡아먹기 때문에 지워주는것이 좋다.
대체 방안으로 Debug.Assert가 있다. bool값과 string값이 들어가는 함수인데, 조건을 충족해야야만 실행되고, build버전에서는 알아서 사라지기 때문이다.
Debug.logAssertion("string")을 통해 Debug.log처럼 사용할 수도 있다.
(번외)
Camera.main도 자주 사용하지 않는것이 좋다. Find()를 사용하기 때문인데.. 캐싱을 한 뒤에 사용해야한다..
vector3 speed time.deltatime도 잘못된 스크립트 예시이다. vector3를 계산할때 (x,y,z)각각 연산이 이루어지기 때문에 vector3에 대한 계산은 뒤쪽에 작성되는 것이 좋다.
LINQ는 쓰지 않는것이 추천된다. for문에 비해 연산이 느려지고 이건 전체적인 속도 저하를 일으킬 수도 있다..특히 Unity에서 두드러진다.
문자열에 대한 합은 Stringbuilder를 사용하자
