플레이어 크기를 줄이는 방법에는 Xcode 안에서 적절한 Release build 를 만드는 방법과 Unity 에디터에서 Stripping Level 을 변경하는 방법 두 가지가 주로 사용됩니다.
최종 릴리스 빌드는 Xcode 4.x/5.x 커맨드인 Product -> Archive__를 사용하여 만들어야 합니다. 커맨드를 사용하면 빌드가 릴리스 설정을 사용하여 만들어지고 모든 디버그 심볼이 스트립됩니다. 커맨드를 전달한 후에는 최근 Xcode가 Organizer 창의 Archives__ 탭으로 전환됩니다. Window -> Organizer 메뉴를 통해 수동으로 이 탭으로 이동할 수 있습니다. 탭에는 App Store size estimation__과 Distribution__이라는 매우 유용한 기능이 2개 있습니다. 빌드 크기 추정 기능은 꽤 효과적이지만, 3G 다운로드 최고 속도(현재 100MB)를 목표로 하는 경우 항상 약간의 오차를 감안하는 것이 좋습니다.
스트리핑 작업에 의한 크기 최적화는 다음과 같이 진행됩니다.
Strip assemblies 수준: 스크립트의 바이트코드를 분석하여 스크립트에서 레퍼런스되지 않는 클래스와 메서드가 DLL에서 삭제하고 AOT 컴파일 단계에서 제외합니다. 이 최적화는 메인 바이너리와 첨부되는 DLL의 크기를 줄이며, 반사를 사용하지 않는 한 안전합니다.
Strip ByteCode 수준: (Data 폴더에 저장된) .NET DLL은 메타데이터만 남도록 스트립됩니다. 이렇게 할 수 있는 이유는 모든 코드가 AOT 단계에서 이미 미리 컴파일되어 메인 바이너리에 링크되기 때문입니다.
Use micro mscorlib 수준: 더 작고 특수한 mscorlib 버전을 사용합니다. Security, Reflection.Emit, Remoting, non-Gregorian calendars 등 일부 컴포넌트는 라이브러리에서 삭제됩니다. 또한 내부 컴포넌트 간 상호 종속성이 최소화됩니다. 이 최적화는 메인 바이너리와 mscorlib.dll의 크기를 줄이지만, 일부 System 및 System.Xml 어셈블리 클래스와 호환되지 않으므로 주의해서 사용해야 합니다.
각 수준은 누적되어 적용됩니다. 3수준 최적화는 1수준과 2수준 최적화를 포함하고, 2수준 최적화는 1수준 최적화를 포함합니다.
Micro mscorlib 은 많이 스트립된 코어 라이브러리 버전입니다. Mono 런타임에 필요한 항목만 Unity 에디터에 남습니다. Micro mscorlib을 사용하는 모범 사례는 애플리케이션에 필요하지 않은 클래스나 기타 .NET 기능을 사용하지 않는 것입니다. 제외할 수 있는 좋은 예로 GUID가 있습니다. GUID는 커스텀 의사(pseudo) GUID로 쉽게 대체할 수 있고, 이렇게 하면 성능이 향상되고 앱 크기가 줄어듭니다.
자세한 내용은 IL2CPP로 관리 바이트코드 스트리핑 문서를 참조하십시오.
참고: 때로는 어떤 클래스가 애플리케이션에 필요한데도 스트립되는 것은 아닌지 알기 어려울 수 있습니다. 스트립된 애플리케이션을 시뮬레이터에서 실행하고 Xcode 콘솔에 표시되는 오류 메시지를 확인하여 이와 관련된 유용한 정보를 얻을 수 있습니다.
모든 크기 최적화를 끄고 만든 빈 프로젝트는 앱 스토어에서 22MB 미만의 공간을 차지합니다. 코드 스트리핑을 사용하면 메인 카메라만 포함하는 빈 씬의 크기를 앱 스토어에서 12MB 미만(압축하고 DRM 연결 시)까지 줄일 수 있습니다.
앱을 퍼블리시하면 Apple 앱 스토어 서비스가 바이너리 파일을 먼저 암호화한 다음 zip 파일로 압축합니다. 암호화하면 코드 세그먼트의 “임의성”이 증가하므로 압축하기가 더 어려워집니다. 제출하기 전에 위의 “배포용 빌드” 섹션에서 앱 스토어 크기를 최적화하는 방법을 참조하십시오.