* 유니티에서 매니저를 싱글톤으로 만들었더니 생성된 매니저가 계속 생성되어서 자원을 소모하기도 하고, 그에 대한 방법을 고민해보는 글이다.
0. 문제를 깨닫게 된 계기
* 테스트를 할 때 무조건 StartScene에서부터 시작해야 해서 비효율적이다.
= 그래서 이후에 에디터 프로그래밍에서 테스트할 때 씬에 넣어 놓은 매니저와 테스트 코드를 삭제하는 처리를 할까 고민했지만, 일단 매니저가 무조건 StartScene에서 생성되어 시작하는 것이 문제인 생각이 들었다.
* 프로젝트 확장의 경우에서 생각하면 특정 자원이 계속 소모된다.
= 매니저가 생성된 후 매니저가 계속 CPU와 메모리를 일정 정도씩 소모하고 있으므로 비효율적이다.
1. 싱글톤의 장/단점
장점
- 전역 접근 가능: 싱글톤은 인스턴스가 전역적으로 접근 가능하므로, 여러 씬이나 오브젝트에서 매니저에 쉽게 접근할 수 있습니다.
- 인스턴스 제어 용이: 한 번 생성된 인스턴스가 계속 유지되므로, 필요한 경우 언제든지 동일한 상태를 유지한 매니저에 접근할 수 있습니다. 특히 상태를 공유하거나 데이터를 유지하는 데 유용합니다.
- 간단한 구현: 인스턴스를 하나만 유지하므로 메모리 관리가 쉬워지고, 불필요하게 여러 인스턴스가 생성되는 문제를 방지할 수 있습니다.
단점
- 테스트의 어려움: 싱글톤 패턴은 유닛 테스트나 모킹(Mock) 테스트에서 어려움을 줄 수 있습니다. 전역적으로 접근 가능하다는 점 때문에 테스트 중 매니저의 상태가 고정되거나 다른 테스트에 영향을 미칠 수 있습니다.
- 의존성 증가: 프로젝트가 커질수록 싱글톤 인스턴스에 대한 의존성이 증가하여 코드의 결합도가 높아지고 유지보수가 어려워질 수 있습니다. 싱글톤에 의존하는 객체들이 많을 경우, 해당 객체들을 리팩토링하거나 테스트할 때 문제가 발생할 수 있습니다.
- 생명 주기 관리: 싱글톤 인스턴스는 게임 전반에 걸쳐 계속 유지되므로, 특정 상황에서 인스턴스를 제거하거나 다시 초기화해야 할 경우 복잡한 처리가 필요할 수 있습니다.
- 멀티스레드 환경 문제: Unity에서는 잘 사용되지 않지만, 멀티스레드 환경에서 동기화 문제로 인해 싱글톤 패턴이 안전하지 않을 수 있습니다.