에셋 임포팅
에셋 데이터는 CPU GPU등의 하드웨어에서 즉시 쓰일 수 있는 포맷일 필요가 있다. 그러나 대부분의 파일 포맷은 저장공간을 최소화하도록 되어있다.(압축) 따라서 유니티는 저장공간에 있는 데이터를 에셋 데이터로 컨버전 한다. 그리고 이렇게 변환된 에셋 데이터는 라이브러리 폴더에 캐싱된다. 이 과정을 에셋 임포팅이라 한다.
문제는?
근데 에셋 임포팅은 오래 걸림. 변경이 많으면 많을수록 더 오래걸린다. 만약 아예 모든 에셋을 임포트 해야 하는 상황이거나 플랫폼을 바꿔야 하는 경우라면 더욱 더 오래걸린다.
그러면 이걸 어떻게 해결할까? 임포트된 에셋 데이터는 라이브러리에 캐싱된다. 따라서 팀내에서 라이브러리 폴더를 공유할 수 있다.
플랫폼 스위칭 같은 경우를 대비하여 플랫폼별로 라이브러리 폴더를 생성해두고, 타겟 플랫폼에 맞춰서 사용해도 된다.
이러면 빠르긴 한데.. 만약 에셋이 변경된다면? 다시 플랫폼별로 변경된 에셋을 임포트 해줘야 한다.
아~ 뭔가 VCS처럼 이런 라이브러리를 버전별로 네트워크에 캐싱하면 더 빠르지 않을까?
Accelerator
Accelerator는 간단히 말해서 임포트된 에셋 데이터를 버전별로 네트워크 저장소에 올려둔 것이라 보면 된다.
(기존에도 캐시 서버라는 게 있긴 한데 아래에서 그 차이점을 설명하겠다.)
Accelerator가 설치된 환경에서 누군가 에셋을 변경했다. 그러고 로컬에서 리임포트를 했다. 그러면 해당 로컬에서 임포트한 데이터를 로컬 Accelerator 서버에 업로드한다. 그 다음 VCS가 CI 서버에 변경사항이 있었다는 콜백을 전달함. 그럼 CI서버에서는 플랫폼별로 빌드를 수행함. 그러는 동안 각 플랫폼별로 임포트된 에셋을 Accelerator에 푸시한다.
자, 이제 나머지 팀원들은 변경된 에셋을 리임포트할 필요가 없다. 그냥 Accelerator에서 땡겨오면 된다.
Accelerator는 디스크 공간만 충분하면 모든 수정본을 그대로 유지한다. 그래서 특정 버전으로 로컬 환경을 바꿔도 리임포트가 일어나지 않는다.
그래서 성능은? 아래 참고된 영상의 사례를 보면 5기가짜리 라이브러리를 생성하는데 3분 40초밖에 걸리지 않는다. 플랫폼 변경은 35초, 15초만에 끝낸다.
캐시 서버와의 차이
요약하자면 위와 같다.
Custom Asset Caching : 만약 커스텀 에셋을 만들었다면 이에 대한 커스텀 에셋 임포터를 작성해줘야만 한다. 기존 캐시서버에서는 이런 커스텀 에셋을 지원하지 않았는데 Accelerator에서는 ScriptedImporter 파라미터에 AllowCaching=true만 지정해주면 됨.
Automatic Disc Storaged Management : 알아서 디스크 용량 관리를 해준다. 용량이 꽉 차면 에셋 데이터를 정리해준다.
Metrics Provision : 각종 지표를 보여줌 (전송된 바이트 등)
Mirroring Multiple Instances : 여러 개의 로컬 Accelerator끼리 데이터 동기화 가능
참고 : https://www.youtube.com/watch?v=0iN9dHz4jLM
'게임엔진 > 유니티' 카테고리의 다른 글
IL2CPP가 Virtual Call과 Boxing을 처리하는 방법 (0) | 2023.11.19 |
---|---|
Update() (0) | 2023.06.04 |
(토막상식) NativeContainer (1) | 2023.05.28 |
(토막상식) 유니티 메모리 (0) | 2023.05.21 |
IL2CPP, MONO, AOT, JIT 여러 줄 정리 (0) | 2022.12.11 |