Addressable Assets development cycle

Addressable Assets development cycle

Addressable Asset의 주요 이점 중 하나는 컨텐츠를 배열, 빌드 및 로드하는 방법을 분리하는 것이다. 전통적으로 이러한 발전 측면은 서로 강하게 연결되어 있다.

Traditional asset management

만일 당신이 자원 디렉토리에 콘텐츠를 배열한다면, 그것은 기본 어플리케이션에 내장되고 당신은 Resources.Load 메소드를 사용하여 콘텐츠를 로드해야 하며, 자원에 대한 경로를 제공해야 한다. 다른 곳에 저장된 콘텐츠에 액세스하려면 직접 참조 또는 에셋 번들을 사용하십시오. 에셋 번들을 사용할 경우, 부하와 조직 전략을 함께 묶어 경로별로 다시 로드할 수 있다. 에셋 번들이 원격이거나 다른 번들에 종속성이 있는 경우 모든 번들의 다운로드, 로드 및 언로드 작업을 관리하는 코드를 작성해야 한다.

Asset group schemas

스키마는 데이터 집합을 정의한다. 에셋 그룹의 인스펙터에 스키마를 첨부할 수 있다. 그룹에 첨부된 스키마 집합은 빌드가 내용을 처리하는 방법을 정의한다. 예를 들어 포장 모드에서 빌드할 때 BundleAssetGroupSchema 스키마가 연결된 그룹은 에셋 번들의 소스로 작용한다. 스키마 집합을 새 그룹을 정의하는 데 사용하는 템플릿으로 결합할 수 있다. AddressableAssetSettings Inspector를 통해 스키마 템플릿을 추가할 수 있다.

Build scripts

빌드 스크립트는 IDataBuilder 인터페이스를 구현하는 프로젝트에서 ScriptableObject 에셋으로 표현된다. 사용자는 자체 빌드 스크립트를 생성하고 해당 검사기를 통해 AddressableAssetSettings 개체에 추가할 수 있다. Addressables Groups window (Window > Asset Management > Addressables > Groups)에서 빌드 스크립트를 적용하려면 Play Mode Script를 선택하고 드롭다운 옵션을 선택하십시오. 현재 전체 애플리케이션 빌드를 지원하기 위해 구현된 스크립트 3개와 편집기에서 반복하기 위한 Play Mode Script 3개가 있다.

Play mode scripts

Addressable Assets 패키지에는 앱 개발을 가속화하기 위해 재생 모드 데이터를 생성하는 세 가지 빌드 스크립트가 있다.

Use Asset Database (faster)

Asset Database mode (BuildScriptFastMode)를 사용하면 게임의 흐름을 따라 작업할 때 게임을 빠르게 실행할 수 있다. 분석이나 에셋 번들 생성 없이 신속하게 반복할 수 있도록 에셋 데이터베이스를 통해 에셋을 직접 로드한다.

Simulate Groups (advanced)

Simulate Groups mode(BuildScriptVirtualMode)는 에셋 번들을 생성하지 않고 레이아웃 및 종속성에 대한 컨텐츠를 분석한다. 에셋은 번들을 통해 로드된 것처럼 리소스 관리자를 통해 에셋 데이터베이스로부터 로드된다. 게임 실행 중에 번들이 로드되거나 언로드되는 시기를 확인하려면 Addressables Event Viewer 윈도우에서 에셋 사용량을 확인하십시오.(Window > Asset Management > Addressables > Event Viewer).

Simulate Groups mode는 로드 전략을 시뮬레이션하고 컨텐츠 그룹을 조정하여 프로덕션 릴리스에 적합한 균형을 찾도록 도와준다.

Use Existing Build (requires built groups)

 Existing Build mode를 사용하면 배포된 애플리케이션 빌드와 가장 밀접하게 일치하지만 별도의 단계로 데이터를 빌드해야 한다. 에셋을 수정하지 않는 경우 재생 모드로 들어갈 때 데이터를 처리하지 않기 때문에 이 모드가 가장 빠르다. Addressables Groups window(Window > Asset Management > Addressables > Groups) 에서 Build > New Build > Default Build Script를 선택하여 이 모드에 대한 콘텐츠를 빌드하거나,  AddressableAssetSettings.BuildPlayerContent() 메소드를 게임스크립트에서 사용할 수 있다.

Analysis and debugging

