액티비티 라이프사이클 관리하기(Managing the Activity Lifecycle)

액티비티의 라이프사이클을 관리할 때 관련 콜백 메서드를 사용하면 강력하면서도 유연한 어플리케이션을 개발할 수 있다. 액티비티의 라이프사이클은 액티비티와 연계되어 있는 또 다른 액티비티, 태스크, 백스택에 의해 직접적인 영향을 받는다.

액티비티는 기본적으로 다음의 3개 상황에 처할 수 있다.

리줌 상태(Resumed)

이 상태에 있는 액티비티는 화면의 제일 전면에 있으며 사용자의 포커스를 갖고 있다. (이 상황은 종종 "실행 중"이라 일컫어지기도 한다.)

일시 정지 상태(Paused)

다른 액티비티가 화면의 제일 전면에서 포커스를 받고 있지만 해당 이 상태에 있는 액티비티는 여전히 그 일부가 사용자에게 보여지고 있다. 즉, 다른 액티비티의 일부분이 투명하거나 화면 전체를 완전히 메울 정도로 크지 않아서 이 상태에 있는 액티비티의 일부분이 보여지고 있는 상태다. 일시 중지된 액티비티는 완전한 상태로 살아있다.(Activity 객체는 모든 상태와 멤버의 정보 데이터를 보존하며 메모리에 남아 윈도우 매니저에 속하게 된다.) 하지만 메모리가 극도로 부족해지면 시스템에 의해서 강제 종료될 수도 있다.

완전 정지 상태(Stopped)

액티비티가 다른 액티비티로 완전히 가리워진 상태다.(액티비티는 현재 "백그라운드"에 있는 상태다.) 정지된 액티비티는 아직 살아있다. (Activity 객체는 마지막 상태와 멤버들의 정보를 모두 유지한 채 메모리에 남아있다. 하지만 윈도우 매니저에는 속하지 않는다.) 하지만 사용자에게는 더 이상 보여지지 않고 있으며 다른 곳에서 메모리가 필요하게 되면 시스템은 액티비티를 강제종료 시킬 수도 있다.

액티비티가 일시 정지되거나 완전 정지되면 시스템은 액티비티에 종료를 요구하거나 (finish() 메서드를 호출한다.) 그냥 프로세스를 강제 종료시키게 된다. 액티비티가 다시 열리면 (그냥 종료되거나 강제 종료 된 후에) 모든 것을 다시 생성해야 한다.

라이프사이클 콜백함수 구현하기(Implementing the lifecycle callbacks)

이 메서드들은 액티비티의 모든 라이프사이클에 관련되어 있다. 이 메서드들을 구현하게 되면 아래와 같은 액티비티 라이프사이클의 루프를 모니터링 해 볼 수 있다.

액티비티의 전체 라이프타임(entire lifetime)은 onCreate() 호출 시점 이후부터 onDestroy() 호출 시점 이전까지를 말한다. 액티비티는 onCreate() 메서드에서 (레이아웃 정의와 같은) 모든 준비를 완료해야 하며 onDestroy() 메서드에서는 남아 있는 모든 리소스를 해제시켜야 한다. 만일 액티비티에 네트워크로부터 데이터를 다운로드 받는 쓰레드가 동작하도록 되어 있다고 하면 onCreate()에서 쓰레드를 생성하고 onDestroy()에서 정지시켜야 한다.

액티비티의 비저블 라이프타임(visible lifetime)은 onStart() 호출 시점 이후부터 onStop() 호출 시점 이전까지를 말한다. 이 시간동안 사용자는 액티비티를 볼 수 있으며 소통할 수 있다. 예를 들어, 새로운 액티비티가 시작되면 onStop()이 호출되고 해당 액티비티는 더 이상 보여지지 않게 된다. onStart()가 호출될 때부터 onStop()이 호출될 때까지 사용자에게 액티비티를 보여주기 위해 필요한 리소스를 유지시킬 수 있다. 예를 들어, UI에 영향을 줄 만한 변화를 감지하기 위해 onStart()에서 BroadcastReceiver를 등록하고 사용자에게 UI를 더 이상 보여줄 필요가 없어지면 onStop()에서 등록을 해지할 수 있다. 사용자가 액티비티를 "보았다 안보았다"를 반복할 수 있기 때문에 액티비티의 전체 라이프타임 동안 onStart()와 onStop()은 여러 번 반복해서 호출될 수도 있다.

