애셋번들 사용패턴 (AssetBundle usage patterns) 6 – 번역

애셋번들 사용패턴 (AssetBundle usage patterns) – 번역

– 원문 링크 –

 

이전글 – 애셋번들을 사용할때 발생할 수 있는 일반적인 문제

4.6 애셋번들 변형 (AssetBundle Variants)

유니티5 애셋번들 시스템의 핵심 기능은 애셋번들 변형(AssetBundle Variant)를 도입한 것입니다.
애셋번들 변형(AssetBundle Variant)의 목적은 어플리케이션이 런타임 환경에 더 적합한 방법으로 콘텐츠를 조절할 수 있도록 하는 것입니다.
애셋번들 변형(AssetBundle Variant)은, 오브젝트를 로드하고 Instance ID 정보를 얻어올때, 서로 다른 애셋번들 파일 안에 있는 여러 오브젝트들이(UnityEngine.Objects) 동일한 오브젝트로 나타나는 것을 허용합니다.

개념적으로, 두 개의 오브젝트(UnityEngine.Objects)에서 동일한 File GUID 및 Local ID를 공유하도록 해서, 실제 로드할 오브젝트(UnityEngine.Objects)를 Variant ID 문자열로 식별합니다.

애셋번들 변형(AssetBundle Variants) 시스템의 두 가지 주요 활용 사례가 있습니다:

• 변형(Variants)은 특정 플랫폼에 적합한 애셋번들을 로딩하는 과정을 단순화 시킵니다.

– 예: 어떤 빌드 시스템에서, 스탠드 얼론 DirectX11 윈도우즈 빌드에 적합한 고해상도 텍스쳐 및 복잡한 쉐이더를 포함하는 애셋번들 하나를 생성하고, 안드로이드에 적합한 저해상도 콘텐츠를 포함하는 두번째 애셋번들을 생성할 수 있습니다. 런타임에, 해당 프로젝트의 리소스 로딩 코드는 실행되는 플랫폼에 맞는 애셋번들 변형(AssetBundle Variants)을 로드할 수 있으며, AssetBundle.Load API에 전달된 오브젝트 이름을 변경할 필요가 없습니다.

• 변형(Variant)을 사용하면, 동일한 플랫폼이지만 다른 하드웨어를 사용하는 경우, 어플리케이션에서 그 차이에 따라서 다른 애셋번들을 로드할 수 있습니다.

– 이를 활용해서 광범위한 모바일 장치를 지원할 수 있습니다. 실제 어플리케이션에서, 아이폰 4는 아이폰 6와 동일한 사양의 콘텐츠를 표시할 수 없습니다. 안드로이드에서는, 애셋번들 변형(AssetBundle Variant)을 활용해서, 여러 장치 간의 화면 종횡비(Aspect Ratio) 및 DPI에 대한 엄청난 파편화를 대응할 수 있습니다.

 

4.6.1 제한사항 (Limitations)

애셋번들 변형(AssetBundle Variants) 시스템의 핵심 제한사항은 별도의 애셋으로 변형(Variant)가 빌드되어야 한다는 점입니다.
이 제한사항은 해당 애셋 간의 유일한 차이점이 그 애셋의 임포트 설정인 경우에도 적용됩니다.
Variant A와 Variant B에 빌드된 각 텍스쳐 간의 유일한 차이점이, 유니티 텍스쳐 임포터에서 선택한 텍스쳐 압축 알고리즘인 경우, Variant A와 Variant B는 완전히 다른 애셋으로 취급되어야 합니다. 즉, Variant A와 Variant B는 디스크에서 별도의 파일로 존재해야 합니다.

이 제한사항은 특정 애셋을 소스 컨트롤(Source Control)에 여러 사본으로 보관 해야하기 때문에 대규모 프로젝트의 관리를 복잡하게 만듭니다.
개발자가 해당 애셋을 업데이트 하려는 경우, 해당 애셋의 모든 복사본도 같이 업데이트 해야 합니다.

이 문제를 해결하기 위해서 제공되는 내장 기능이 없습니다.

