숏컷 코드
text
Manager가 오래 산다고
-> 전역이어야 하는 것은 아님
생성 시점
-> scope 기준
해제 시점
-> owner 기준문법과 예시
manager lifecycle은 편의가 아니라 scope와 owner 기준으로 정한다
매니저는 이름상 오래 살아 보이기 쉽지만, 실제로는 어떤 scope를 대표하는지에 따라 생존 기간이 달라집니다. 앱 전체를 대표하면 app scope, 전투 한 판만 대표하면 battle scope, UI 한 장면만 다루면 scene scope가 더 자연스럽습니다.
text
App Scope
-> SettingsManager
Battle Scope
-> BattleFlowManager
Scene Scope
-> InventoryScreenManager종료 경계는 "누가 dispose를 보장하는가"를 먼저 정해야 한다
종료 시점을 명시하지 않으면 매니저는 대개 살아남습니다. 이벤트 구독, 타이머, 비동기 작업, 캐시를 들고 있는 매니저는 owner가 해제 책임을 갖는지 먼저 정해야 누수와 중복 실행을 막을 수 있습니다.
가장 흔한 실패는 임시 편의 때문에 전부 오래 살게 두는 것이다
처음엔 다시 생성하기 귀찮아서 DontDestroyOnLoad나 global registry에 올려 두기 쉽습니다.
하지만 실제로는 한 씬이나 한 모드에서만 필요한 매니저까지 오래 살게 하면 재진입 버그와 중복 이벤트가 빠르게 쌓입니다.
lifecycle을 정할 때 핵심
| 상황 | 더 자연스러운 선택 |
|---|---|
| 앱 전체에서 공통 설정과 세션을 대표할 때 | app scope |
| 한 모드나 전투 한 판의 흐름만 조정할 때 | mode/battle scope |
| 특정 화면의 입력과 표현만 조정할 때 | scene/view scope |
| 종료 시 unsubscribe, cancel, dispose가 필요할 때 | owner가 shutdown 책임 보장 |
| 재생성 비용보다 누수 위험이 커질 때 | 오래 살리기보다 재조립 선택 |
특이 케이스와 주의할 점
흔한 실패는 manager라는 이름만 보고 전역 객체로 취급하는 것입니다. 실제 scope가 짧은데 생존 기간만 길어지면, 초기화와 종료가 구조를 더 망칩니다.
text
실패 예시
- BattleFlowManager를 전역 singleton으로 유지
- InventoryScreenManager가 화면 종료 뒤에도 이벤트를 계속 구독
결과
- 재진입 시 중복 실행
- 메모리와 상태 누수