기본적으로 Addressable Assets은 경고 및 오류만 기록한다. Player settings window(Edit > Project Settings... > Player)을 열어 상세 로깅을 활성화할 수 있다. Other Settings > Configuration section으로 이동하고, Scripting Define Symbols 필드에 "ADDRESTABLE_LOG_ALL"을 추가한다.

AddressableAssetSettings 개체 Inspector에서 Log Runtime Exceptions 옵션을 선택 해제하여 예외를 비활성화할 수도 있다. 리소스 관리자를 구현할 수 있다.원하는 경우 사용자 고유의 예외 처리기가 있는 ExceptionHandler 속성이지만 이 작업은 주소록이 런타임 초기화를 완료한 후에 수행해야 한다(아래 참조).

Initialization objects

오브젝트들을 Addressable Assets setting에 연결하고 런타임에 초기화 프로세스에 개체를 전달하십시오. CacheInitializationSettings 오브젝트는 런타임에 Unity의 캐싱 API를 제어한다. 고유한 초기화 개체를 생성하려면 IObjectInitializationDataProvider 인터페이스를 구현하는 ScriptableObject를 생성하십시오. 런타임 데이터와 직렬화되는 ObjectInitializationData를 생성하는 것을 담당하는 시스템의 Editor 구성요소 입니다.

Customizing URL Evaluation

런타임에 자산의 경로나 URL(일반적으로 AssetBundle)을 사용자 정의해야 하는 몇 가지 시나리오가 있다. 가장 일반적인 예는 서명된 URL을 만드는 것이다. 다른 하나는 동적 호스트 결정일 수 있다.

아래 코드는 모든 URL에 쿼리 문자열을 추가하는 예:

//Implement a method to transform the internal ids of locations
string MyCustomTransform(IResourceLocation location)
{
    if (location.ResourceType == typeof(IAssetBundleResource) && location.InternalId.StartsWith("http"))
        return location.InternalId + "?customQueryTag=customQueryValue";
    return location.InternalId;
}

//Override the Addressables transform method with your custom method.  This can be set to null to revert to default behavior.
[RuntimeInitializeOnLoadMethod]
static void SetInternalIdTransform()
{
    Addressables.InternalIdTransformFunc = MyCustomTransform;
}

*참고하십시오*: Android 플랫폼에 비디오 파일을 로드할 목적으로 주소록에 비디오 파일을 번들링할 때는 CacheInitializationSettings개체를 생성하고 해당 개체에서 압축 번들을 사용하지 않도록 설정한 다음 아직 없는 경우 AddressableAssetSettings 개체의 초기화 개체 목록에 추가해야 한다.

Content update workflow

Unity는 게임 콘텐츠를 두 가지 범주로 구성할 것을 권장한다.

* Static content  결코 업데이트 하지 않을 컨텐츠

* Dynamic content 업데이트할 것으로 예상되는 컨텐츠

이 구조에서 정적 콘텐츠(Static content)는 애플리케이션(또는 설치 직후 다운로드)과 함께 제공되며 매우 적은 수의 대형 번들로 상주한다. 동적 콘텐츠는 온라인에 저장되며, 각 업데이트에 필요한 데이터 양을 최소화하기 위해 더 작은 번들로 구성된 것이 이상적이다. Addressable Assets 자산 시스템의 목표 중 하나는 스크립트를 변경하지 않고도 이 구조를 쉽게 작업하고 수정할 수 있도록 하는 것이다.

그러나 Addressable Assets System 시스템은 완전히 새로운 애플리케이션 빌드를 게시하지 않으려는 경우에도 "static" 컨텐츠의 변경이 필요한 상황을 수용할 수 있다.

원격 업데이트를 허용하지 않는 경우(예: 현재 대부분의 비디오 게임 콘솔 또는 서버가 없는 게임)에는 매번 완전하고 새로운 빌드를 만들어야 한다는 점에 유의하십시오.

How it works

주소록(Addressables)은 content catalog를 사용하여 주소를 각 에셋에 매핑하여 로딩 위치와 방법을 지정한다. 앱에 매핑을 수정할 수 있는 기능을 제공하려면 원래 앱이 이 카탈로그의 온라인 사본을 알고 있어야 한다.이를 설정하려면 AddressableAssetSettings Inspector에서 Build Remote Catalog setting을 실행하십시오. 이렇게 하면 카탈로그의 복사본이 지정된 경로에 빌드되어 로드될 수 있다. 이 로드 경로는 앱이 일단 출시되면 변경할 수 없다. 컨텐츠 업데이트 프로세스는 이전에 지정된 로드 경로에 있는 파일을 덮어쓰는 새로운 버전의 카탈로그(동일한 파일 이름)를 생성한다.