대부분의 팀에서 자체 애셋번들 변형(AssetBundle Variant) 폼(form)을 구현합니다.
이 작업은, 주어진 애셋번들이 나타내는 특정 변형(Variant)을 식별하기 위해서, 파일 이름 뒤에 잘-정의된 접미어가 추가된 애셋번들을 빌드하는 방식으로 수행합니다.
커스텀 코드는, 이러한 애셋번들을 로드할때 포함된 애셋의 임포트 설정을 프로그래밍으로 변경합니다.
일부 개발자들은 프리팹(prefab)에 추가된 컴포넌트의 매개변수(parameter)도 변경할 수 있도록, 자체 제작한 시스템을 확장하기도 합니다.

 

4.7 압축하거나 압축하지 않거나 (Compressed or uncompressed?)

애셋번들을 압축할지 여부는 신중하게 고려해야 합니다. 이를 위한 확인해야하는 중요한 질문은 다음과 같습니다:

• 애셋번들의 로딩 시간이 중요한 요소인가요? 로컬 저장소 또는 로컬 캐시에서, 압축하지 않은 애셋번들이 압축된 애셋번들을 로드하는 것보다 훨씬 빠릅니다. 일반적으로 원격 서버에서 압축된 애셋번들을 다운로드하는 것이 압축하지 않은 애셋번들을 다운로드하는 것보다 빠릅니다.

• 애셋번들의 빌드 시간이 중요한 요소인가요? LZMA 및 LZ4 방식은 파일을 압축할때 매우 느리고, 유니티 에디터는 애셋번들을 순차적으로 처리합니다. 다수의 애셋번들이 포함된 프로젝트는 그 애셋번들을 압축하는데 많은 시간이 소모됩니다.

• 어플리케이션의 크기가 중요한 요소인가요? 애셋번들이 어플리케이션과 함께 배포되는 경우, 애셋번들을 압축하면 어플리케이션의 전체 크기를 줄일 수 있습니다. 또는 어플리케이션을 설치한 후에 애셋번들을 다운로드 시킬 수도 있습니다.

• 메모리 사용량이 중요한 요소인가요? 유니티 5.3 이전 버전에서 유니티의 모든 압축 해제 매커니즘(mechanism)은 압축을 해제하기 전에 압축된 애셋번들을 전체 메모리에 로드해야만 했습니다. 메모리 사용량이 중요한 경우, 압축하지 않은 애셋번들이나 LZ4 압축방식으로 압축된 애셋번들을 사용하시기 바랍니다.

• 다운로드 시간이 중요한 요소인가요? 애셋번들의 크기가 크거나, 모바일에서 3G를 통해서 다운로드하거나 낮은 속도에서 다운로드 하는 경우와 같이, 대역폭 제한이 있는 환경에서 사용하는 경우에만 압축이 필요합니다. 높은 속도의 접속을 허용하는 환경에서 PC에 몇 십 메가 바이트 정도의 데이터를 전달하려는 경우에는, 압축을 생략할 수 있습니다.

 

4.8 애셋번들과 WebGL (AssetBundles and WebGL)

유니티는 WebGL 프로젝트에서 압축된 애셋번들을 사용하지 않도록 권장합니다.

유니티 5.3 부터, WebGL에서 애셋번들의 압축 해제 및 로딩은 메인 쓰레드에서 처리되어야 합니다.
이는 유니티 5.3 WebGL의 추출(export) 옵션이 현재 작업 쓰레드(worker thread)를 지원하지 않기 때문입니다.
(애셋번들의 다운로드는 XMLHttpRequest Javascript API를 통해서 브라우저에 위임되며, 유니티의 메인 쓰레드에서 실행됩니다.)
즉, WebGL에서 압축된 애셋번들을 로드하는데 쓰이는 비용이 매우 비쌉니다.

이를 염두해두고, 애셋번들에 기본 LZMA 포맷의 사용을 피하고, 필요시 매우 효과적으로 압축을 해제하는 LZ4 방식을 사용해서 압축하는 것이 좋습니다.
LZ4 방식이 제공하는 것보다 더 작은 크기로 압축하려는 경우, 웹서버가 HTTP 프로토콜 수준(LZ4 압축 상단)에서, gzip 방식으로 압축할 수 있도록 구성할 수 있습니다.

 

내용 끝까지 읽어주셔서 감사합니다.
배너 클릭은 저에게 많은 힘이 됩니다.
감사합니다 🙂