이 글은 유니티 튜토리얼을 번역한 글 입니다. 원문은 여기에서 확인하실 수 있습니다.

이 글은 총 5개의 챕터로 구성되며 아래와 같습니다.

  1. [번역] 에셋번들과 리소스에 대한 가이드
  2. [번역] 에셋과 오브젝트, 그리고 직렬화
  3. [번역] RESOURCES 폴더
  4. [번역] 에셋번들 기초
  5. [번역] 에셋번들 사용 패턴




이 글은 [번역] 에셋번들과 리소스에 대한 가이드 시리즈의 세번째 챕터입니다.

이 챕터에서는 Resources 시스템에 대해 이야기합니다. 이는 개발자가 Resources 라는 이름의 하나 이상의 폴더에 에셋을 저장하고, 런타임에 Resources API를 이용해서 오브젝트를 로드하거나 언로드할 수 있는 시스템을 말합니다.

2.1. Resources 시스템의 모범 사례(Best Practices)

이 시스템을 사용하지 마십시오.

이와 같은 강한 추천은 몇 가지 이유 때문에 만들어졌습니다.

  • Resources 폴더를 사용하는 것은 메모리에 대한 세세한 관리를 더 어렵게 만듭니다.
  • Resources 폴더를 부적절하게 사용하게 되면 애플리케이션의 시작 시간과 빌드의 크기를 증가시킵니다.
    • Resources 폴더의 수가 늘어날 수록, 이러한 폴더에 들어있는 에셋을 관리하는 것이 매우 어려워집니다.
  • Resources 시스템은 특정 플랫폼에 커스터마이징 된 컨텐츠를 프로젝트에서 사용할 수 없도록 하고, 점진적인 컨텐츠 업그레이드에 대한 가능성을 없애버립니다.
    • 에셋번들 변형(Variants)은 디바이스마다 컨텐츠를 조절할 수 있는 유니티의 주요 수단입니다.



2.2 Resources 시스템의 적절한 사용

좋은 개발 사례를 해치지 않고 Resources 시스템을 유용하게 사용할 수 있는 2가지 사용 예가 있습니다.

  1. Resources 는 빠른 프로토타이핑과 실험을 할 때에 최고의 시스템입니다. 왜냐하면 간단하고 사용하기 편하기 때문이죠. 하지만, 프로젝트가 최종 제품 단계에 들어가게 되면 Resources 폴더를 사용하지 않을 것을 강력히 추천합니다.
  2. Resources 폴더는 아래의 상황같은 흔한 경우에도 유용합니다.
    • Resources 폴더에 저장되어 있는 컨텐츠가 메모리에 별로 영향을 주지 않는 경우
    • 컨텐츠가 거의 프로젝트 전반적으로 필요한 경우
    • 컨텐츠의 패치가 거의 필요없는 경우
    • 컨텐츠가 플랫폼이나 디바이스에 따라 변경될 필요가 없는 경우


두번째 경우에 대한 예로는 전역으로 사용되는 싱글턴(singleton) MonoBehaviour나 페이스북 App ID같은 써드파티(third-party) 설정 데이터 에셋이 있습니다.

2.3. Resources의 직렬화

"Resources" 폴더에 있는 모든 에셋과 오브젝트는 프로젝트가 빌드될 때 단일 직렬화된 파일로 합쳐지게 됩니다. 이 파일은 또한 에셋번들과 비슷하게 메타데이터(metadata)와 익덱싱 정보도 포함하고 있습니다. 에셋번들 기초 챕터의 에셋번들 안에는 무엇이 있나? 섹션에서 말하고 있듯이, 이 인덱싱 정보는 직렬화된 색인(lookup) 트리(tree)를 포함하는데, 이는 오브젝트의 이름을 가지고 적합한 File GUID와 Local ID를 가져오는데에 쓰입니다. 또한 이 정보는 오브젝트를 직렬화된 파일의 내용에서 특정 바이트 오프셋에 위치시키기 위해 사용됩니다.

색인 자료 구조는 balanced search tree이기 때문에, 생성 시간은 O(N log(N)) 비율로 늘어나고, 여기에서 N은 트리에 익덱싱된 오브젝트의 개수입니다. 이런 생성 시간의 증가 비율은 인덱스의 로딩 시간이 Resources 폴더에 있는 오브젝트 갯수가 증가하는 것보다 더 크게 증가하게 만듭니다.

이런 동작은 넘어갈 수 없고(unskippable) 애플리케이션이 시작될 때 최초 스플래쉬 화면이 나올 때 발생하게 됩니다. 10,000 개의 에셋을 가지고 있는 Resources 시스템을 초기화하는데에 저사양 모바일 디바이스에서 수 초(multiple seconds)가 걸렸는데, Resources 폴더에 있는 오브젝트의 대부분이 애플리케이션의 첫 씬에 로드될 필요가 없었습니다.

+ Recent posts