모바일 앱의 Hot Start: 정의, 요인 및 속도 향상 방법

모바일 앱에서 Hot Start란 무엇인가

Hot Start는 앱의 프로세스가 이미 기기의 RAM에 존재하는 시작 시나리오입니다. 사용자가 앱을 최소화한 후 돌아오면 시스템은 새 프로세스를 생성하지 않고 기존 프로세스를 재개합니다. 이 시나리오에서는 OS 로딩, Application 클래스 초기화, 프로세스 생성이 필요하지 않으므로 UI가 화면에 나타날 때까지의 시간이 획기적으로 단축됩니다. Android 문서(2025)에 따르면 Hot Start는 200~500ms만 소요되는 반면, Cold Start는 5초 이상 걸릴 수 있습니다. 속도 차이는 메모리가 제한된 기기에서 특히 두드러지며, 시스템이 백그라운드 앱을 더 자주 언로드합니다.

Hot Start의 주요 특징은 호출되는 라이프사이클 메서드의 최소 집합입니다. Android에서는 Activity.onCreate와 Activity.onStart이고, iOS에서는 applicationDidBecomeActive입니다. Application.onCreate, ContentProvider.onCreate, Activity.onCreate 및 많은 라이브러리 초기화가 순차적으로 호출되는 Cold Start와 달리, Hot Start는 이러한 모든 단계를 건너뜁니다. 개발자는 핫 스타트 중에 특히 어떤 코드가 실행되는지 이해해야 합니다. 핫 스타트 중에는 더 이상 필요하지 않음에도 불구하고 무거운 SDK 초기화, 분석, DI 컨테이너가 Cold Start와 Hot Start 모두에서 반복되는 경우가 많습니다.

Cold Start, Warm Start, Hot Start 비교

세 가지 앱 시작 시나리오는 초기화 깊이에서 차이가 있습니다. Cold Start는 설치 후, 기기 재부팅 후 또는 메모리에서 제거된 후 앱이 처음 시작될 때 발생합니다. 시스템은 새 Linux 프로세스를 만들고, Application 클래스를 로드하고, ContentProvider 인스턴스를 만들고, 라이브러리 초기화를 수행한 다음에야 Activity를 렌더링합니다. 전체 프로세스는 앱 복잡성과 기기 특성에 따라 2~10초가 소요됩니다.

Warm Start는 중간 시나리오입니다. 앱 프로세스는 메모리에 살아 있지만 Activity는 제거되었으며 다시 생성해야 합니다. 이는 예를 들어 화면 회전 시 또는 메모리 부족으로 Activity는 제거되었지만 프로세스는 남아 있는 다른 앱에서 돌아올 때 발생합니다. Warm Start는 Activity.onCreate와 Activity.onStart 호출을 포함하지만 Application.onCreate나 ContentProvider 초기화는 포함하지 않습니다. Warm Start 시간은 500ms에서 2초입니다. Hot Start는 세 가지 중 가장 빠릅니다. Activity가 이미 백 스택에 존재하고, 프로세스가 살아 있으며, 시스템이 단순히 Activity.onRestart, onStart, onResume을 호출합니다. Hot Start 시간은 200~500ms입니다. Warm Start와의 차이점은 Activity가 새로 생성되지 않고 기존 인스턴스에서 복원된다는 점입니다.

Hot Start 중 Android 라이프사이클

Android에서 Hot Start는 사용자가 최근 화면을 통해 또는 최소화된 상태에서 앱 아이콘을 탭하여 앱으로 돌아올 때 트리거됩니다. 시스템은 프로세스가 살아 있는지 확인하고, 살아 있다면 Activity.onRestart, onStart, onResume을 순차적으로 호출합니다. Hot Start 중에는 onCreate 메서드가 호출되지 않습니다. Activity 인스턴스가 이미 메모리에 존재하기 때문입니다. 이는 Activity 제거로 인해 onCreate가 여전히 호출되는 Warm Start와의 중요한 차이점입니다. Google I/O 2019에 따르면 Android의 일반적인 Hot Start 시간은 200~400ms이며, 이 단계에서의 속도 저하는 인지된 시작 시간을 직접적으로 증가시킵니다.

개발자는 UI 초기화 코드, LiveData 구독 또는 RecyclerView 설정이 onCreate뿐만 아니라 onStart나 onResume에서도 수행된다는 점을 종종 간과합니다. Hot Start 중에는 UI가 이미 구성되었음에도 이러한 코드 블록이 다시 실행됩니다. 일회성 초기화(savedInstanceState 확인과 함께 onCreate에서)와 재개 가능한 로직(onStart/onResume)을 분리하는 것이 좋습니다. 예를 들어, 어댑터 설정, 목록 로딩과 같은 무거운 작업은 onRestart 중에 실행되지 않는 블록으로 이동하거나 savedInstanceState를 확인해야 합니다.