애플리케이션을 구축하면 고유한 앱 콘텐츠 버전 문자열이 생성되며, 이는 각 앱이 로드해야 하는 콘텐츠 카탈로그를 식별한다. 특정 서버는 충돌 없이 여러 버전의 앱 카탈로그를 포함할 수 있다. 필요한 데이터는 addressable_content_state.bin 파일에 저장한다. 여기에는 StaticContent로 표시된 그룹에 포함된 모든 자산에 대한 해시 정보와 함께 버전 문자열이 포함된다. 기본적으로 이 디렉토리는 Assets/AddressableAssetsData/<플랫폼> 프로젝트 디렉토리에 위치하며, 여기서 <플랫폼>은 당신의 목표 플랫폼이다.

addressable_content_state.bin 파일에는 주소록 시스템의 모든 StaticContent 자산 그룹에 대한 해시 및 종속성 정보가 포함되어 있다. StreamingAssets 폴더에 구축되는 모든 그룹은 StaticContent로 표시해야 하지만 대규모 원격 그룹도 이 지정의 혜택을 받을 수 있다. 다음 단계(콘텐츠 업데이트 준비, 이하 설명) 동안 이 해시 정보는 StaticContent 그룹이 변경된 에셋을 포함하고 있는지 여부를 결정하므로 해당 에셋을 다른 곳으로 이동해야 한다.

Preparing for content updates(컨텐츠 업데이트 준비)

StaticContent 그룹에서 에셋을 수정한 경우 컨텐츠 업데이트 준비 명령(Prepare For Content Update command)을 실행하십시오. 이렇게 하면 정적 그룹(static groups)에서 수정된 에셋이 모두 제거되고 새 그룹으로 이동한다.  new asset groups을 생성하려면:

1. Open the Addressables window in the Unity Editor (Window > Asset Management > Addressable Assets).

2. Addressables window에서 상단 메뉴 모음에서 Build를 선택한 다음 내용  Prepare For Content Update를 선택하십시오.

3. Build Data File dialog에서 addressable_content_state.bin 파일(기본적으로 이 파일은 Assets/AddressableAssetsData Project 디렉터리에 있음)을 선택하십시오.

이 데이터는 응용 프로그램이 마지막으로 구축된 이후 어떤 에셋이나 종속성이 수정되었는지 확인하는 데 사용된다. 이 시스템은 콘텐츠 업데이트 빌드를 준비하기 위해 이러한 에셋을 새로운 그룹으로 이동시킨다.

참고: 이 명령은 모든 변경 사항이  non-static groups에 국한된 경우 아무 것도 수행하지 않는다.

중요: 준비 작업을 실행하기 전에 Unity는 버전 제어 시스템의 분기를 권장한다. 준비 작업을 수행하면 컨텐츠 업데이트에 적합한 방식으로 에셋그룹이 재구성된다. 브랜딩은 다음에 새 플레이어를 발송할 때 선호하는 콘텐츠 배열로 돌아갈 수 있도록 보장한다.

Building for content updates

콘텐츠 업데이트를 위해 빌드하려면:

1. Open the Addressables window in the Unity Editor (Window > Asset Management > Addressable Assets).

2. Addressables window,에서 상단 메뉴에서 Build 를 선택한 다음 Build For Content Update를 선택하십시오.

3. Build Data File dialog에서 기존 응용 프로그램 빌드의 빌드 폴더를 선택하십시오. 빌드 폴더는 addressable_content_state.bin 파일을 포함해야 한다.

빌드는 content catalog, hash file, 및 asset bundles을 생성한다.

생성된 콘텐츠 카탈로그는 선택한 애플리케이션 빌드의 카탈로그와 이름이 동일하여 이전 카탈로그와 해시 파일을 덮어쓴다. 응용 프로그램은 새 카탈로그가 사용 가능한지 확인하기 위해 해시 파일을 로드한다. 시스템은 애플리케이션과 함께 제공되거나 이미 다운로드된 기존 번들에서 수정되지 않은 에셋을 로드한다.