액티비티의 포어그라운드 라이프타임(foreground lifetime)은 onResume() 호출 시점 이후부터 onPause() 호출 시점 이전까지를 말한다. 이 라이프타임에서는 액티비티가 다른 어떤 액티비티보다도 화면의 맨 앞에 위치하게 되며 사용자의 입력을 받을 수 있게 된다. 액티비티는 자주 이 상태에 진입하기도 하고 빠져나가기도 한다. 기기가 슬립모드로 전환되거나 다이얼로그가 앞에 나오는 상황이 되면 액티비티는 이 라이프타임에서 빠져나가게 되며 반대로 슬립모드가 해제되거나 다이얼로그가 사라지면 다시 이 라이프타임으로 진입하게 된다. 이 라이프타임은 다른 라이프타임에 비해 매우 빈번하게 상태 변화가 일어나기 때문에 프로그램이 느려지지 않도록 하려면 onResume()와 onPause()를 매우 간단한 작업만 하도록 구현해야한다.

[그림 1]은 위의 3가지 루프와 액티비티의 상태변화가 어떤 순서로 일어나는지에 대해서 설명하고 있다.

그림 1. 액티비티의 라이프사이클

아래 [표 1]에서는 위 그림에 표시된 콜백 메서드들에 대한 좀 더 상세한 설명과 각 콜백 메서드가 액티비티의 라이프사이클 루프 중 어디에 속하는지 그리고 호출된 후에 액티비티가 강제 종료될 가능성이 있는지에 대해서 설명한다.

표 1. 액티비티 라이프사이클 콜백 메서드 요약

"호출 후 강제종료?"라고 된 열은 말 그대로 시스템이 액티비티를 순간 강제 종료시킬 가능성이 있는지를 나타낸다. 3개 메서드가 "예"라고 표시되어 있다(onPause(), onStop(), onDestroy()). onPause()는 액티비티가 생성된 이후 3개의 메서드 중에서 첫번째 메서드이기 때문에 프로세스가 강제 종료될 때에도 수행이 보장되는 마지막 메서드다. 만일 시스템이 긴급하게 메모리를 확보해야 한다면 나머지 2개의 메서드(onStop(), onDestroy())는 반드시 수행된다고 보장하기는 어렵다. 따라서 사용자가 수정했다던가 하는 중요한 데이터는 onPause()에서 저장해 두어야 한다. 그러나 onPause()에서 보관해야하는 데이터에 대해서는 어느 정도 선별이 필요하다. onPause()가 수행을 종료해야만 다음 액티비티로의 상태 전환이 이루어지기 때문에 과도한 작업을 수행하면 사용자 경험이 느려지게 된다.

"강제 종료" 항목이 "아니오"라고 표시된 메서드들은 수행 중 프로세스가 강제 종료 되지 않도록 보호가 된다. 그래서 액티비티는 onPause()가 리턴되고 onResume()이 호출되기 전까지 강제 종료가 가능한 상태가 되며 onPause()가 다시 호출되고 리턴될 때까지 강제 종료의 대상에서 제외된다.

액티비티 상태 저장하기(Saving activity state)

액티비티 라이프사이클 관리하기(Managing the Acitivity Lifecycle)의 소개 부분에서 액티비티가 일시 정지(pause)되거나 완전 정지(stop)될 때 액티비티의 상태가 유지되는 것에 대해 간략히 언급하였다. 액티비티가 일시 정지되거나 완전 정지되어도 Activity 오브젝트는 여전히 메모리에 로드되어 있는 상태이기 때문에 모든 멤버의 정보나 마지막 상태 정보도 모두 유지된다. 그래서 액티비티가 다시 화면의 맨 앞으로 나오게 되면(resume 될 때) 모든 정보가 그대로 남아있게 된다.