시작 유형 추적 예제

다음 Kotlin 코드는 시작 시나리오를 감지하고 시간을 측정하는 간단한 방법을 보여줍니다. launchTimeStamp 변수는 시작 시작 순간을 캡처하고, isColdStart는 콜드 스타트와 핫 스타트의 로직을 분리할 수 있습니다.

class MainActivity : AppCompatActivity() {

    private var launchTimeStamp = 0L
    private var isColdStart = true

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        if (savedInstanceState == null) {
            isColdStart = true
            launchTimeStamp = System.currentTimeMillis()
            // 일회성 초기화
        } else {
            isColdStart = false
            // Hot Start — Activity가 복원됨
        }
    }

    override fun onResume() {
        super.onResume()
        if (isColdStart) {
            val launchTime =
                System.currentTimeMillis() - launchTimeStamp
            Log.d("LaunchTime", "Cold Start: $launchTime ms")
        }
    }
}

핫 시작 중 iOS 라이프사이클

iOS에서 Hot Start는 sceneDidBecomeActive(UIKit) 또는 onAppear(SwiftUI)를 통해 백그라운드에서 앱으로 돌아오는 것에 해당합니다. 앱이 일시 중단 또는 백그라운드 상태였다면 운영 체제는 프로세스를 다시 생성하지 않습니다. 핫 시작 중에는 AppDelegate에서 applicationDidBecomeActive가 호출되지만 applicationDidFinishLaunching은 호출되지 않습니다. 이는 Application.onCreate가 건너뛰어지는 Android와 유사합니다. iOS는 메모리에서 앱을 더 적극적으로 제거합니다. 기기에 RAM이 부족하면 시스템이 백그라운드 앱을 제거할 수 있으며, 다음 시작은 Cold Start가 됩니다. Apple Developer 문서에 따르면 iOS의 평균 Hot Start 시간은 300~600ms입니다.

iOS의 주요 차이점은 Android 의미의 Warm Start에 대한 직접적인 유사체가 없다는 것입니다. iOS에서 앱이 최소화되면 sceneDidEnterBackground가 호출되고, 돌아올 때 sceneWillEnterForeground와 sceneDidBecomeActive가 호출됩니다. 시스템이 장면을 제거하지만 프로세스를 살려두는 경우, 다음 시작은 장면 관점에서는 콜드이지만 프로세스 관점에서는 핫이 됩니다. 개발자는 초기화 코드를 배치할 때 이를 고려해야 합니다. NotificationCenter 구독, UI 업데이트 및 상태 재설정은 viewDidLoad뿐만 아니라 sceneDidBecomeActive에 있어야 합니다.

iOS에서 Hot Start 처리 예제

이 Swift 코드는 핫 시작 횟수를 추적하고 로직을 분리하는 방법을 보여줍니다. foregroundCount 카운터는 백그라운드에서 돌아올 때마다 증가합니다.

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var foregroundCount = 0

    func sceneDidBecomeActive(
        _ scene: UIScene
    ) {
        foregroundCount += 1

        if foregroundCount == 1 {
            // Cold Start — 전체 초기화
            setupSDKs()
        } else {
            // Hot Start — UI 업데이트만
            refreshUI()
        }
    }

    private func refreshUI() {
        // 화면의 데이터 업데이트
    }
}

Hot Start 속도에 영향을 미치는 요인

Hot Start 속도에는 여러 범주의 요인이 영향을 미칩니다. 첫 번째는 onStart 및 onResume 라이프사이클 메서드의 작업량입니다. 개발자가 이러한 메서드에 네트워크 데이터 로딩, JSON 파싱, 어댑터 초기화 또는 무거운 계산을 배치한 경우, 각 블록은 시작 시간에 수십 또는 수백 밀리초를 추가합니다. Android Vitals에 따르면 Hot Start 시간이 800ms를 초과하는 앱은 돌아올 때 최대 20%의 사용자를 잃습니다.

