콘텐츠 업데이트 예시
여기에서는 콘텐츠 업데이트 중에 어드레서블 콘텐츠가 처리되는 방식을 설명하기 위해 가상의 예제를 살펴봅니다. 이 예제에서는 다음과 같은 어드레서블 그룹으로 빌드된 애플리케이션을 고려합니다.
| Local_Static | Remote_Static | Remote_NonStatic |
|---|---|---|
| AssetA | AssetL | AssetX |
| AssetB | AssetM | AssetY |
| AssetC | AssetN | AssetZ |
Local_Static 및 Remote_Static은 Cannot Change Post Release 그룹에 속합니다.
이 버전은 라이브 상태이므로, 기존 플레이어는 기기에 Local_Static이 있으며 원격 번들 중 하나 또는 둘 모두가 로컬로 캐시되어 있을 수 있습니다.
각 그룹에서 하나의 에셋(AssetA, AssetL, AssetX)을 수정한 다음 __Check for Content Update Restrictions__를 실행하면 로컬 어드레서블 설정의 결과가 표시됩니다.
| Local_Static | Remote_Static | Remote_NonStatic | content_update_group(비정적) |
|---|---|---|---|
| AssetX | AssetA | ||
| AssetB | AssetM | AssetY | AssetL |
| AssetC | AssetN | AssetZ |
준비 작업은 Cannot Change Post Release 그룹을 편집하며, 이는 직관적이지 않은 방식처럼 보일 수 있습니다. 하지만 시스템에서는 위의 레이아웃을 빌드하되 해당 그룹에 대한 빌드 결과는 모두 폐기합니다. 따라서 플레이어의 관점에서 보면 다음과 같은 결과가 나옵니다.
| Local_Static |
|---|
| AssetA |
| AssetB |
| AssetC |
Local_Static 번들은 이미 플레이어 기기에 있으며 변경할 수 없습니다. 이 이전 버전의 AssetA는 더 이상 참조되지 않습니다. 대신 플레이어 기기에 죽은 데이터(dead data)로 남아 있습니다.
| Remote_Static |
|---|
| AssetL |
| AssetM |
| AssetN |
Remote_Static 번들은 변경되지 않습니다. 플레이어의 기기에 아직 캐시되지 않은 경우에는 AssetM 또는 AssetN이 요청될 때 다운로드됩니다. AssetA와 마찬가지로 이 이전 버전의 AssetL은 더 이상 참조되지 않습니다.
| Remote_NonStatic(이전) |
|---|
| AssetX |
| AssetY |
| AssetZ |
Remote_NonStatic 번들은 이제 오래된 번들입니다. 서버에서 삭제하거나 그대로 둘 수 있으며, 어느 쪽이든 이 시점부터는 다운로드되지 않습니다. 캐시된 경우에는 따로 제거하지 않는 한 플레이어 기기에 계속 남게 됩니다. 자세한 내용은 에셋 번들 캐싱을 참조하십시오. AssetA 및 AssetL과 마찬가지로 이 이전 버전의 AssetX는 더 이상 참조되지 않습니다.
| Remote_NonStatic(신규) |
|---|
| AssetX |
| AssetY |
| AssetZ |
이전 Remote_NonStatic 번들은 해시 파일로 구분되는 새 버전으로 대체됩니다. 수정된 버전의 AssetX는 이 새 번들로 업데이트됩니다.
| content_update_group |
|---|
| AssetA |
| AssetL |
content_update_group 번들은 앞으로 참조할 수정된 에셋으로 구성됩니다.
위의 예시에는 다음과 같은 의미가 있습니다.
- 변경된 로컬 에셋은 사용자의 기기에서 영원히 사용되지 않습니다.
- 사용자가 이미 비정적 번들을 캐시한 경우 변경되지 않은 에셋(예: AssetY 및 AssetZ)을 포함하여 번들을 다시 다운로드해야 합니다. 사용자가 번들을 캐시하지 않은 경우가 가장 바람직하며, 이때는 새 Remote_NonStatic 번들을 다운로드하기만 하면 됩니다.
- 사용자가 이미
Static_Remote번들을 캐시한 경우 업데이트된 에셋만 다운로드하면 됩니다(이 경우content_update_group을 통해 AssetL 다운로드). 바람직한 상황이라고 할 수 있습니다. 사용자가 번들을 캐시하지 않은 경우content_update_group을 통해 새 AssetL을 다운로드하고, 변경되지 않은Remote_Static번들을 통해 이제는 사용되지 않는 AssetL을 다운로드해야 합니다. 초기 캐시 상태와 관계없이 사용자는 기기에서 사용되지 않는 AssetL에 액세스하지 않았음에도 불구하고 해당 에셋을 캐시된 상태로 무기한 보유하게 됩니다.
원격 콘텐츠에 가장 적합한 설정은 특정 사용 사례에 따라 달라집니다.
콘텐츠 업데이트 종속성
에셋을 직접 변경하는 것만이 콘텐츠 업데이트의 일부로 다시 빌드해야 한다고 플래그를 지정하는 유일한 방법은 아닙니다. 에셋의 종속성 변경은 업데이트를 빌드하면서 고려할 때 비교적 덜 분명한 요소입니다.
예를 들어 위 예제의 Local_Static 그룹을 생각해 보겠습니다.
| Local_Static |
|---|
| AssetA |
| AssetB |
| AssetC |
이 그룹의 에셋에 다음과 같은 종속성 체인이 있다고 가정해 보겠습니다. AssetA는 Dependency2에 종속된 Dependency1에 종속되고, AssetB는 Dependency2에 종속되고, AssetC는 Dependency3에 종속되고, 세 종속성 모두 어드레서블 및 비 어드레서블 에셋이 혼합되어 있습니다.
Dependency1만 변경하고 Check For Content Update Restriction을 실행한 경우 결과로 발생하는 프로젝트 구조는 다음과 같습니다.
| Local_Static | content_update_group |
|---|---|
| AssetA | |
| AssetB | |
| AssetC |
Dependency2만 변경된 경우:
| Local_Static | content_update_group |
|---|---|
| AssetA | |
| AssetB | |
| AssetC |
마지막으로 Dependency3만 변경된 경우:
| Local_Static | content_update_group |
|---|---|
| AssetA | |
| AssetB | |
| AssetC |
이는 종속성이 변경되면 전체 종속성 트리를 다시 빌드해야 하기 때문입니다.
다음 예시에는 이러한 종속성 트리가 있습니다. AssetA는 Dependency2에 종속된 AssetB에 종속되고, AssetB는 Dependency2에 종속되며, AssetC는 Dependency3에 종속됩니다. 이제 Dependency2가 변경되면 프로젝트 구조는 다음과 같이 보입니다.
| Local_Static | content_update_group |
|---|---|
| AssetA | |
| AssetB | |
| AssetC |
AssetA는 AssetB에 종속되고 AssetB는 Dependency2에 종속되기 때문입니다. 전체 체인을 다시 빌드해야 하므로 AssetA와 AssetB는 모두 content_update_group 에 포함됩니다.