피드로 돌아가기
Dev.toMobile
원문 읽기
Android 개발자들이 4개 기본 컴포넌트를 진입점(entry point)으로 이해하지 못해 BroadcastReceiver에서 메인 스레드 블로킹, Service에서 API 26+ 무시, ContentProvider 초기화 순서 간과
Day 2/100: The 4 Android Components — What Senior Engineer Get Wrong
AI 요약
Context
Android 개발자는 Activity, Service, BroadcastReceiver, ContentProvider의 용도를 알지만, 각각이 시스템 진입점이라는 본질을 간과한다. 이로 인해 메인 스레드 ANR, 불안정한 백그라운드 작업, 성능 저하가 발생한다.
Technical Solution
- BroadcastReceiver onReceive()에서 직접 작업 금지: 메인 스레드에서 최대 10초 제한이므로 WorkManager에 즉시 위임
- Service 대신 WorkManager 또는 ForegroundService 사용: API 26+ 이상에서 백그라운드 Service는 앱 전환 시 시스템에 의해 즉시 종료됨
- ContentProvider 초기화 순서 이용: 라이브러리는 빈 ContentProvider를 선언하여 Application.onCreate()보다 먼저 초기화 로직 실행
- WorkManager의 Constraints API 활용: setRequiresCharging(true), setRequiredNetworkType(UNMETERED) 등으로 배터리·데이터 비용 제어
- 각 컴포넌트의 생명주기 경계 정확히 인식: 각 진입점은 독립적으로 호출되며 Application 초기화 비용을 매번 발생시킴
Key Takeaway
Android 컴포넌트 선택은 "어느 클래스를 쓸까"가 아니라 "시스템 진입점의 특성, 제약, 신뢰성 메커니즘을 고려하여 어떻게 해제할 것인가"의 문제다.
실천 포인트
Android 백그라운드 작업이 필요한 상황에서 BroadcastReceiver 본문에 무거운 로직을 두지 말 것: onReceive()는 메인 스레드에서 10초 제한이므로, 모든 작업을 WorkManager.enqueue()로 즉시 위임해야 한다. API 26+ 환경에서 일반 Service를 백그라운드 처리에 사용하면 시스템이 앱 전환 직후 강제 종료하므로, 음악 재생 등 사용자 인지 작업은 ForegroundService로, 연기 가능한 작업은 WorkManager로 분리하면 안정성이 확보된다.