빌드 파일 크기 축소
항상 빌드된 앱의 파일 크기를 최소한으로 유지하는 것이 중요하지만, 크기 제한을 적용하는 모바일 디바이스나 앱 스토어의 경우 더욱 중요합니다. 크기를 줄이는 첫 단계에는 파일에서 가장 큰 공간을 차지하는 에셋이 무엇인지 확인해야 합니다. 이러한 에셋을 최적화하는 것이 가장 효과적일 수 있기 때문입니다. 이 정보는 빌드를 수행한 직후에 에디터 로그에서 확인할 수 있습니다. 콘솔 창으로 이동(메뉴: Window < Console)하여 오른쪽 상단의 작은 드롭다운 패널을 클릭하고 Open Editor 를 선택합니다.
에디터 로그에는 타입별로 나눈 에셋의 개요가 표시되고 이어서 개별 에셋이 파일에서 차지하는 크기에 따라 순서대로 나열됩니다. 일반적으로 텍스처, 사운드 및 애니메이션 등의 에셋이 스토리지를 가장 많이 차지하고 스크립트, 레벨 및 셰이더가 파일 크기에 미치는 영향이 가장 적습니다. 리스트에 보이는 File headers 는 에셋이 아니라 레퍼런스 및 설정을 저장하기 위해 “원시” 에셋 파일에 추가로 더해지는 데이터입니다. 일반적으로 헤더는 에셋 크기에 거의 영향을 미치지 않지만 Resources 폴더에 커다란 에셋이 많으면 값이 클 수 있습니다.
에디터 로그는 제거하거나 최적화할 수 있는 에셋을 식별하는 데 유용하지만, 시작하기 전에 다음 사항을 고려해야 합니다.
Unity는 임포트된 에셋을 자체적인 내부 포맷으로 다시 코딩하므로 선택하는 소스 에셋 타입은 중요하지 않습니다. 예를 들어 프로젝트에 멀티 레이어 Photoshop 텍스처가 있는 경우 빌드 전에 레이어를 줄이고 압축합니다. 텍스처를 .png 파일로 익스포트해도 빌드 크기는 변하지 않으므로 개발 중에 가장 편리한 포맷을 유해야 합니다.
Unity는 빌드 중에 사용되지 않는 에셋을 대부분 제거하므로 프로젝트에서 에셋을 수동으로 제거해도 이득이 없습니다. 제거되지 않는 에셋은 스크립트(어차피 매우 작은 경우가 대부분이므로)와 Resources 폴더에 있는 에셋(Unity가 폴더에서 필요하고 필요하지 않은 에셋을 구분할 수 없으므로) 뿐입니다. 따라서 Resources 폴더에 있는 에셋만 게임에 필요한지 확인해야 합니다. Resources 폴더에 있는 에셋을 AssetBundle로 대체할 수 있습니다. 그러면 Unity가 에셋을 동적으로 로드하므로 플레이어 크기가 작아집니다.
빌드 크기 축소를 위한 제안
텍스처
텍스처는 일반적으로 빌드에서 가장 많은 공간을 차지합니다. 이 문제를 해결하는 첫 번째 방법으로, 압축 텍스처 포맷을 사용할 수 있습니다. 자세한 내용은 플랫폼별 텍스처 압축을 참조하십시오.
이 방법으로 파일 크기가 충분히 작아지지 않으면 텍스처 이미지의 물리적 크기(픽셀 단위)를 줄여보십시오. 실제 소스 콘텐츠를 수정하지 않고 이렇게 하려면 프로젝트 뷰에서 텍스처를 선택하고 인스펙터 창에서 Max Size 를 줄입니다. 그 결과가 게임에 어떻게 나타나는지 보려면 텍스처를 사용하는 게임 오브젝트를 확대한 다음 씬 뷰에서 더 안 좋게 보이기 시작할 때까지 Max Size 를 조정합니다. 최대 텍스처 크기를 변경해도 텍스처 에셋에는 영향이 없고 게임에서 표시되는 해상도에만 영향이 있습니다.
기본적으로 Unity는 텍스처를 임포트할 때 모두 압축합니다. 에디터에서 워크플로를 더 빨리 진행하려면 Unity < Preferences 로 이동하고 Compress Assets on Import 체크박스를 선택 해제합니다. 이 설정에 관계 없이 빌드의 모든 텍스처가 압축됩니다.
메시 및 애니메이션
메시와 임포트된 애니메이션 클립을 압축하여 게임 파일에서 차지하는 공간을 줄일 수 있습니다. 메시 압축을 활성화하려면 메시를 선택한 다음 인스펙터 창에서 Mesh Compression 을 Low, Medium 또는 High 로 설정합니다. 메시 및 애니메이션 압축에는 양자화가 사용되므로 공간을 덜 차지하지만, 압축으로 인해 부정확성이 다소 발생할 수 있습니다. 모델에 적합한 압축 수준을 다양하게 실험해 보십시오.
메시를 압축하면 데이터 파일이 더 작아지기만 하고 런타임에 메모리가 덜 사용되지는 않습니다. 애니메이션 키프레임 축소를 사용하면 데이터 파일이 더 작아지고 런타임에 사용되는 메모리도 감소하므로, 일반적으로 항상 활성화하는 것이 좋습니다. 자세한 내용은 애니메이션 클립 문서를 참조하십시오.
DLL
Unity는 기본적으로 다음 DLL만 빌드된 플레이어에 포함합니다.
mscorlib.dll
Boo.Lang.dll
UnityScript.Lang.dll
UnityEngine.dll
플레이어를 빌드할 때 System.dll 또는 System.Xml.dll에 종속성이 없도록 해야 합니다. Unity에서는 기본적으로 종속성이 빌드된 플레이어에 포함되지 않지만, 클래스를 사용하는 경우 포함됩니다. 이 두 DLL은 플레이어 저장 크기를 약 1메가바이트 정도 늘립니다. 게임에서 XML을 파싱해야 하는 경우 시스템 라이브러리보다 작은 Mono.Xml.zip 등의 라이브러리를 대신 사용할 수 있습니다. 일반 컨테이너는 대부분 mscorlib에 포함되지만, 스택을 비롯한 기타 소수의 컨테이너는 System.dll에 포함되므로 가능한 경우 피해야 합니다.
모바일 .NET 라이브러리 크기 축소
Unity는 일부 모바일 디바이스에 대해 두 가지 호환성 레벨인 .NET 2.0 및 .NET 2.0의 하위 집합인 두 가지 .NET API 호환성 수준을 지원합니다. 플레이어 설정에서 빌드에 적합한 레벨을 선택해야 합니다.
.NET 2.0 API 프로파일은 전체 .NET 2.0 API와 유사합니다. 라이브러리 루틴은 대부분 완전히 구현되므로 이 옵션을 선택하면 기존 .NET 코드와의 호환성을 극대화할 수 있습니다. 전체 라이브러리는 많은 게임에서 필요하지 않으며, 불필요한 코드가 소중한 메모리 공간을 다수 차지합니다.
Unity는 메모리 낭비를 방지하기 위해 .NET 2.0 서브셋 API 프로파일도 지원합니다. 이 프로파일은 Mono “monotouch” 프로파일과 매우 유사하므로 “monotouch” 프로파일의 여러 한계가 Unity의 .NET 2.0 서브셋 프로파일에도 적용됩니다. 자세한 내용은 MonoTouch의 한계에 대한 Mono Project 문서를 참조하십시오. 게임에서 일반적으로 필요하지 않은 여러 라이브러리 루틴은 메모리를 아끼기 위해 이 프로파일에서 제외됩니다. 하지만 이로 인해 코드의 해당 루틴에 종속성이 있으면 제대로 작동하지 않습니다. 이 옵션은 유용한 최적화 방법일 수 있지만, 적용 후에도 기존 코드가 계속 작동하는지 확인해야 합니다.