2024 12 20 TIL

기술 면접 예상 질문을 준비하면서 정리한 내용들을 위주로 오늘 TIL을 작성한다. 

 

스택과 힙의 차이

 

스택

 

스택은 정적으로 메모리를 할당받으며 처리가 빠르지만 메모리의 할당에 제한이 있습니다.
스택에 할당한 메모리는 블록이 끝나면 자동으로 스택에서 빠져나갑니다. (자동으로 메모리 관리)
지역변수와 매개변수가 이에 해당하는 예시입니다.

 

힙

힙은 동적으로 메모리를 할당할 때 쓰입니다. 
스택에서 처리하기 힘든 크기를 메모리를 다루기 위해 사용됩니다.
런타임 중 할당되는 메모리는 힙에 할당됩니다.

가비지 컬렉터가 지원되지 않는 툴들은 프로그래머가 직접 할당을 해제해주어야 합니다. (메모리 누수 방지)

 

C#에서는 가비지 컬렉터라는 기능이 있어 자동으로 힙의 메모리를 정리하여 주지만

가비지 컬렉터의 정리는 완벽하진 않으며 어느 순간 한번에 정리를 하여 일시적인 성능저하를 우려해야합니다.

 

결론

이전의 구조체와 클래스의 차이점에서 피드백을 받았던 내용의 연장선으로

스택과 힙의 특성을 고려하여 적절하게 사용함이 필요합니다.

 

또한 항상 가비지 컬렉터를 경계해야합니다.

new 키워드를 사용하여 객체를 너무 많이 생성하게 되면 

게임을 실행하다가도 어느순간 가비지 컬렉터가 게임을 멈춰버릴 위험이 있기에 

저희가 오브젝트풀과 같은 최적화 기법을 찾는 이유기도 합니다.

 

Find메서드를 지양해야하는 이유

 

Find메서드란

 

Find 메서드는 게임 오브젝트의 이름이나 태그 등 고유의 값을 통해
하이어라키 상에 존재하는 게임 오브젝트를 찾아내는 메서드입니다.

지양하는 이유 

1. 성능 문제 : 모든 게임 오브젝트를 탐색하기 떄문에 게임 오브젝트의 양이 많아질수록 성능에 악영향을 줍니다.

2.  안정성 문제 : 찾고자하는 대상의 값(이름,태그)이 변형되면 찾을 수 없는 문제가 생길 수 있습니다.

또한 동일한 값의 여러개의 게임 오브젝트가 있을 경우엔

가져오고자 하는 오브젝트가 아닌 다른 오브젝트가 반환될 가능성이 생깁니다.

 

3. 유지보수 문제 : 남용하여 캡슐화와 단일책임원칙을 지키지 않으면 한번 코드를 수정할 때 

많은 코드를 수정해야할 수 있어 코드의 유지보수가 어려워집니다.

피드백 : 코드유지보수에 안좋다, 여러개의 게임 오브젝트가 있을 경우 문제가 발생

대안

1. 유니티의 인스펙터에 할당해주거나 (직접할당과 코드를 이용한 할당 모두 포함)

2. 적절한 싱글톤을 사용하여 참조할 수 있는 경로를 열어주는 것이 좋습니다.

그렇다면 꼭 쓰지말아야하나

 

정말로 필요한 순간에만 사용하고 왠만하면 런타임 중에는 대안들을 활용하는 것이 좋습니다.

 

필요할 때의 예시로

하이어라키 상에 게임 오브젝트가 많지 않은 실행 전 (컴파일) 단계에서

특정 타입의 객체를 찾아야할 때 (제네릭 싱글톤) 등이 있습니다.

 

 

 

면접 후 피드백 : 

자기소개 => 자신의 기술적인 장점과 경험을 토대로 보완한다.

 

기술 설명 관련 => 

면접에서는 보편적으로 쓰이는 키워드를 통해 설명하고

이후 추가적인 질문이 들어올 때 이해한 바를 말해주는 것이 좋다.

(스택은 정적 메모리 할당 힙은 동적 메모리 할당 등 사람들이 주로 사용하는 표현을 쓰자)

 

가비지컬렉터가 지원되지 않는 경우도 있다. (현재 C#과 자바스크립트가 지원된다고 알고있음)

 

 

주말동안 할 것 

추가할 레퍼런스 퍼즐들을 살펴보고 사운드매니저 추가,    에셋의 코드 분석 등

 

코드가 눈에 익숙해질 때까지 반복하고 숙달해보자