반응형
Flutter는 단일스레드 가비지 콜렉션, Android는 메모리 공유 멀티 스레드 GC, iOS는 ARC를 통해 메모리를 관리한다. 자동 해제이지만 리소스가 가장되면 먼저 삭제해야 한다.
🧠 ARC vs GC 구조 요약
ARC (iOS) vs GC (Android / Flutter)
| 의미 | Automatic Reference Counting | Garbage Collection |
| 해제 방식 | 참조 카운트가 0이 되면 즉시 메모리 해제 | 사용되지 않는 객체를 GC가 주기적으로 수거 |
| 언제 작동함? | 객체 참조가 사라지는 즉시 | GC가 스케줄 따라 수시로 작동 (즉시 아님) |
| 누가 관리함? | 컴파일러가 코드에 retain/release 삽입 | 런타임 GC 엔진이 heap을 스캔 |
| 순환참조 방지 | 직접 weak or unowned 사용 | GC가 순환 참조도 스스로 탐지 가능 |
| 프레임/성능 영향 | 참조 해제가 즉시 일어나서 예측 가능성 높음 | GC 타이밍 예측 어려움, stop-the-world 가능성 있음 |
| 스레드 영향 | ARC는 메인/백그라운드 둘 다 작동, 안정적 | GC가 메인 스레드에서 돌면 렉 유발 가능 (Flutter 등) |
❗ 차이점: GC 엔진 구조와 타이밍
Android JVM (ART) vs Dart VM (Flutter)
| GC 알고리즘 | Generational GC + Concurrent GC + Region-based GC | Generational Scavenger + Mark-Sweep |
| GC 시점 | 멀티스레드 기반 → 앱 실행 중 백그라운드에서도 돌 수 있음 | 단일 스레드(UI thread)에서 실행, stop-the-world 발생 가능 |
| 스레드 | Java는 멀티스레드 환경 (GC도 별도 스레드) | Dart는 기본적으로 단일 스레드 모델 |
| GC 타이밍 최적화 | 훨씬 공격적이고 고도화됨 (Android 10 이후 매우 정교함) | 더 단순하지만 프레임 드롭 위험이 있음 (GC가 UI 스레드 차단할 수 있음) |
플랫폼스레드 모델비고
| Android (Java/Kotlin) | 멀티스레드 (JVM 기반) | Handler, Thread, Executor, Coroutine |
| Flutter (Dart) | 단일 스레드 (메인 isolate) + background isolate | spawn해서 병렬 처리 가능, GC는 메인 isolate에서 동작 |
| iOS (Swift/ObjC) | 멀티스레드 (GCD, OperationQueue) | 스레드/큐 생성 자유롭고, UI는 메인 스레드 전용 |
반응형