특강정리 - 디버깅, 프레임 워크 구조

코드가 복잡해지면, 문제가 발생할 가능성이 높아짐

이를 해결해기 위해 디버깅 과정을 거쳐야함

 

중단점

• f9 혹은 디버깅을 하고 싶은 줄의 좌측을 클릭해서 생성
• 실행중 중단점을 만나면 해당 위치에서 코드 중단
• 유니티에서 사용시, 중단점을 찍은뒤, 유니티에 연결을 누르고, 씬 재생
• 중단점을 만났을때, 해당 지점에서 필드에 어떤값이 들어있는지를 확인 할 수 있음

좌측 붉은색 원이 중단점을 찍은 지점

상단 도구모음에서 유니티에 연결을 누르고, 이런식으로 되었을때 씬 실행

호출 스택

• 함수가 참조되었을때, 해당 함수가 어디에서 호출되었는지를 보여줌

조건

• 특정한 상황이 동시에 발생했을때 만 디버깅 하고싶을때 사용 가능
• 중단점에 조건을 걸어서 해당 위치에서 조건을 충족중일때 코드를 중단
• 조건이 있을경우 중단점 원에 + 가 붙음

중단점에 우클릭을 하여 조건 설정 가능

조건 설정이 완료되면 중단점에 + 표시가 추가됨

추가 기능

• f10 - 프로시저 단위 실행 : 해당 코드의 다음 줄 실행(메서드 내용은 단계별 실행 없이 전부실행)
• f11 - 한 단계씩 코드 실행 : 메서드가 있을경우, 메서드의 내부 내용으로 넘어가서 한줄씩 실행

구조 잡기 (프레임 워크, 최적화)

중재자 패턴

• GameManager 는 이름으로 어떤 역할을 하는지 명확히 알 수 없음
• GameManager에 다른 관리 클래스의 객체를 생성하고 이들을 관리하는 클래스로 사용(UIManager, SoundManager 등)

 

중재자 패턴으로 인한 차이점

1. 속도 차이
   • 각 매니저 싱글톤을 개별적으로 초기화 하는것보다 GameManager 클래스 하나를 초기화하고 객체를 생성해주는것이 약간 빠름
   • PoolingManager 처럼 오브젝트 풀을 사용할경우 오브젝트 풀이 필요하지 않은 씬에서도 객체를 생성하게 되어 성능에 악영향을 줌
2. 메모리 차이
   • 개별 싱글톤으로 구현시, 각자 메모리를 잡게됨 → 메모리 파편화 발생
   • 중재자 패턴 사용시, 하나의 스크립트만 메모리를 사용하게됨
   • 큰 메모리를 사용해야하는 상황 발생시, 메모리 파편화가 있을경우 공간 확보를 위해 메모리 정리 과정을 거치게됨, 이 때 프레임 드랍이 발생
3. MonoBehaviour 의 차이 발생
   • 중재자 패턴 사용시, MonoBehaviour 가 없는 클래스로 매니저들의 객체가 생성됨
   • Coroutine 등, MonoBehaviour를 통해 사용하던 메서드들 사용 불가 → GameManager에서 대신 처리해 주어야함

※ 프로파일러를 사용하여, 성능을 비교하고 채택 여부를 결정해야함

 

UI 최적화

• 플랫폼에 따라 최대 프레임을 정해주는것이 좋음
• 프레임이 높을수록, 기기에 부담이 커짐 (프레임이 높을수록 Update 연산을 자주하게됨)
• Game 화면에서 Stats 를통해 현재 프레임 확인 가능

 

스프라이트 최적화

• 스프라이트가 너무 크면, 쓸데없이 용량을 사용하게됨
• 적절한 크기를 찾아서 사용, 스프라이트의 인스펙터에서 MaxSize 를 조절하여 사용

POT 세팅 : 2의 배수로 스프라이트의 크기를 세팅 (4의 배수가 최적화), 이미지 압축이 가능해져 용량을 크게 줄일 수 있음

 

프레임 디버거

• 게임 화면이 그려지는 순서를 볼 수 있음

이미지가 묶여있을경우 화면에 한번에 그려짐

→ 묶여있지 않다면 순서대로 여러번 그리게됨, 성능에 불리함

 

이미지를 SpriteAtlas 로 묶어줄 수 있음, 묶어줄경우 스프라이트를 그릴때 한번에 그리게됨

※ 단, Atlas로 묶인 이미지는 그 중 하나만 불러와도 모든 스프라이트를 불러오게됨, 각자 사용되는 이미지를 묶으면 쓸모없는 이미지를 불러오게되며 역효과 발생