0. SVG 렌더링 방식
- 로드 단계
- SVG는 벡터 데이터(XML 형식)를 먼저 메모리에 불러온 뒤, 내부의
<path>, <polygon>, <circle> 등 벡터 명령을 파싱.
- 렌더링 단계
- 화면 크기나 줌 레벨에 맞춰 래스터화(Vector → Pixel 변환)
- 그릴 때마다 Path 계산과 Fill/Stroke 연산을 수행 (CPU/GPU 부하)
- 메모리 관리
- 벡터 데이터 자체는 작고 해상도에 무관
- 하지만 복잡한 Path나 대규모 데이터는 렌더링 시 CPU 점유율 급상승
- 애니메이션/확대축소가 많을 경우 성능 저하 가능
- 대용량 문제
- 고해상도 복잡 SVG(지도, 일러스트 등)는 그릴 때마다 연산량이 커서 프레임 드랍 발생
- 실시간 UI나 스크롤 뷰에서는 특히 부담됨
1. PNG → Bitmap 렌더링 방식
- 로드 단계
- PNG는 압축 이미지이므로, 메모리에 올릴 때 압축 해제 → Bitmap(픽셀 배열) 생성
- 예: 4000×4000 이미지(ARGB_8888) →
4000 × 4000 × 4byte = 64MB 메모리 사용
- 렌더링 단계
- 이미 픽셀 데이터가 메모리에 있으므로 GPU에 바로 전달 → 빠르게 그려짐
- 해상도 고정, 확대 시 픽셀 깨짐(블러 발생)
- 메모리 관리
- 한 번 메모리에 로드하면 재렌더링 부하 거의 없음
- 대신 메모리 점유가 크고, OOM(Out Of Memory) 위험 존재
- 대용량 문제
- 초고해상도 이미지는 메모리에 못 올릴 수 있음
- 메모리 부족 시 GC(가비지 컬렉션) 과다 발생, 앱 성능 저하
요약
- 벡터(GeoJsonLayer) 렌더링
- 메모리에 전체를 올리지 않고, 그릴 때마다 실시간으로 렌더링
- 장점: 메모리 사용 효율적
- 단점: 데이터 용량이 크면 매번 렌더링 과정에서 CPU·GPU 부하 증가 → 성능 저하 가능
- 비트맵 렌더링
- 모든 픽셀 데이터를 메모리에 미리 로드
- 장점: 필요 시 즉시 그릴 수 있어 CPU·GPU 부하 적음
- 단점: 고해상도·대용량 이미지일 경우 메모리 점유율이 높아 Out of Memory(OOM) 위험 존재
V1에서 사용한 geoJsonLayer 렌더링 방식
// geoJson을 vector방식으로 map 에 렌더링하는 방식.
class GeoJsonLayerProvider : GeoJsonProvider {
private val geoJsonLayer = SnapshotStateList<GeoJsonLayer>()
geoJsonLayer.setFeatureStyle()
}
V2에서 사용한 geoJsonTilerProvider 렌더링 방식
// geoJson File을 비트맵으로 변환 후 타일링하는방식.
class GeoJsonTileLayerProvider : GeoJsonProvider {
private val tileProviderState = SnapshotStateList<GeoJsonTileRenderer>()
private val tileOverlayList = mutableListOf<TileOverlay>()
val tileProvider = GeoJsonTileRenderer(context, combinedFeatures, maxZoom)
tileProviderState.add(tileProvider)
tileProvider.clearDiskCache()
val tileOverlay = map.addTileOverlay(
TileOverlayOptions()
.tileProvider(tileProvider)
.fadeIn(false)
.transparency(0.0f)
.zIndex(0f)
)
tileOverlay?.let { tileOverlayList.add(it) } //
}