두 번째 범주는 savedInstanceState에서 복원되는 프래그먼트와 뷰입니다. 프래그먼트에 무거운 ViewPager2, WebView 또는 복잡하게 중첩된 계층 구조가 포함된 경우, 복원에 CPU 리소스가 소모됩니다. Google I/O 2023에 따르면 중첩된 ViewGroup마다 Hot Start 중 렌더링 시간에 평균 2~5ms가 추가됩니다. 세 번째 범주는 타사 SDK입니다. 분석 라이브러리, 충돌 보고 도구, A/B 테스트 프레임워크 및 DEX 로더는 백그라운드에서 돌아올 때마다 초기화를 수행할 수 있습니다. 어떤 SDK가 특히 onStart/onResume에서 코드를 실행하는지 확인하고 중요하지 않은 작업을 백그라운드 스레드로 지연하는 것이 좋습니다.

핫 시작 최적화 방법

Hot Start 최적화는 재개 라이프사이클 메서드의 작업을 최소화하는 것으로 귀결됩니다. 첫 번째 방법은 지연 초기화입니다. 첫 번째 UI 프레임에 필요하지 않은 코드는 onResume 후에 Handler.postDelayed 또는 Coroutine.launch(Dispatchers.IO)를 통해 지연 실행되어야 합니다. 두 번째 방법은 뷰 상태 캐싱입니다. 앱이 최소화되면 데이터를 인메모리 캐시에 저장하여 Hot Start 중에 데이터베이스나 네트워크에서 다시 로드할 필요가 없도록 합니다. 세 번째 방법은 Android에서 SavedStateHandle과 iOS에서 StateRestorationPolicy를 사용하여 복원되는 데이터 양을 최소화하는 것입니다.

Hot Start 후 지연 로딩

이 예제에서 Handler.postDelayed는 첫 번째 프레임 렌더링 후 500ms 후에 분석 초기화를 지연시킵니다. 사용자가 이미 인터페이스를 보고 있으므로 인지된 시작 시간에 영향을 미치지 않습니다.

class AnalyticsDeferrer {

    fun lazyInitAfterHotStart() {
        val handler = Handler(Looper.getMainLooper())
        handler.postDelayed({
            // 첫 번째 프레임 후 초기화
            Analytics.init(Application.getInstance())
            CrashReporter.start()
        }, 500)
    }
}

App Startup 라이브러리 사용

AndroidX App Startup을 사용하면 시작 시 구성 요소의 초기화 순서를 제어할 수 있습니다. 모든 ContentProvider는 Cold Start 중에 자동으로 초기화되지만, Hot Start 중에 필요하지 않은 구성 요소의 자동 초기화를 비활성화할 수 있습니다.

@Initializer(Application::class)
class SdkInitializer : Initializer<Unit> {

    override fun create(context: Context) {
        SdkOne.init(context)
        SdkTwo.init(context)
    }

    override fun dependencies() = emptyList<Class<*>>()
}

시작 시간 모니터링 도구

Hot Start 시간을 측정하기 위해 플랫폼 내장 도구와 타사 솔루션이 모두 있습니다. Android에서 주요 도구는 Google Play Console의 Android Vitals입니다. 기기 모델 및 OS 버전별로 분류된 모든 시나리오(Cold, Warm, Hot)의 시작 시간 메트릭을 자동으로 수집합니다. 추가로 AndroidX의 Macrobenchmark(자동 시작 성능 테스트 라이브러리)를 사용할 수 있습니다. iOS에서는 이에 해당하는 MetricKit이 시작 시간, 프레임 속도 및 메모리 사용량 데이터를 수집합니다.

상세한 핫 스타트 프로파일링에는 Firebase Performance Monitoring(사용자 지정 추적 추적) 및 시작 시간 대시보드가 있는 New Relic이 적합합니다. 개발자 측에서 수동 측정을 위해 Android의 reportFullyDrawn이 사용됩니다. UI가 렌더링되고 상호 작용할 준비가 된 정확한 순간을 시스템에 알리는 API입니다. iOS에서는 MetricKit의 endActivity가 이에 해당합니다. 이러한 도구를 결합하여 특정 기기에서 어떤 SDK 또는 코드 블록이 Hot Start를 느리게 하는지 식별할 수 있습니다.

Hot Start용 Macrobenchmark 예제

Macrobenchmark 라이브러리를 사용하여 Cold 및 Hot Start를 측정하는 Kotlin 코드입니다. 테스트는 Activity를 시작하고 완료 상태까지의 시간을 측정합니다.

@RunWith(AndroidJUnit4::class)
class StartupBenchmark {

    @get:Rule
    val benchmarkRule = MacrobenchmarkRule()

    @Test
    fun hotStart() {
        benchmarkRule.measureRepeated(
            packageName = "com.example.app",
            metrics = listOf(StartupTimingMetric()),
            iterations = 10,
            startupMode = StartupMode.HOT
        ) {
            pressHome()
            startActivityAndWait()
        }
    }
}