0. 메모리 최적화는 모바일 게임을 만들 때 특히 중요하다. - PC는 실제 메모리 사양보다 더 많이 사용할 수 있다. - 모바일은 게임에 사용할 수 있는 메모리가 실제 사양보다 적다. 1. Asset 중복 유니티는 중복 파일 체크를 하지 않기 때문에 동일한 Asset( font, audio, texture, mesh, 등 )을 여러 폴더에 뒀을 때 메모리를 불필요하게 차지할 수 있다. 2. Asset Bundle Asset Bundle을 사용할 때 Asset 디펜던시로 인해서 하나의 Asset이 중복되어 메모리에 올라갈 수 있다. EX) 하나의 Texture를 공유하는 여러 프리팹을 번들로 만들고 Texture는 번들로 만들지 않으면 Texture가 중복으로 들어가게 된다.( addressables 사..
ScriptableObject는 대량의 데이터를 저장할 수 있는 데이터 컨테이너로 데이터를 저장하고 있기 때문에 변경되지 않는 데이터를 갖는 프리팹의 경우 ScriptableObject를 사용하면 인스턴스화할 때마다 데이터를 중복하여 만들지 않기 때문에 메모리 사용을 줄일 수 있다. MonoBehaviour와 같이 ScriptableObject는 Unity의 Object에서 파생되지만 MonoBehaviour와 달리 GameObject에 연결할 수 없고 에셋으로 저장된다. 편집기에서 사용할 때 데이터 저장은 아무 때나 가능하다. 다만 게임을 플레이하는 중에는 데이터를 저장할 수 없고 저장된 데이터를 사용하는 것만 할 수 있다. 편집기에서 에셋 형태로 ScriptableObject에 저장한 데이터는 세션 ..
1. 중첩 Canvas 1.1 Canvas 안의 요소가 변경되면 Canvas 안의 모든 요소가 갱신된다. 1.2 Canvas가 중첩됐을 때 부모와 자식 Canvas 사이에는 서로 영향을 주지 않는다. (부모 Canvas의 크기가 변경되는 경우는 예외) 위의 두 가지 때문에 변경이 잦은 요소를 중첩된 Canvas 중 자식 Canvas에 두어 별도로 관리하면 성능이 향상될 가능성이 높다. 2. 계층의 깊이를 낮게 유지 UI의 RectTransform은 계층구조로 이루어져 있다. 때문에 계층의 깊이가 깊어질수록 Canvas 갱신 등의 비용이 커진다. 3. Re-parenting 주의 부모를 바꾸는 행위를 할 때 Canvas가 갱신될 가능성이 높기 때문에 자제하는 것이 좋다. 4. Pixel Perfect 사용..
1. LINQ를 사용하지 않는다. LINQ는 사용하기는 쉽지만, 알고리즘을 직접 만들어 사용하는 것보다 일반적으로 더 많은 자원이 필요하다. 2. 최대한 GC가 동작하지 않도록 한다. GC(가비지 컬렉터)는 자동 메모리 관리자로 메모리 할당 및 해제를 관리한다. 자동으로 관리되기 때문에 개발자는 편하지만 동작하게 될 때 많은 자원을 사용하게 된다. GC가 동작하는 시점은 시스템의 메모리가 부족해지거나 관리되는 힙에 허용되는 임계값을 초과하는 경우이다. 즉 사용되지 않는 메모리가 많아질수록 GC가 동작하게 될 여지가 많아지기 때문에 이를 막아야 한다. 3. boxing에 주의한다. boxing이란 int, bool, 등과 같은 값 형식 변수를 참조 형식 변수로 래핑하는 것으로 래핑하게 되면 메모리에 할당되..
Color // 참고2 각 색상 구성요소는 0에서 1 사이의 범위를 갖는 부동 소수점 값이다. Color32 // 참고3 32비트 형식으로 RGBA 색상을 표현한다. 각 색상 구성요소는 0~255 범위의 바이트 값이다. 여기서 Color32가 아닌 Color를 사용하는 것은 별로 권장하지 않는다. 이유는 아래와 같다. 1. float 값으로 색을 조정하는건 불편하다. 2. Color32를 대신 사용하면 색상의 byte-float 변환을 방지하고 임시 메모리를 덜 사용한다. (For performance reasons, consider using colors32 instead. This will avoid byte-to-float conversions in colors, and use less tempor..
Canvas에 TextMeshPro를 추가하고 스크립트로 색상을 변경하려 할 때 색상이 변경되지 않는 문제가 발생했다. 문제가 됐던 부분은 색상을 변경할 때 Color 구조체를 사용했기 때문이었다. Color 구조체 대신 Color32 구조체를 사용하니 문제가 발생하지 않았다. 글을 작성한 후 추가로 확인했을 때 구조체의 문제가 아닌 것을 확인했다. 기존에는 색상의 RGB 값을 검색하여 원하는 색상을 찾아 아래와 같이 코드를 작성했었다. Color color = new Color(255, 0, 0, 255); 하지만 Color 구조체의 경우 Byte 형태가 아닌 float 형으로 데이터를 입력해야 하는데 Byte 형으로 값을 입력하는 것이 문제가 되어 색상이 변경되지 않았던 것이다. * 추가 검색을 하다..
Unity를 다시 시작하거나 빌드할 때 Rect Transforms의 Y가 기존에 저장되어 있던 값과 다른 값으로 변경되는 현상이 발생했다. 해당 현상의 원인을 찾아봤을 때 유니티 버전의 문제였고 현재 사용하고 있는 2022.3.4f1 버전에서 발생하는 현상이었다. 해당 버그는 유니티 버전 2021.3.29f1 및 2022.3.5 f1에서는 고쳐졌다고 한다. 2022.3.7f1 버전에서는 재현되지 않는다는 내용이 있었고 해당 내용을 확인하고 버전을 2022.3.13f1로 업데이트했을 때 재현되지 않고 있다.
Unity에서 오브젝트 풀링(Object Pooling)이란 오브젝트를 미리 만들어 쌓아둔 후 필요할 때 꺼내서 사용하고 다 사용했으면 다시 넣어두는 방식을 뜻한다. 이러한 오브젝트 풀링을 사용하는 이유는 Unity에서 오브젝트를 생성하여 메모리를 할당하고 리소스를 초기화하거나 오브젝트를 파괴하여 가비지(Garbage)가 생기고 이런 가비지가 모여 가비지 컬렉터가 동작함으로 인해서 성능 저하가 발생할 수 있고 이러한 문제를 최대한 배제하여 성능을 높이기 위해서다. 동작 방식을 간단하게 설명하면 최초 오브젝트를 담기 위한 오브젝트 풀을 생성하고 오브젝트 풀에 최소한으로 사용할 오브젝트를 생성하여 담아둔다. 그리고 필요할 때 꺼내어 사용하고 다 사용했을 때는 오브젝트 풀에 넣는다. 만약 오브젝트 풀이 비어있..
코루틴은 주로 프레임, 시간 단위로 반복적으로 수행해야 하는 함수 등이 있거나 HTTP 전송, 에셋 로드, 파일 I/O 완료 등을 기다리는 것과 같이 긴 비동기 작업을 처리해야 하는 경우 코루틴을 사용한다. 코루틴을 사용하게 되면 프로세스가 진행되는 중 코루틴이 프로세스를 중단시키고 Unity에서 일시적으로 제어를 가져와 사용하고 다시 Unity에 제어와 선택적 반환 값을 반환하여 중단된 부분에서 다시 시작하게 된다. 다만 코루틴은 다중 스레드를 사용하는 것과는 다르고 메인 스레드에서 실행된다. 실행 방법 아래는 코루틴 메서드의 기본 구조다. IEnumerator Coroutine() { (1) yield break; (2) } 반환 값은 IEnumerator이여야 하며 반환할 때는 yield 문을 사용..