오르카의 아틀리에

The Resource folder

이건 Unity5에서 에셋, 리소스 그리고 리소스 관리에 관한 아티클 스리즈의 세 번째 챕터입니다.


이 챕터에서는 리소스 시스템에 관해 설명합니다. 리소스 시스템은 개발자가 "Resource"라는 이름의 하나 이상의 폴더에 Asset을 저장하고 Resource API를 사용하여 런타임에 이러한 Asset에서 개체를 로드하거나 언로드 합니다..


2.1 Resource System에 대한 모범 사례

쓰지마세요!


이렇게 말하는데에는 몇가지 이유가 있습니다.


1. 리소스 폴더를 사용하면 세분화된 메모리 관리가 더욱 어려워집니다.

2. 리소스 폴더를 부적절하게 사용하면 애플리케이션 시작 시간과 빌드 길이가 증가합니다. (리소스 폴더의 수가 증가함에 따라 이러한 폴더 내의 Asset 관리가 매우 어려워집니다.)

3. 리소스 시스템은 사용자 정의 컨텐츠를 특정 플랫폼으로 제공하는 프로젝트의 기능을 저하시키고, 추가 컨텐츠 업그레이드 가능성을 제거합니다. (AssetBundleVariants는 디바이스 별로 콘텐츠를 조정하기 위한 Unity의 기본 도구입니다.)


2.2. Resource System의 적절한 사용 

좋은 개발 관행을 저해하지 않고 자원 시스템이 도움이 될 수 있는 두가지 사용 사례가 있습니다.


1. 리소스 폴더는 간편하기 때문에 빠른 프로토 타입 제작이 가능한 훌륭한 시스템입니다. 하지만 프로젝트가 전체 프로덕션으로 전환되면 리소스 폴더의 사용이 제거되어야 합니다.

 

2. 리소스 폴더는 다음과 같은 경우 사소한 경우에 유용할 수 있습니다.

- 프로젝트의 수명이 다할 때까지 일반적으로 필요함

- 메모리 집약적이지 않음

- 패치 적용이 쉽지 않거나 플랫폼이나 장치에 따라 달라지지 않음


이 두번째 사례의 예로는 Prefab을 호스팅 하는 데 사용되는 MonobeviourSingletons또는 FacebookAppID와 같은 타사 구성 데이터를 포함하는 ScriptableOjects가 있습니다.


2.3 Resources 직렬화

프로젝트가 생성될 때 "Resource"라는 이름의 모든 폴더에 있는 Assets 및 Object가 단일 연속 파일로 결합됩니다. 이 파일은 AssetBundle과 유사하게 메타 데이터 및 색인 정보도 포함합니다. AssetBundle설명서에 설명되는 이 색인은 지정된 개체의 이름을 적절한 파일 GUID및 로컬 오프셋 ID로 확인하는 데 사용되는 직렬화된 룩업 트리(Serialized Lookup Tree)를 포함합니다. 이 트리는 특정 바이트에서도 사용됩니다.


대부분의 플랫폼에서 Lookup data의 구조는 균형잡힌 탐색 트리(Balanced Search Tree)로 프로그래머라면 알고 있듯이, 이 트리의 복잡도는 O(N*logN)입니다. 이로인해 리소스 폴더의 개체 수가 증가함에 따라 인덱스 로드 시간도 선형 이상으로 더욱 길어집니다. (보라색이 N*logN 그래프)




이 작업은 스킵할 수 없으며 응용 프로그램 시작 시 초기 스플래시 화면이 표시된 상태에서 수행됩니다. 실제로는 리소스 폴더에 포함된 대부분의 개체가 애플리케이션의 첫번째 장면에 로드할 필요가 거의 없음에도 불구하고 10,000개의 자산이 포함된 리소스 시스템을 초기화하면 로우 엔드 모바일 장치에서 몇초 동안 소비됩니다.



요약

무턱대고 리소스폴더에 많은 에셋과 오브젝트를 때려박고 사용하다보면, 리소스 폴더는 직렬화해서 관리하기 때문에 필요하지 않은 타이밍에도 직렬화된 리소스들을 전부 로드해서 사용하게 되고, 이때문에 원치않는 타이밍에 필요없는 리소스도 메모리에 올려 관리하는 비효율성을 보여줄 수 있다.. 거기에 리소스 서치 알고리즘도 N*logN이기 때문에 갯수가 많으면 많을 수록 느려지게된다. 라는 이야기이다.


하지만 또 무턱대고 Resources System이 구리다! 라는 것이 아니라 유용하게 사용할 수 있는 몇가지 상황들이 있으니 잘 걸러서 유용한 부분에서만 사용하고, 자신의 프로젝트 볼륨을 생각해서 최대한 AssetBundle을 사용하는 방향으로 구조를 잡으면 될 것 같다.