Handle Activity State Changes

Different events, some user-triggered and some system-triggered, can cause an Activity to transition from one state to another. This document describes some common cases in which such transitions happen, and how to handle those transitions.

몇몇 사용자가 트리거하고 몇몇은 시스템이 트리거하는 다른 이벤트로 인해 액티비티가 한 상태에서 다른 상태로 전환 될 수 있습니다. 이 문서에서는 이런 전환이 발생하는 몇 가지 일반적인 사례와 이런 전환을 처리하는 방법을 설명합니다.

For more information about activity states, see Understand the Activity Lifecycle. To learn about how the ViewModel class can help you manage the activity lifecycle, see Understand the ViewModel Class.

액티비티 상태에 대한 자세한 정보는 Understand the Activity Lifecycle을 참고하세요. ViewModel 클래스가 액티비티 생명주기를 관리하는데 어떤 도움을 주는지 알고 싶다면 Understand the ViewModel Class를 참고하세요.

Configuration change occurs

There are a number of events that can trigger a configuration change. Perhaps the most prominent example is a change between portrait and landscape orientations. Other cases that can cause configuration changes include changes to language or input device.

configuration 변경을 트리거 할 수 있는 많은 이벤트가 있습니다. 아마 가장 눈에 띄는 예시는 세로 방향과 가로 방향의 변화 일 것 입니다. configuration 변경을 유발할 수 있는 다른 경우에는 언어 또는 입력 장치 변경이 있습니다.

When a configuration change occurs, the activity is destroyed and recreated. The original activity instance will have the onPause(), onStop(), and onDestroy() callbacks triggered. A new instance of the activity will be created and have the onCreate(), onStart(), and onResume() callbacks triggered.

configuration 변경이 발생하는 경우, 액티비티는 파괴된 다음 재생성됩니다. 원래 액티비티 인스턴스에는 onPause(), onStop(), onDestroy() 콜백이 트리거됩니다. 새로운 액티비티 인스턴스가 생성되고 onCreate(), onStart(), onResume() 콜백이 트리거됩니다.

Use a combination of ViewModels, the onSaveInstanceState() method, and/or persistent local storage to preserve an activity’s UI state across configuration changes. Deciding how to combine these options depends on the complexity of your UI data, use cases for your app, and consideration of speed of retrieval versus memory usage. For more information on saving your activity UI state, see Saving UI States.

ViewModels, onSaveInstanceState() 또는 영구 로컬 저장소의 조합을 사용하여 구성변경시 액티비티의 UI 상태를 보존합니다. 이러한 옵션을 결합하는 방법은 UI 데이터의 복잡성, 앱 사용 사례, 검색 속도, 메모리 사용량의 고려 사항에 따라 결정됩니다. 액티비티 UI 상태 저장에 대한 자세한 내용은 Saving UI States를 참조하세요.

Handling multi-window cases

When an app enters multi-window mode, available in Android 7.0 (API level 24)and higher, the system notifies the currently running activity of a configuration change, thus going through the lifecycle transitions described above. This behavior also occurs if an app already in multi-window mode gets resized. Your activity can handle the configuration change itself, or it can allow the system to destroy the activity and recreate it with the new dimensions.

앱이 Android 7,0 (API 레벨 24) 이상에서 사용할 수 있는 multi-window mode로 전환되면 시스템은 현재 실행중인 액티비티에 configuration 변경을 알리므로 위에서 설명한 생명주기를 거쳐갑니다. 이 동작은 이미 multi-window mode에 있는 앱의 크기가 조정되는 경우에도 발생합니다. 액티비티는 configuration 변경 자체를 처리하거나 시스템이 액티비티를 파괴하고 새 차원으로 다시 생성하도록 허용 할 수 있습니다.

For more information about the multi-window lifecycle, see the Multi-Window Lifecycle section of the Multi-Window Support page.

multi-window mode의 생명주기에 대한 자세한 정보는 Multi-Window Support 페이지의 Multi-Window Lifecycle을 참고

In multi-window mode, although there are two apps that are visible to the user, only the one with which the user is interacting is in the foreground and has focus. That activity is in the Resumed state, while the app in the other window is in the Paused state.

multi-window mode에서는 사용자에게 표시되는 두 개의 앱이 있지만 사용자가 상호 작용하는 앱만 포 그라운드에 있고 포커스가 있습니다. 해당 액티비티는 Resumed 상태이고 다른 앱은 Paused 상태입니다.

When the user switches from app A to app B, the system calls onPause() on app A, and onResume() on app B. It switches between these two methods each time the user toggles between apps.

사용자가 앱 A에서 앱 B로 전환하면, 시스템은 app A에 onPause()를 호출하고 app B에 onResume()을 호출합니다. 사용자가 앱을 전환 할 때마다 두가지 방법간에 전환이 됩니다.

