일부 사용자에 의해 트리거되고 일부 시스템에 의해 트리거되는 다양한 이벤트로 인해 Activity가 한 상태에서 다른 상태로 전환될 수 있습니다. 이 문서에서는 이러한 전환이 발생하는 일반적인 사례와 전환을 처리하는 방법을 설명합니다.
활동 상태에 관한 자세한 내용은 활동 수명 주기를 참고하세요. ViewModel 클래스가 활동 수명 주기를 관리하는 데 어떻게 도움이 되는지 알아보려면 ViewModel 개요를 참고하세요.
대부분의 활동 변경사항의 경우 활동 수명 주기의 콜백에 직접 응답할 필요가 없습니다. Compose는 상태에서 UI를 재구성하므로 상태가 rememberSaveable 또는 ViewModel과 같은 적절한 위치에 저장되도록 하여 자동 리컴포지션을 활용할 수 있습니다.
구성 변경 발생
구성 변경을 트리거할 수 있는 여러 이벤트가 있습니다. 아마도 가장 눈에 잘 띄는 예는 세로 모드와 가로 모드 간 방향 변경일 것입니다. 구성 변경을 일으킬 수 있는 다른 사례로는 언어 설정 또는 입력 기기 변경이 있습니다.
구성 변경이 발생하면 활동이 제거되고 다시 생성됩니다. 이렇게 하면 원래 활동 인스턴스에서 다음 콜백이 트리거됩니다.
활동의 새 인스턴스가 생성되고 다음 콜백이 트리거됩니다.
Compose에서는 이러한 콜백과 직접 상호작용하는 것이 일반적이지 않습니다. 대신 Lifecycle API를 사용하여 상태 변경을 관찰하세요. Compose에서는 LocalLifecycleOwner.current를 사용하여 현재 수명 주기를 가져오고 관찰자를 추가하여 이벤트에 응답할 수 있습니다.
ViewModel 인스턴스, rememberSaveable 또는 영구 로컬 저장소의 조합을 사용하여 구성 변경 전체에 걸쳐 활동의 UI 상태를 유지합니다.
이러한 옵션을 조합하는 방법은 UI 데이터의 복잡성, 앱 사용 사례, 메모리 사용량 대비 검색 속도를 고려하여 결정해야 합니다. 대부분의 사용 사례에서는 상태를 ViewModel로 호이스팅하고 rememberSaveable를 사용하여 구성 변경과 시스템에서 시작된 프로세스 종료 모두에서 상태가 유지되도록 해야 합니다. 활동 UI 상태 저장에 관한 자세한 내용은 UI 상태 저장을 참고하세요.
구성 변경으로 인해 활동이 다시 생성되면 초기 컴포지션이 처리됩니다. ViewModel 또는 rememberSaveable을 사용하면 새 컴포지션에서 UI 상태가 복원됩니다.
자세한 내용은 Jetpack Compose의 수명 주기 및 상태 및 Jetpack Compose를 참고하세요.
멀티 윈도우 사례 처리
앱이 Android 7.0 (API 수준 24) 이상에서 제공되는 멀티 윈도우 모드로 전환되면 시스템은 실행 중인 활동에 구성 변경을 알립니다. 이에 따라 이전에 설명한 수명 주기 전환을 거치게 됩니다.
이미 멀티 윈도우 모드에 있는 앱의 크기가 조정될 때도 이 동작이 발생합니다. 활동은 구성 변경을 직접 처리하거나 시스템이 활동을 소멸하고 새 측정기준으로 활동을 다시 생성하도록 허용할 수 있습니다.
멀티 윈도우 수명 주기에 관한 자세한 내용은 멀티 윈도우 모드 지원의 멀티 윈도우 수명 주기 설명을 참고하세요.
멀티 윈도우 모드에서는 사용자에게 표시되는 앱이 두 개 있더라도 사용자가 상호작용하고 있는 앱만 포그라운드에 있으며 포커스를 가집니다. 이 활동은 '다시 시작됨' 상태이지만 다른 창의 앱은 '일시중지됨' 상태입니다.
사용자가 앱 A에서 앱 B로 전환할 때 시스템은 앱 A에 onPause을 호출하고 앱 B에 onResume을 호출합니다. 사용자가 앱을 전환할 때마다 두 메서드가 전환됩니다.
멀티 윈도우 모드에 관한 자세한 내용은 멀티 윈도우 모드 지원을 참고하세요.
활동 또는 대화상자가 포그라운드로 나옴
새 활동 또는 대화상자가 포그라운드로 나옴에 따라 포커스를 얻고 진행 중인 활동을 부분적으로 가리면 가려진 활동은 포커스를 잃고 '일시중지됨' 상태로 전환됩니다. 그러면 시스템은 그 활동에 onPause를 호출합니다.
가려진 활동이 포그라운드로 돌아와서 포커스를 다시 얻으면 시스템은 onResume을 호출합니다.
새 활동 또는 대화상자가 포그라운드로 나옴에 따라 포커스를 얻고 진행 중인 활동을 완전히 가리면 가려진 활동은 포커스를 잃고 '중지됨' 상태로 전환됩니다. 그러면 시스템은 onPause 및 onStop을 빠르게 연속적으로 호출합니다.
가려진 활동의 동일한 인스턴스가 포그라운드로 돌아오면 시스템은 활동에 onRestart, onStart, onResume을 호출합니다. 인스턴스가 백그라운드로 전환된 가려진 활동의 새 인스턴스이면 시스템은 onRestart를 호출하지 않고 onStart 및 onResume만 호출합니다.
리컴포지션은 포그라운드에 표시되는 대화상자의 영향을 받지 않습니다. 하지만 흐름 및 애니메이션과 같은 수명 주기에 연결된 부작용은 필요에 따라 작업을 자동으로 일시중지하고 재개하기 위해 수명 주기 인식 API (예: collectAsStateWithLifecycle)를 사용해야 합니다. 자세한 내용은 상태 및 Jetpack Compose를 참고하세요.
사용자가 뒤로를 탭하거나 동작을 실행함
활동이 포그라운드에 있는데 사용자가 뒤로를 탭하거나 제스처를 사용하면 활동은 onPause, onStop, onDestroy 콜백을 거치며 전환됩니다. 활동이 소멸되고 백 스택에서 삭제됩니다.
대부분의 Compose 앱과 같은 단일 활동 앱에서 컴포저블이 탐색 백 스택에서 삭제되면 rememberSaveable은 상태를 유지하지 않습니다. 이는 사용자가 뒤로를 탭할 때 동일한 인스턴스로 돌아올 것으로 예상하지 않으므로 모든 상태가 삭제되기 때문입니다.
사용자에게 앱을 종료할지 확인하는 대화상자를 표시하는 등 맞춤 뒤로 동작을 구현하려면 NavigationEventHandler API를 사용하세요.
시스템이 앱 프로세스를 종료함
앱이 백그라운드에 있는데 시스템이 포그라운드 앱을 위해 메모리를 확보해야 하면 시스템은 백그라운드 앱을 종료할 수 있습니다. 시스템이 앱을 종료할 때 앱에서 onDestroy가 호출된다는 보장은 없습니다.
시스템이 제거할 프로세스를 결정하는 방식에 관해 자세히 알아보려면 활동 상태 및 메모리에서 방출과 프로세스 및 앱 수명 주기를 참고하세요.
시스템이 앱 프로세스를 종료할 때 활동 UI 상태를 저장하는 방법을 알아보려면 임시 UI 상태 저장 및 복원을 참고하세요.