에셋 번들 빌드

AssetBundle 워크플로 문서에서는 BuildPipeline.BuildAssetBundles 함수에 3개의 인수를 전달하는 코드 예제를 보았습니다. 이제 조금 더 깊게 알아보도록 하겠습니다.

Assets/AssetBundles: 디렉토리에 에셋 번들의 결과물이 출력됩니다. 결과물이 출력되는 디렉토리는 원하는 대로 변경할 수 있지만, 빌드를 시도하기 이전에 설정한 폴더가 실제로 존재하는지 확인하기 바랍니다.

BuildAssetBundleOptions

다양한 BuildAssetBundleOptions를 사용할 수 있으며, 각각의 옵션은 다양한 효과를 냅니다. 모든 옵션을 표로 확인하려면 BuildAssetBundleOptions의 스크립팅 API 레퍼런스를 확인합니다.

BuildAssetBundleOptions를 필요한 대로 동시에 사용할 수 있지만, 에셋 번들 압축에 관여하는 3개의 구체적인 BuildAssetBundleOptions이 있습니다.

BuildAssetBundleOptions.None: 이 번들 옵션은 직렬화된 데이터 파일의 압축된 단일 LZMA 스트림인 LZMA 압축 포맷을 사용합니다. LZMA 압축 포맷은 번들을 사용하기 전에 전체 번들의 압축을 풀어야 합니다. 따라서 파일 크기는 가장 작아지지만, 압축 해제 때문에 로드 시간이 조금 길어지게 됩니다. BuildAssetBundleOptions를 사용하는 경우 번들의 에셋을 사용하기 위해 모든 번들의 압축을 풀어야 합니다.
번들의 압축이 풀린 이후에는 디스크에서 LZ4 압축 포맷을 사용하여 다시 압축됩니다. LZ4는 번들의 에셋을 사용하기 위해서 모든 번들의 압축을 풀 필요가 없습니다. 이 옵션은 번들의 에셋을 사용하기 위해서 모든 에셋을 로드해야 하는 경우 사용하기에 적합합니다. 이러한 경우의 예제로 캐릭터나 씬에 대한 모든 에셋을 묶는 경우가 있습니다.
LZMA 압축 포맷을 사용하는 것은 파일 크기가 작다는 점을 고려했을 때, 외부 호스트에서 에셋 번들을 최초로 다운로드 받을 때만 권장합니다. UnityWebRequestAssetBundle을 통해 로드된 LZMA 압축 에셋 번들은 자동으로 LZ4 압축으로 재압축되어 로컬 파일 시스템에서 캐시됩니다. 번들을 다른 방법으로 다운로드하고 저장하는 경우 AssetBundle.RecompressAssetBundleAsync API로 재압축할 수 있습니다.
BuildAssetBundleOptions.UncompressedAssetBundle: 이 번들 옵션은 데이터가 전혀 압축되지 않는 방식으로 번들을 빌드합니다. 이 옵션의 단점은 데이터가 압축되지 않았기 때문에 다운로드할 파일 크기가 크다는 점입니다. 하지만 다운로드된 파일을 로드하는 속도는 비교적 빠릅니다.
BuildAssetBundleOptions.ChunkBasedCompression: 이 번들 옵션은 LZ4 압축 메서드를 사용합니다. 메서드는 LZMA 압축 포맷보다 압축된 파일 크기가 크지만 LZMA 포맷과는 다르게 에셋을 사용하기 전에 모든 번들의 압축을 풀 필요는 없습니다. LZ4 압4축 포맷은 청크 기반 알고리즘을 사용하여 에셋 번들이 부분적으로 또는 “청크” 단위로 로드될 수 있도록 합니다. 단일 청크의 압축을 풀면 에셋 번들에서 다른 청크의 압축을 풀지 않아도 해당 청크에 포함된 에셋을 사용할 수 있습니다.

ChunkBasedCompression 옵션을 사용하면 압축되지 않은 번들과 비슷한 로드 속도를 가지게 되지만 디스크의 용량은 적게 차지합니다.

BuildTarget

