유니티 최적화

코드로직 최적화 -> 오브젝트 풀(리소스 최적화) -> Draw call -> 폰트 -> UI -> 사운드

FindObject 계열 함수들은 매우느리다

유니티 객체들은 변수에 저장해서, 캐싱해서 사용하는것이 좋다.

Instantiate와 Destroy함수를 이용한 프리팬의 생성/해제는 비용이 매우크다(활성화/ 비활성화 활용 -> 오브젝트 풀링)

Update 함수 보다는 Coroutine 활용

문자열은 readonly 혹은 const 키워드를 사용하여, 가비지 컬렉션으로부터 벗어나도록 한다

ResourceLoadAsync() 함수는 엄청느림

Draw call: 오브젝트에 설정된 재질의 셰이더 패스당 하나씩 일어난다. 렌더러에 사용된 재질의 수만큼 드로우 콜이 발생

static batch : 움직이지 않는 오브젝트들은 static으로 설정해서 배칭이 되게한다, 동일한 재질을 사용 할 경우, 자동으로 통합

dynamic batch : 움직이는 물제를 대상으로 동일한 재질을 사용하는 경우, 자동으로 통합

GC

GC는 언제 인어날지 모르며 일어나면 사용자 이용에 불편이 발생 GC 관리가 필요

빈 콜백함수는 제거

오브젝트 풀링

오브젝트(or 프리팹)의 동적 생성과 해제는 부하가 크다.

오브젝트가 해제되면 언젠가는 GC가 동작

오브젝트를 풀을 만들어 미리 많이 만들어 두고, 활성화/비활성화로 사용

풀에서 가져와서 사용하고, 사용이 끝나면 비활성화 상태로 풀에 반환

• 이미지(텍스쳐) 설정
  • Generate Mil Maps 해제: 카메라와의 거리를 다이나믹하게 조정하는 게임이 아닌 이상 필요 없음.
  • 압축 옵션의 포맷은 알파값이 있다면 Truecolor 아니면 Compressed 옵션을 추천:
    알파값 존재시 Compressed 옵션으로 인한 화질저하 대비 용량 이득이 크지 않음. 반대로 알파값이 없는 경우 큰 용량 절감 효과를 보여줌. 다만 알파값이 불필요하게 잡혀 들어갔다면 Advanced에서 RGBA가 아닌 RGB 압축 포맷으로 지정해주면 됨.
  • TinyPNG 같은거 쓰지마라. 알아서 유니티가 압축함. 마찬가지로 사이즈를 아무리 크게 해서 넣어도, 압축 설정에 따른 최종 결과물은 같다. 임포트 하기전에 압축한다고 화질을 열화시키는 것은 무의미하다.
  • 도트형 레트로 스타일의 게임인 경우 스프라이트에 필터를 사용하면 안된다. 도트형 그래픽의 외곽선을 부드럽게 꺽어 왜곡하여 비주얼상 더 난잡해 보인다.
  • 압축시 2의 제곱수를 변길이로 가진 정사각형으로 이미지를 사용하므로, 가능한 이 정사각형에 가깝게 이미지 사이즈를 제작하길 추천. 예를 들면 900x1600의 해상도를 가진 물체라면 1024x1024와 2048x2048 중에 maxSize를 고민해야할지도 모른다. 전자는 화질이 손상되고 후자는 낭비다.
  • 개별 이미지를 atlas로 합치는 것이 성능에 도움이 된다. 방법은 이곳을 참고: http://lhh3520.tistory.com/350
    • 참고로 Resources 폴더의 텍스쳐는 엔진 구조상의 문제로 유니티 내부 기능으로 팩킹 불가능. 5에서도 여전하니, 해결되길 기다리자.
  • Advacned로 압축을 설정할때 압축 포맷이 빌드 타켓 플랫폼과 호환되는지 확인하라. 호환되지 않는 포맷은 해당 플랫폼에서 무압축으로 적재된다.
    • ECT2가 ECT1호환 된다고 하지만, 그건 호환이 된다는거지 실제론 무압축으로 올려버린다. 그리고 ETC2가 대세긴 하지만 현실적으로 ETC1을 지원하는 구기기들이 점유율이 더 많다.
• UGUI
  • 하나의 캔버스에 모든 UI요소를 넣는 것이 좋지만은 않다. 캔버스에서 상호작용 가능한 스프라이트가 동적으로 변할때, 캔버스에 있는 전체 요소들에 대해 갱신비용이 들어간다.
• 사운드 설정
  • 모바일에서 스트레오는 큰 의미를 가지지 않는다. Force To Mono 사용.
  • Preload Audio Data는 씬 로드에 부담을 준다. 해제.
  • Load in Background는 엄격하게 재생 타이밍을 맞춰야 하는 경우가 아니면, 체크할 수 있다. 오디오는 조금 늦게 재생되지만 로딩 속도를 적게나마 향상시킬 수 있다.
  • 로드 타입에서 Decompress On Load는 압축을 해제해서 메모리에 적재하기에, 플레이 하는 순간에 오버헤드가 생기지 않는다. 적은 용량의 파일, 효과음에 사용.
  • Compress On Memory는 메모리에서는 압축되어 있다가 재생시 압축을 해제한다. 플레이하는 순간에 오버헤드가 생길 수 있다. 메모리에 그대로 적재하기는 힘든 큰 용량의 파일, 배경 음악에 사용.
  • 역시 모바일에서 높은 kbps는 크게 의미 있지 않다. 가능한 줄여본다.
  • 오디오 매지너에서 스트레오 사운드가 필요없으면 스피커 모드를 Mono나 Raw로 한다.
• 폰트
  • 모든 완성형 한글을 메모리에 넣어도 괜찮다고 생각하는게 아니라면 Dynamic을 사용한다.
  • 만약 해당 폰트를 꼭 써야하는게 아니라면 Incl. Font Data를 해제한다. 해당 폰트가 시스템에 존재하면 사용하고, 없으면 시스템 폰트를 가져다 쓸것이다. 빌드 사이즈가 줄어든다.
• 물리 설정
  • 물리, 레이캐스팅을 사용하지 않는 형태의 게임이라면 충돌 레이어 설정을 해제하라. 프로젝트 세팅 중 Physics 에서 Collision 레이어 항목 체크를 해제해준다.
  • FixedUpdate는 랜더와 상관없이 물리를 위해 독립적으로 일정 간격 호출되는 함수다. 필요에 따라 호출간격으로 조정해준다. 게임에 따라 0.2초에 한번 호출,, 정도로 호출 간격을 늘려도 문제없다.
• 빌드시 세팅
• x86을 사용하는 안드로이드 기기는 거의 없다. FAT을 하지 말고 ARM 대상으로만 빌드
• Stripping Level의 경우 가능한 높은 수준을 추천하나, micro nmscorlib이나 byte code 세팅은 프로그램을 크래쉬할 수 있으니 빌드 테스트를 한다. 일반적으로는 무난하게 assembly 로 적용하고 바로 빌드한다.
• 32비트 품질이 필요한지 비교후, 그렇지 않다면 체크 해제한다.
• 호환에 문제가 없다면 .NET 2.0 Subset 사용

• [출처] 유니티 최적화 Tip|작성자 은채아버지

참조 - http://blog.naver.com/alan79/220963558032