시스템은 addressable_content_state.bin 파일의 컨텐츠 버전 문자열과 위치 정보를 사용하여 자산 번들을 생성한다. 업데이트된 콘텐츠를 포함하지 않는 에셋번들은 업데이트를 위해 선택한 빌드에 있는 것과 동일한 파일 이름으로 작성된다. 에셋번들에 업데이트된 콘텐츠가 포함된 경우, 원본과 공존할 수 있도록 새로운 파일 이름과 함께 업데이트된 콘텐츠가 포함된 새로운 에셋 번들이 생성된다. 새 파일 이름을 가진 에셋번들만 컨텐츠를 호스팅하는 위치에 복사해야 한다.

또한 시스템은 static content용 자산 번들을 구축하지만, Addressables asset  항목이 이를 참조하지 않으므로 컨텐츠 호스팅 위치에 업로드할 필요는 없다.

Content update examples

이 예에서 출시된 애플리케이션은 다음과 같은 그룹을 알고 있다.

이 버전이 라이브이기 때문에, 기기에 Local_Static이 있는 플레이어가 있다. 그리고 원격 번들 중 하나 또는 둘 모두를 로컬로 캐시할 수 있다.

각 그룹(AssetA, AssetL 및 AssetX)에서 하나의 자산을 수정한 다음 컨텐츠 업데이트 준비를 실행하면 이제 로컬 주소 지정 가능 설정의 결과가 다음과 같이 된다.

준비 작업은 실제로 정적 그룹을 편집하며, 이는 역직관적으로 보일 수 있다는 점에 유의하십시오. 그러나 핵심은 시스템이 위의 레이아웃을 구축하지만 정적 그룹에 대한 빌드 결과는 무시한다는 것이다. 이와 같이 선수 입장에서는 다음과 같은 결과를 초래하게 된다.

Local_Static 번들은 이미 플레이어 장치에 있으며, 변경할 수 없다. 이 이전 버전의 AssetA는 더 이상 참조되지 않는다. 대신 플레이어 기기에 데드 데이터로 고정된다.

Remote_Static 번들은 변경되지 않는다. 플레이어의 장치에 아직 캐시되지 않은 경우, 자산M 또는 자산N을 요청할 때 다운로드한다. AssetA와 마찬가지로 이 이전 버전의 AssetL은 더 이상 참조되지 않는다.

Remote_NonStatic 번들은 이제 오래되었다. 서버에서 삭제할 수 있지만 어느 쪽이든 이 시점부터는 다운로드되지 않을 것이다. 캐싱하면 결국 캐시를 떠난다. AssetA 및 AssetL과 마찬가지로 이 이전 버전의 AssetX는 더 이상 참조되지 않는다.

이전 Remote_NonStatic 번들은 해시 파일로 구분되는 새 버전으로 대체된다. 수정된 AssetX 버전이 이 새로운 번들로 업데이트되었다.

content_update_group 번들은 향후 참조될 수정된 에셋으로 구성된다.

이 예제의 의미는 다음과 같다.

1. 변경된 모든 로컬 에셋은 사용자의 기기에서 영구히 사용되지 않은 상태로 남아 있다.

2. 사용자가 이미 비정적 번들을 캐시했으므로 변경되지 않은 에셋(예: AssetY 및 AssetZ)을 포함하여 번들을 다시 다운로드해야 한다. 이상적으로는 사용자가 번들을 캐시하지 않았으며, 이 경우 새로운 Remote_NonStatic 번들을 다운로드하기만 하면 된다.

3. 사용자가 이미 Static_Remote 번들을 캐시했다면 업데이트된 에셋(이 경우 content_update_group을 통한 AssetL)만 다운로드하면 된다. 이것은 이 경우에 이상적이다. 사용자가 번들을 캐시하지 않은 경우, 사용자는 content_update_group을 통해 새로운 AssetL을 다운로드해야 하며, 손대지 않은 Remote_Static 번들을 통해 현재 삭제된 AssetL을 다운로드해야 한다. 초기 캐시 상태에 관계 없이, 사용자는 언제부턴가 장치에 삭제된 AssetL 이 접속되지 않았음에도 불구하고 무한정 캐시된 AssetL 은 액세스되지 않음에도 불구하고 무한정 캐싱된다.

원격 콘텐츠에 대한 최상의 설정은 특정 사용 사례에 따라 달라진다.