그러나 시스템이 메모리를 확보하기 위해 액티비티를 파괴하게 되면 시스템이 다시 액티비티를 복원(resume)시켜 간단히 원래 상태로 돌아올 수가 없다. 대신에 사용자가 다시 그 액티비티로 돌아가려고 하면 시스템은 액티비티 오브젝트를 다시 생성시킨다. 하지만 사용자는 시스템이 액티비티를 파괴하고 재생성한 일은 알지 못하기 때문에 마지막에 보았던 상태 그대로 유지되어 있을 것으로 생각한다. 이런 상황에서는 onSaveInstanceState()라는 또다른 콜백 메서드를 구현하여 액티비티의 중요한 정보를 유지시킬 수 있다.

시스템은 액비티티가 파괴되기 전에 onSaveInstanceState()를 호출한다. 시스템은 이 메서드를 호출할 때 액티비티의 상태 정보를 저장할 수 있도록 Bundle이라는 것을 넘겨준다. Bundle은 putString()과 putInt()와 같은 메서드(리치크루 : 이 이름의 메서드들 외에 다른 메서드들도 있다.)를 사용하여 이름과 값이 짝을 이루는 형태(name-value pair)로 정보를 저장할 수 있다. 이후에 시스템이 어플리케이션 프로세스를 파괴하고 사용자가 다시 되돌아오는 상황이 발생하면 시스템은 액티비티를 재생성하고 onCreate()와 onRestoreInstanceState()에 Bundle을 넘겨준다. 이 두 개의 메서드를 사용하면 onSaveInstanceState()에서 저장한 상태 정보를 Bundle에서 추출하여 액티비티의 상태를 복구할 수 있다. 만일 복구해야할 정보가 없다면 Bundle은 null값으로 넘어온다(액티비티가 처음 생성될 때 이런 상황이 된다.).

그러나 onSaveInstanceState() 메서드에서 아무런 작업을 하지 않거나 심지어 이 메서드를 구현하지 않아도 Activity 클래스에서 기본적으로 구현해 놓은 onSaveInstanceState()가 일부 액티비티의 상태를 복구해 준다. 구체적으로 설명하자면 레이아웃에 있는 View들이 저장할 필요가 있는 정보를 저장할 수 있도록 각 View의 onSaveInstanceState() 메서드를 호출해 준다. 안드로이드 프레임워크에 있는 거의 대부분의 위젯은 시각적으로 보여지는 내용의 변화는 재생성될 때 다시 복구할 수 있도록 자체적으로 적절한 메서드를 구현하고 있다. 예를 들어, EditText는 사용자가 입력한 텍스트를 저장하며 CheckBox는 체크된 상태를 저장한다. 각 위젯이 이렇게 자동으로 상태를 저장할 수 있도록 하기 위해 해야할 일은 각 위젯에 유니크ID를 부여하는 것이다.(android:id 속성 사용) 위젯이 ID를 갖지 않는다면 시스템은 위젯의 상태를 저장할 수가 없다.

이렇게 액티비티의 상태를 자동으로 저장하도록 기본 onSaveInstanceState() 메서드가 구현되어 있긴 하지만 다른 추가적인 정보를 저장하기 위해서 이 메서드를 오버라이드 해야 할 수도 있다. UI외에도 UI와 연결되어 있는 멤버 변수들은 자동으로 저장되고 복구되지 않기 때문에 직접 onSaveInstanceState() 메서드를 구현해 줘야 한다.

기본적으로 구현되어 있는 onSaveInstanceState() 메서드는 UI의 상태를 저장해주고 있기 때문에 추가정보를 저장하기 위해서 메서드를 오버라이딩하려면 다른 작업을 하기 전에 항상 부모클래스의 onSaveInstanceState()를 먼저 호출해야 한다. 같은 맥락으로 onRestoreInstanceState()를 구현할 때도 부모클래스의 메서드를 먼저 호출해야만 UI의 상태가 복구된다.