For more detail about multi-windowing, refer to Multi-Window Support.

multi-windowing에 대한 자세한 사항은 Multi-Window Support를 참고.

Activity or dialog appears in foreground

If a new activity or dialog appears in the foreground, taking focus and partially covering the activity in progress, the covered activity loses focus and enters the Paused state. Then, the system calls onPause() on it.

새 액티비티 또는 다이얼로그가 포그라운드에 나타나서 포커스를 맞추고 진행중인 액티비티를 부분적으로 가리는 경우 가려진 액티비티는 포커스를 잃고 Paused 상태에 들어가게됩니다. 그러면 시스템은 onPause()를 호출합니다.

When the covered activity returns to the foreground and regains focus, it calls onResume().

가려진 액티비티가 포 그라운드에 리턴되어 포커스를 다시 가져오면 onResume()을 호출합니다.

If a new activity or dialog appears in the foreground, taking focus and completely covering the activity in progress, the covered activity loses focus and enters the Stopped state. The system then, in rapid succession, calls onPause() and onStop().

새로운 액티비티나 다이얼로그가 포그라운드에 나타나 포커스를 맞추고 진행중인 액티비티를 완전히 덮으면 액티비티가 포커스를 잃고 Stopped 상태가 됩니다. 그러면 시스템은 연속적으로 onPause() 그리고 onStop()을 호출합니다.

When the same instance of the covered activity comes back to the foreground, the system calls onRestart(), onStart(), and onResume() on the activity. If it is a new instance of the covered activity that comes to the background, the system does not call onRestart(), only calling onStart() and onResume().

가려져있는 액티비티의 같은 인스턴스가 포 그라운드로 돌아오면 시스템은 onRestart(),onStart(),onResume() 순서로 호출 합니다. 백그라운드로 오는 가려져있는 액티비티의 새 인스턴스인 경우 시스템은 onRestart()를 호출하지 않고 onStart()와onResume()만 호출 합니다.

Note: When the user taps the Overview or Home button, the system behaves as if the current activity has been completely covered.

사용자가 Overview 또는 홈 버튼을 탭하면 시스템은 현재 액티비티가 완전히 처리 된 것 처럼 작동합니다.

User taps Back button

If an activity is in the foreground, and the user taps the Back button, the activity transitions through the onPause(), onStop(), and onDestroy() callbacks. In addition to being destroyed, the activity is also removed from the back stack.

액티비티가 포 그라운드에 있고 사용자가 백 버튼을 탭하면, 액티비티는 onPause(),onStop(),onDestroy() 콜백을 통해 전환됩니다. 파괴되는 것 외에도 액티비티는 백 스택에서 제거됩니다.

It is important to note that, by default, the onSaveInstanceState() callback does not fire in this case. This behavior is based on the assumption that the user tapped the Back button with no expectation of returning to the same instance of the activity. However, you can override the onBackPressed() method to implement some custom behavior, for example a "confirm-quit" dialog.

이 경우 기본적으로 onSaveInstanceState() 콜백이 실행되지 않는다는 점에 유의해야합니다. 이 동작은 사용자가 액티비티의 동일한 인스턴스로 돌아갈 것으로 예상하지 않고 백 버튼을 탭했다는 가정을 기반으로 합니다. 하지만 confirm-quit 다이얼로그와 같은 사용자 정의 동작을 구현하기 위해 onBackPressed()를 재 정의 할 수 있습니다.

If you override the onBackPressed() method, we still highly recommend that you invoke super.onBackPressed() from your overridden method. Otherwise the Back button behavior may be jarring to the user.

onBackPressed() 메서드를 오버라이드 하는경우 오버라이드 된 메서드에서 super.onBackPressed()를 호출하는 것이 좋습니다. 그렇지 않으면 백 버튼 동작이 사용자에게 동작 하지 않을 수 있습니다.

System kills app process

If an app is in the background and the system needs to free up additional memory for a foreground app, the background app can be killed by the system to free up more memory. To learn more about how the system decides which processes to destroy, read Activity state and ejection from memory and Processes and Application Lifecycle.

앱이 백그라운드에 있고 시스템이 포 그라운드 앱을 위해 추가 메모리를 확보해야하는 경우 시스템이 백그라운드 앱을 종료하여 더 많은 메모리를 확보 할 수 있습니다. 시스템에서 삭제할 프로세스를 결정하는 벙법에 대해 자세히 알아 보려면 Activity state and ejection from memory 그리고 Processes and Application Lifecycle를 읽어보세요.

To learn how to save your activity UI state when the system kills your app process, see Saving and restoring activity state.

시스템이 앱 프로세스를 종료 할 때 액티비티 UI 상태를 저장하는 방법을 알아 보려면 Saving ad restoring activity state를 참조하세요.