Jetpack Compose는 선언형 UI 프레임워크로, 기존 View 시스템과는 완전히 다른 방식으로 화면을 그린다. Compose의 렌더링 파이프라인을 이해하면 성능 최적화와 버그 해결이 훨씬 수월해진다. Compose는 크게 세 단계로 화면을 그리는데, Composition, Layout, Drawing 순서로 진행된다. Composition 단계Composition은 UI 트리를 구성하는 첫 번째 단계다. 이 단계에서 Composable 함수들이 실행되면서 UI의 구조가 결정된다.@Composablefun MyScreen() { Column { Text("Hello") Button(onClick = {}) { Text("Click") ..
안드로이드 모니터링 서비스를 개발하면서 시계열 데이터를 시각화할 필요가 생겼다. MPAndroidChart 같은 라이브러리도 있지만, Jetpack Compose 환경에서 View 기반 차트를 사용하면 AndroidView로 감싸야 하는 번거로움이 있었다. 더 중요한 건, 우리 디자인 시스템에 맞는 커스텀한 인터랙션과 스타일이 필요했다는 점이다. 그래서 Canvas API를 활용해 직접 라인 차트를 구현하기로 결정했다. 기술 스택과 핵심 요구사항Jetpack Compose의 Canvas API와 DrawScope를 기반으로 차트를 그리기로 했다. 주요 요구사항은 다음과 같았다.시계열 데이터를 부드러운 라인으로 연결터치 시 해당 지점의 상세 정보를 툴팁으로 표시평균값을 점선으로 표시최대/최소값 자동 표시 ..
Jetpack Compose에서 부수 효과(side-effect)는 선언형 UI와 비동기 작업, 외부 시스템과의 상호작용을 안전하게 연결해주는 핵심 메커니즘이다. Compose의 철학은 상태(state)를 기반으로 UI를 재작성(recomposition)하는 것이지만, 실제 앱에서는 데이터 요청, 리스너 등록, DB 저장, 로그 기록 등 UI 외부에서 발생하는 다양한 효과를 동반해야 컴포넌트간 연결과 자연스러운 UX를 제공한다. Compose에서 Side-effect의 필요성과 주의점Compose는 함수형 패러다임을 지향하나, 앱은 네트워크 통신이나 DB 저장과 같이 상태(state) 외부의 세계에 계속 개입할 필요가 있다.Side-effect를 무계획적으로 사용하면 예기치 않은 recomposition..
모니터링 시스템의 인스턴스 상세 화면을 개발하면서, 동시에 여러 개의 메트릭 API를 호출해야 하는 상황이 있었다. 이 글에서는 그 과정을 실제 코드, 병렬 처리 원리, 그리고 성능 개선 수치와 함께 구체적으로 살펴본다. WHY — 왜 이 최적화를 했는가?문제 상황초기 구현은 아래처럼 완전히 순차적으로 API를 호출했다.val cpuMetrics = getCpuMetricsUseCase(instanceId, targetDate)val memoryMetrics = getMemoryMetricsUseCase(instanceId, targetDate)val networkReceiveMetrics = getNetworkReceiveMetricsUseCase(instanceId, targetDate)val net..
멀티 모듈 프로젝트를 개발하다 보면 각 모듈의 build.gradle.kts 파일에서 동일한 설정이 반복되는 문제에 직면합니다. 예를 들어 compileSdk, minSdk, Compose 설정, Hilt 설정 등이 모든 모듈에서 중복되어 관리 포인트가 늘어나고 일관성을 유지하기 어려워집니다. 이러한 문제를 해결하기 위해 Convention Plugin 패턴을 활용한 build-logic 구조를 도입하면 빌드 설정을 효율적으로 관리할 수 있습니다. build-logic이란?build-logic은 Gradle의 Composite Builds 기능을 활용하여 빌드 로직을 별도의 독립적인 Gradle 프로젝트로 분리한 구조입니다. 기존의 buildSrc 방식과 유사하지만, build-logic은 더 나은 빌드..
Stateful은 컴포저블이 remember 등으로 내부 상태를 보유하는 형태이고, Stateless는 상태를 보유하지 않고 외부에서 값과 이벤트를 주입받는 형태이며, State Hoisting은 상태를 호출자로 올려 Stateless로 만드는 패턴이다. 실제로는 상태를 읽고 쓰는 모든 컴포저블의 최저 공통 조상으로 상태를 끌어올리는 것이 권장되며, UI 논리와 비즈니스 논리에 따라 컴포지션 내부 또는 ViewModel까지 위치가 달라진다. 핵심 개념 정리Stateful: remember/mutableStateOf 등으로 내부에 상태를 저장하는 컴포저블로 재사용성과 테스트 용이성이 낮아질 수 있다.Stateless: 상태를 보유하지 않고 값과 이벤트를 매개변수로 받아 그리기만 하며, 상태 호이스팅으로 쉽..
오늘은 프로젝트에서 구현한 인증 시스템을 깊이 있게 분석해보자. 단순한 토큰 관리를 넘어, 동시성 문제, 메모리 캐시 전략, Race Condition 해결 등 실전에서 마주하는 복잡한 문제들과 그 해결책을 다룬다. AuthDataStore: DataStore의 확장 함수 패턴private fun Preferences.Key.flowIn(store: DataStore) = store.data.map { it[this] }private suspend fun Preferences.Key.saveTo(store: DataStore, value: String) = store.edit { it[this] = value }private suspend fun Preferences.Key.deleteFrom..
Feature-Driven Modularization(피처 중심 모듈화)은 안드로이드 멀티모듈 아키텍처에서 가장 강력하고 실용적인 설계 방식이다. 이번 포스팅에서는 피처 기반 모듈화의 철학부터 실제 구현 방법, 그리고 build-logic과 benchmark 모듈까지 포함한 부분을 공부한 내 나름대로 풀어보자. Feature-Driven Modularization이란?기본 개념과 철학Feature-Driven Modularization은 비즈니스 기능(Feature) 단위로 모듈을 구성하는 설계 방식이다. 전통적인 Layer-based 접근법과는 근본적으로 다른 관점을 제시한다. 전통적 Layer-based 접근법:app/├── data/ # 모든 데이터 로직├── domain/ ..