여러분이 만든 앱이 상태를 얼마나 잘 복구하는지 확인해 보려면 그냥 기기를 돌려서 화면이 회전되도록 해보면 된다. 화면의 방향이 바뀌면(가로방향에서 세로방향으로 또는 세로방향에서 가로방향으로) 시스템은 다른 방향의 레이아웃에 맞는 대체 자원을 적용시키기 위해서 액티비티를 파괴하고 새로 생성한다. 사용자들은 앱을 사용하면서 화면을 회전시키는 경우가 빈번하기 때문에 이런 상황 하나만으로도 액티비티가 파괴되고 재생성될 때 UI의 상태를 저장하고 복구하는게 얼마나 중요한지 알 수 있다.

설정 변화 핸들링하기(Handling configuration changes)

기기의 설정 일부는 실행 도중에 변경될 수도 있다(화면 방향, 키보드 설정, 언어 등과 같은 설정들). 이런 것들이 변경되면 안드로이드는 실행 중인 액티비티를 재생성하게 된다(시스템은 onDestroy()를 호출하고 바로 onCreate()를 호출한다.). 이렇게 하는 이유는 프로그램 작성자가 제공한 리소스들을 변경된 설정에 맞게 자동으로 다시 적용시키기 위해서다(예를 들어, 가로화면과 세로화면에 맞는 레이아웃을 따로 만들어 두었다면 사용자가 기기를 회전시켰을 때 그에 맞는 레이아웃을 다시 적용시키는 것이다.).

만일 위헤서 설명한 대로 화면의 방향이 바뀌고 그에 따라 액티비티의 상태가 복구될 수 있도록 프로그램을 작성했다면 그 앱은 액티비티의 라이프사이클 도중에 예상치 못한 상황에도 좀 더 유연해지게 된다.

이렇게 재시작되는 상황을 잘 대처하기 위해서는 앞서 설명한대로 onSaveInstanceState()에서 액티비티의 상태를 저장하고 onRestoreInstanceState()(또는 onCreate())에서 복구되도록 하는 것이 최선의 방법이다.

실행 중에 발생하는 설정 변경과 그에 대한 처리 방법에 대해 좀 더 알고 싶다면 Handling Runtime Changes를 참고하기 바란다.

액티비티간 콜백 메서드의 수행 순서(Coordinating activities)

어떤 액티비티가 다른 액티비티를 구동시키면 두 액티비티는 모두 라이프사이클의 상태 변화가 생긴다. 처음 액티비티는 일시정지(pause)된 후에 완전정지(stop)되며 (물론 액티비티가 뒤쪽에서 조금이라도 보이게 되면 안전정지(stop)되지는 않는다.) 반면에 다른 액티비티는 생성(create)이 된다. 이런 경우 이 두 개의 액티비티가 디스크나 다른 곳에 데이터를 저장하여 서로 정보를 공유하는 방식을 사용한다면, 두 번째 액티비티가 생성되기 전에 첫번째 액티비티는 완전하게 정지되지 않는다는 사실을 반드시 알고 있어야 한다. 좀 더 정확히 얘기하면 두번째 액티비티를 생성하는 프로세스와 첫번째 액티비티를 정지하는 프로세스가 겹쳐져서 수행된다는 말이다.

라이프사이클 콜백 메서드의 순서, 특히 같은 프로세스에서 하나의 액티비티가 다른 액티비티를 구동할 때의 순서는 명확하게 정해져 있다. 다음은 액티비티A가 액티비티B를 구동시킬 때의 동작 순서를 나열한 것이다.

1. 액티비티A의 onPause() 메서드가 실행된다.
   
2. 액티비티B의 onCreate(), onStart(), onResume()이 순서대로 실행된다.(액티비티B가 사용자 포커스를 받게 된다.)
   
3. 이제 액티비티A가 화면에서 더 이상 보이지 않게 되면 onStop() 메서드가 실행된다.
   

이러한 라이프사이클 콜백 메서드의 순서를 참고하면 하나의 액티비티에서 다른 액티비티로 정보가 옮겨지는 것을 문제없이 수행할 수 있다. 예를 들어, 다음 액티비티에서 읽어내야 할 데이터를 첫번째 액티비티가 데이터베이스에 써 놓아야 한다면 onStop() 대신에 onPause()에서 데이터베이스 쓰기 작업을 수행해야만 한다.