어드레서블에 대한 이해를 하고자 해보았으나 실제 사용하는 방법은 약간 차이가 있다.
일단 하던 번역은 마무리하고 실제 사용 전략에 대해 정리할 예정이다.
2020/06/09 - [개발/Unity] - Addressable Assets development cycle (1)
2020/06/10 - [개발/Unity] - Addressable Assets development cycle (2)
컨텐츠 업데이트 빌드 (Building for content updates)
컨텐츠 업데이트를 빌드하려면 다음을 수행한다.
- 유니티 에디터에서 Addressable Groups window 를 연다 (Window > Asset Management > Addressables > Gruops)
- Addressable Groups window 에서 탑 메뉴의 Build > Update a Previous Build 를 선택한다.
- 빌드 데이터 파일 (Build Data File) 다이얼로그 팝업이 열리면 addressable_content_state.bin 파일을 선택한다.
빌드를 통해 컨텐츠 카탈로그, 해시 파일 및 에셋번들이 생성된다.
생성된 컨텐츠 카탈로그는 선택된 애플리케이션 빌드의 카탈로그와 동일한 이름을 가지며 이전 카탈로그 및 해시 파일을 겹쳐 쓴다. 애플리케이션은 새 카탈로그가 사용가능한지 판별하기 위해 해시 파일을 로드한다. 시스템은 애플리케이션과 함께 제공되거나 이미 다운로드 된 기존 번들에서 수정되지 않은 에셋을 로드한다.
시스템은 addressables_content_state.bin 에서 컨텐츠 버전 문자열과 위치 정보를 사용하여 에셋 번들을 생성한다. 업데이트 된 컨텐츠를 포함하지 않는 에셋 번들은 업데이트를 위해 선택된 빌드의 파일 이름과 동일한 이름을 사용하여 작성된다. 에셋 번들에 업데이트 된 컨텐츠가 포함된 경우 원래 파일과 공존할 수 있도록 업데이트가 된 컨텐츠를 포함하는 새 에셋 번들이 새로운 파일 이름으로 작성된다. 새 파일 이름을 가진 에셋 번들만 컨텐츠를 호스팅 하는 위치로 복사되어야 한다.
또한 시스템은 변경할 수 없는 컨텐츠에 대한 에셋 번들을 빌드하지만 어드레서블 에셋 항목이 참조하지 않으므로 컨텐츠 호스팅 위치에 업로드할 필요는 없다.
새 플레이어를 빌드하고 컨텐츠를 업데이트 하는 (예: 플레이어 코드, 어드레서블) 빌드 스크립트를 변경해서는 안된다. 애플리케이션에서 예기치 않은 동작이 발생될 수 있다.
런타임 시 컨텐츠 업데이트 확인 (Checking for content updates at runtime)
새로운 어드레서블 컨텐츠 업데이트가 있는지 정기적으로 확인하기 위해 사용자 정의 스크립트를 추가할 수 있다. 다음 함수 호출을 사용하여 업데이트를 시작한다.
public static AsyncOperationHandle<List<string>> CheckForCatalogUpdates(bool autoReleaseHandle = true)
리턴 값의 List<string> 은 수정된 위치 ID 목록이 포함된다. 이 ID를 필터링하여 특정 ID 만 업데이트하거나 완전히 UpdateCatalogs API 로 전달할 수 있다.
새로운 컨텐츠가 있는 경우 업데이트를 수행할 수 있는 버튼을 사용자에게 제공하거나 자동으로 수행할 수 있다. 오래된 에셋이 릴리즈되었는지 확인하는 것은 개발자의 책임이다.
카탈로그 목록은 null이 될 수 있으며, 필요한 경우 다음 스크립트는 업데이트가 필요한 모든 카탈로그를 업데이트한다.
public static AsyncOperationHandle<List<IResourceLocator>> UpdateCatalogs(IEnumerable<string> catalogs = null, bool autoReleaseHandle = true)
리턴 값은 업데이트 된 위치 목록이다.
컨텐츠 업데이트 예 (Content update examples)
이 예제에서 제공된 애플리케이션은 다음 그룹을 인식한다.
| 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 (non-static) |
| |
|
AssetX |
AssetA |
| AssetB |
AssetM |
AssetY |
AssetL |
| AssetC |
AssetN |
AssetZ |
|
참고: 준비 작업은 실제로 Cannot Change Post Release 그룹을 편집하므로 직관적이지 않을 수 있다.그러나 핵심은 시스템이 위의 레이아웃을 빌드하지만 이러한 그룹에 대한 빌드 결과를 버리는 것이다. 따라서 플레이어의 관점에서 다음과 같이 정리된다.
| Local_Static |
| AssetA |
| AssetB |
| AssetC |
Local_Static 번들은 변경할 수 없는 플레이어 장치에 이미 있다. 이 이전 버전 AssetA 는 더 이상 참조되지 않는다. 대신 플레이어 장치에 죽은 데이터로 남아있게 된다.
| Remote_Static |
| AssetL |
| AssetM |
| AssetN |
Remote_Static 번들은 변경되지 않는다. AssetM 이나 AssetN 이 플레이어 장치에 아직 캐시되지 않은 경우 요청 시 다운로드 된다. AssetA 와 같이 이전 버전 AssetN 은 더 이상 참조되지 않는다.
| Remote_NonStatic (old) |
| AssetX |
| AssetY |
| AssetZ |
Remote_NonStatic 번들은 이제 오래되었다. 서버에서 삭제할 수 있으며 이 시점부터는 다운로드 되지 않는다. 캐시가 되더라도 결국 캐시에서 삭제된다. AssetA 와 AssetL 처럼 이전 버전 AssetX 는 더 이상 참조되지 않는다.
| Remote_NonStatic (new) |
| AssetX |
| AssetY |
| AssetZ |
이전 Remote_NonStatic 번들은 해시 파일로 구별되는 새 버전으로 대체된다. 수정된 버전은 AssetX 가 새 번들로 업데이트 된다.
| content_update_group |
| AssetA |
| AssetL |
이전 content_update_group 번들은 전진 참조(referenced moving forward)될 수정된 에셋으로 구성되어 있다.
위의 예는 다음과 같은 의미를 갖는다.
- 변경된 로컬 에셋은 사용자 장치에서 영원히 사용되지 않은 상태로 유지된다.
- 사용자가 비정적(non-static) 번들을 이미 캐시한 경우 변경되지 않은 에셋 (예:
AssetY, AssetZ) 을 포함하여 번들을 다시 다운로드해야 한다. 이상적으로 사용자는 번들을 캐시하지 않았으므로 새로운 Remote_NonStatic 번들을 다운로드하면 된다.
- 사용자가 이미 Static_Remote 번들을 캐시한 경우 업데이트 된 에셋만 다운로드하면 된다. ( 이 경우
AssetL 은 content_update_group 을 통해). 이 경우에는 이상적이다. 사용자가 번들을 캐시하지 않은 경우 수정되지 않은 번들을 통해 content_update_group 을 통해 새로운 AssetL 과 수정되지 않은 Remote_Static 번들을 통해 현재 없어진 AssetL 을 모두 다운로드 해야 한다. 초기 캐시 상태와 상관없이, 어느 시점에 사용자는 장치에 기능이 없는 AssetL 을 갖게 되며, 액세스하지 않아도 무기한으로 캐시된다.