BuildTarget.Standalone: 이 옵션은 에셋 번들을 사용할 타겟 플랫폼이 무엇인지 빌드 파이프라인에 알려주게 됩니다. Scripting API Reference에서 사용 가능한 명시적인 빌드 타겟의 리스트는 BuildTarget을 참조하십시오. 하지만 빌드 타겟에 하드 코딩을 하기를 원치 않는다면 EditorUserBuildSettings.activeBuildTarget 옵션을 사용합니다. 이 옵션은 현재 빌드 설정이 된 플랫폼을 자동적으로 찾고 그 타겟 기반의 에셋 번들을 빌드합니다.

빌드 스크립트를 적절하게 설정한 이후, 번들을 빌드합니다. 위의 스크립트 예제를 따른 경우 Assets > Build AssetBundles 을 클릭하여 프로세스를 시작합니다.

에셋 번들을 성공적으로 빌드한 경우 에셋 번들 디렉토리에서 예상한 것보다 더 많은 파일이 있을 수 있습니다. 정확히는 2*(n+1)개의 파일이 더 있을 것입니다. 그럼 BuildPipeline.BuildAssetBundles 옵션이 어떤 결과물을 내는지 좀 더 알아보겠습니다.

에디터 상으로 특정한 에셋 번들마다 에셋 번들의 이름으로된 파일과 에셋 번들 이름 + “.manifest”로 된 파일이 생성됩니다.

또한 생성한 에셋 번들과 이름을 공유하지 않는 추가 번들 또는 매니페스트가 있을 것입니다. 이는 자신이 위치한 디렉토리(에셋 번들이 빌드된 디렉토리)의 이름을 사용합니다. 이것이 매니페스트 번들입니다. 나중에 이 번들이 무엇이고, 어떻게 활용하는지 알아볼 것입니다.

에셋 번들(AssetBundle) 파일

이 파일은 .manifest 확장자가 없는 파일로서 에셋을 로드하기 위해 런타임 시점에 로드해야 하는 파일입니다.

에셋 번들 파일은 다수의 파일을 내부적으로 포함하는 아카이브입니다. 아카이브의 구조는 파일이 에셋 번들인지 또는 씬 에셋 번들인지에 따라 미세하게 달라질 수 있습니다. 다음은 일반적인 에셋 번들의 구조의 예제입니다.

씬과 그 콘텐츠를 스트림 로딩할 수 있도록 최적화되었다는 점이 씬 에셋 번들 구조가 일반적인 에셋 번들 구조와 다른 점입니다. 다음의 그림은 씬 번들의 내부 구조입니다.

매니페스트(Manifest) 파일

추가 매니페스트 번들을 포함하여 생성된 번들마다 관련된 매니페스트 파일이 생성됩니다. 매니페스트 파일은 모든 텍스트 에디터로 열 수 있으며 순환 중복 검사(CRC) 데이터 등과 같은 번들에 대한 정보를 포함합니다. 일반적인 에셋 번들의 경우 매니페스트 파일은 다음과 같은 형식을 가집니다.

ManifestFileVersion: 0
CRC: 2422268106
Hashes:
  AssetFileHash:
    serializedVersion: 2
    Hash: 8b6db55a2344f068cf8a9be0a662ba15
  TypeTreeHash:
    serializedVersion: 2
    Hash: 37ad974993dbaa77485dd2a0c38f347a
HashAppended: 0
ClassTypes:
- Class: 91
  Script: {instanceID: 0}
Assets:
  Asset_0: Assets/Mecanim/StateMachine.controller
Dependencies: {}

포함된 에셋, 종속성, 그리고 기타 정보를 보여줍니다.

생성된 매니페스트 번들 역시 매니페스트 파일을 가지지만, 다음과 같은 형식을 가집니다.

ManifestFileVersion: 0
AssetBundleManifest:
  AssetBundleInfos:
    Info_0:
      Name: scene1assetbundle
      Dependencies: {}

이는 에셋 번들이 어떻게 연관되어 있고, 종속성은 어떠한지 보여줍니다. 일단 이러한 번들이 AssetBundleManifest 오브젝트를 포함한다는 점을 이해하게 된다면, 런타임 시점에 로드할 번들의 종속성을 파악하는 데 도움이 됩니다. 번들과 매니페스트 오브젝트를 활용하는 방법은 에셋 번들의 전문적인 활용 문서를 참조하십시오.

에셋 번들을 위한 에셋 준비

에셋 번들 종속성