2020. 8. 6. 18:10ㆍUnity/수업내용
1. UGUI
- Unity Engine에서 공식적으로 지원하는 UI System
- Canvas 단위로 Draw Call이 관리된다.
- 동적 할당이 편하다
- NGUI에 비해 레퍼런스가 부족하다. 잘 몰라서 검색해도 안 나오는 경우가 비교적 많다는 의미이다.
- 아무래도 공식 지원 System이다보니 호환성 부분에서 강점을 가질 수 있다.
2. NGUI
- UGUI가 나오기 전에 사용되던 플러그인. 3rd party library라고 생각하면 편하다.
- UI Root 단위로 관리된다.
- 정적 화면에 최적화가 잘 되어 있다(고 알려졌으나 잘 모르겠음)
- UGUI가 나오기 전부터 사용되어 오던 시스템이기에 참고할 레퍼런스가 많다.
- 호환성 부분에서 UGUI에 점점 밀린다고 한다. legacy System들이 갖는 보편적 한계인 듯 하다.
- 공식 지원 System이 아니고, 호환성 등 여러 단점에도 불구하고, 아직까지 NGUI를 주로 사용하는 게임회사들이 많다고 한다. 아무래도 사용해온 역사가 UGUI에 비해서 길기 때문에 고인물들이 기존에 진행하던 프로젝트는 속도를 위해 익숙한걸 많이 사용해서 그런듯 하다. 그런 경우가 많기 때문에 고정관념으로 추측하는것 뿐이지만...
3. AssetBundle 개념
- 유니티의 에셋들을 묶어 하나로 관리하는 것을 칭함. Sprite의 Atlas를 연상하면 쉽다.
- 분산 처리 방식으로 대규모 요청에 견디기 용이한 강점을 가지고 있다. 흐름은 아래와 같다.
개발자는 Asset들을 묶어서 AssetBundle로 만든 후 FTP Client를 사용하여 외부에 있는 Storage에 저장한다.
Runtime 시 Unity Scene의 Script를 통해 외부 Storage에 저장된 AssetBundle을 Load해서 사용한다.
4. AssetBundle을 사용하는 이유에 대해서
1. 업데이트의 용이성 - (Feat. 버전 관리 규칙)
- 소프트웨어 버전 관리 규칙에 대해서는 정해진 규칙이 딱히 없지만, 가장 보편적인 규칙으로 "유의적 버전"을 예로 들어본다. 버전표기방식은 주.부.수 숫자로 한다. 각각의 설명은 다음과 같다.
주 : Major 버전 넘버다. 기존 버전과 호환되지 않게 API가 변경되면 이 넘버를 올린다.
부 : Minor 버전 넘버다. 기존 버전과 호환되면서 새로운 기능을 추가할 때 이 넘버를 올린다.
수 : Patch 버전 넘버다. 기존 버전과 호환되면서 기능 추가가 없고, 버그를 수정한 경우 이 넘버를 올린다.
- 모바일 기기 내에서 어떤 Application(이하 App으로 서술)의 업데이트가 필요할 때 일반적으로 다음과 같이 두 가지 케이스로 나뉜다.
1) App 실행 시 AppStore로 화면전환 없이 자동으로 App 내에서 업데이트 되고 바로 이어서 실행할 수 있는 경우
2) App 실행 시 AppStore로 화면전환 후 새로 App자체를 받는 경우
1번의 경우 기존 버전과 호환이 되는 업데이트가 이루어진 경우이다. Minor 혹은 Patch가 변경된 경우라고 볼 수 있다.
2번의 경우 기존 버전과 호환이 되지 않는 업데이트, 즉 Major가 변경된 경우라고 볼 수 있다.
(*이 글은 버전 관리 규칙에 대해 기술하는 포스팅이 아니기에 길게 서술하지 않고, 추후에 따로 이 부분에 대해 포스팅할 예정이다.)
- 유니티에서 App을 빌드하게 되면 실행 파일과 내부의 Asset들은 하나로 압축된다. 때문에 이후 수정할 일이 생기면 통째로 다시 빌드하지 않으면 수정 할 수가 없다.
예를 들어, 단순히 계절성 이벤트 아이템의 Asset Design이 변경될 때, 혹은 작은 버그 하나 수정하는것조차 개발자는 해당 Asset부분을 수정한 후 통째로 다시 빌드해서 재배포를 해야 하는 2번 같은 상황이 벌어진다는 것이다.
- 따라서 컨텐츠에 포함되는 Asset들은 전부 묶어서 AssetBundle로 만든 후 별도의 *CDN에 저장한다.
(*CDN은 아래에서 추후 설명할 예정이다.)
그 후 App이 실행된 후 Runtime 단계에서 Unity Scene에 있는 Script를 통해 CDN에 업로드되어있는 AssetBundle을 가져와서 사용하게 된다. 이 경우가 위에서 말한 1번에 해당된다.
- 또한 AssetBundle을 카테고리별로 세분화하여 나뉠수록 업데이트 시 변경되는 AssetBundle의 양이 적어지고, 이는 업데이트의 속도와도 직접적으로 영향을 끼치게 된다.
2. App의 용량 경량화
- Runtime 단계에서 주 컨텐츠를 외부 Storage에서 가져온다는 것은 곧 App의 무게가 AssetBundle을 적용한 만큼 가벼워진다는것을 의미한다.
App Store에서 최대 업로드 용량 제한을 두고 있음에도 고용량의 게임이 유저의 모바일 기기에서 이용될 수 있는 이유를 여기서 찾을 수 있다.
5. CDN
1. CDN의 개념
- CDN이란, 간단히 말해서 위에서 지속적으로 나왔던 외부 Storage와 유저를 연결하는 캐싱 서버(Cache Server)이다.
- 서비스를 하는 개발자가 FTP를 외부 Storage로 사용한다고 했을 때, 여기서 FTP를 Contents Origin Server라고 부른다.(이후 Origin으로 서술)
그리고 여기서 업데이트를 제공받기 위한 사용자를 End User라고 한다.
CDN은 Origin과 End User 사이의 물리적 거리를 줄여 컨텐츠 로드 지연을 최소화하는, 촘촘히 분산된 서버로 이루어진 플랫폼이다. 아무래도 물리적으로 거리가 멀면 데이터 전송에 시간이 훨씬 많이 걸리는 문제도 있을 뿐더러, 수신요청은 여럿인데 송신하는 곳이 Origin 하나라면 Origin의 부담이 너무 크기 때문이다.
때문에 세계 각지에 캐싱 데이터를 보관할 서버를 구축한 후, 요청이 들어오는 곳에서 위치상 가장 가까운 서버에서 해당 요청에 응답하는 시스템을 만든 것이 CDN이라고 할 수 있다.
2. CDN의 사용 이유
CDN을 사용하지 않으면, Origin은 모든 End User의 요청에 일일이 응답해야 하고, 이는 오리진에 막대한 트래픽 부하를 발생시킬 확률을 높이게 된다.
예를 들어 미국의 스트리밍 플랫폼인 넷플릭스의 경우 서비스 제공지역이 전 세계에 해당하는데, CDN이 없다면 Origin 혼자서 트래픽을 전부 감당해야 하므로 국가 하나조차 서비스하기 어려울 것이다. 이러한 점을 보완하기 위해 넷플릭스는 자체 CDN을 구축하고 인프라를 확대하여 세계 시장으로 서비스를 뻗어나가고 있다.
- 위의 예시에서 알 수 있듯 서비스의 범위를 일정 이상 확대하기 위해서는 CDN의 사용이 필수로 들어가게 된다.
단순히 서버의 스펙이 좋으면 커버된다의 문제가 아니라, 지역에 따른 서비스 품질의 형평성 또한 어느정도 맞출 수 있는 좋은 수단이기도 하기 때문이다.
'Unity > 수업내용' 카테고리의 다른 글
| GPGS(Google Play Game Service) 연동 (0) | 2020.08.12 |
|---|---|
| 특정 GameObject의 하위 GameObject / Transform 검색하기 (0) | 2020.08.06 |
| MLAgents - RollerBall (0) | 2020.07.14 |
| Coroutine (0) | 2020.05.29 |
| 쿠키런 점프 Image (0) | 2020.05.28 |