빌드한 iOS 플레이어 크기 최적화
플레이어 크기를 줄이는 데는 Xcode 안에서 적절한 Release build 를 만들고 Unity 에서 Stripping Level 을 변경하는 두 가지 방법이 주로 사용됩니다.
최종 릴리스 빌드는 Xcode 커맨드 Product > Archive 를 사용하여 제작될 것으로 예상됩니다. 이 커맨드를 사용하면 빌드를 릴리스 설정으로 제작하고 모든 디버그 심볼을 제거할 수 있습니다. 이 커맨드를 전달하면 Xcode는 Organizer 창의 Archives 탭으로 전환합니다. 앱 크기를 계산하는 방법과 다른 크기 줄이기 팁은 앱 크기 줄이기에 관한 Apple의 기술 Q&A를 참조하십시오.
참고: 무선 전송 규정(over-the-air, OTA) 다운로드 한도(현재 150MB)를 목표로 하는 경우 오류에 대해 약간의 추가 마진을 확보하는 것이 좋습니다.
다음과 같이 작업을 스트리핑하여 Mono 스크립팅 백엔드 빌드에 대한 크기 최적화를 활성화하십시오.
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 파일로 압축합니다. 암호화하면 코드 세그먼트의 “임의성”이 증가하므로 압축하기가 더 어려워집니다. 제출하기 전에 위의 “배포용 빌드” 섹션에서 앱 스토어 크기를 최적화하는 방법을 참조하십시오.
2018–06–14 일부 편집 리뷰를 거쳐 페이지 수정됨
2017–14–06 - IL2CPP로 스트리핑 섹션 업데이트