구성 변경 처리

일부 기기 구성은 런타임에 변경될 수 있습니다(예: 화면 방향, 키보드 가용성 및 사용자가 다중 창 모드를 활성화할 경우). 그러한 변경이 일어나는 경우 Android는 실행 중인 Activity를 다시 시작합니다(onDestroy()가 호출되고, 그다음에 onCreate()가 호출됨). 재시작 동작은 여러분이 제공한 대체 리소스로 애플리케이션을 자동으로 다시 로드함으로써 새로운 기기 구성에 애플리케이션이 적응하는 것을 돕도록 설계되었습니다(예: 다양한 화면 방향과 크기에 대한 다양한 레이아웃).

재시작을 적절히 처리할 때는 액티비티가 이전 상태로 복원되는 것이 중요합니다. onSaveInstanceState(), ViewModel 객체 및 영구적인 저장소 조합을 사용하여 모든 구성 변경에 걸쳐 액티비티의 UI 상태를 저장하고 복원할 수 있습니다. 액티비티 상태를 저장하는 방법에 대한 자세한 내용은 UI 상태 저장을 참조하세요.

애플리케이션이 애플리케이션 상태를 그대로 유지한 채 스스로 다시 시작할 수 있는지 시험해 보려면, 애플리케이션에서 여러 가지 작업을 수행하는 동안 구성 변경을 실행해보아야 합니다(예를 들어 화면 방향 변경 등). 언제든 애플리케이션이 사용자 데이터나 상태를 손실하지 않고 다시 시작할 수 있어야 합니다. 그래야 구성 변경과 같은 이벤트를 처리할 수 있기 때문입니다. 그렇지 않으면 걸려오는 전화를 받은 사용자가 한참 뒤에 애플리케이션으로 돌아왔을 때 애플리케이션 프로세스가 이미 소멸되어 있을 수도 있습니다. 액티비티 상태를 복원하는 방법을 알아보려면 액티비티 수명 주기를 참조하세요.

하지만 애플리케이션을 다시 시작하고 상당량의 데이터를 복원하면 비용도 많이 들고 미흡한 사용자 환경이 만들어지는 상황에 직면할 수도 있습니다. 그러한 상황이라면 두 가지 다른 옵션이 있습니다.

  1. 구성 변경 중 객체 보존

    구성이 변경되는 중에 액티비티가 다시 시작될 수 있게 허용하되, 액티비티의 새 인스턴스에 상태 저장 객체를 넣습니다.

  2. 구성 변경 직접 처리

    구성 변경을 처리할 때 숨겨진 복잡성이 있기 때문에 직접 구성 변경을 처리하는 것은 권장하지 않습니다. 그러나 선호하는 옵션(onSaveInstanceState(), ViewModels 및 영구적인 저장소)을 사용하여 UI 상태를 보존할 수 없다면 특정 구성 변경 중에는 시스템에서 액티비티를 다시 시작하지 못하도록 차단할 수 있습니다. 구성이 변경될 때 앱에서 콜백을 받으므로 필요에 따라 액티비티를 수동으로 업데이트할 수 있습니다.

구성 변경 중 객체 보존

액티비티를 다시 시작하기 위해 많은 수의 데이터 세트를 복구해야 하는 경우 네트워크 연결을 다시 설정하거나 다른 집약적 작업을 수행한 다음, 완전히 다시 시작하세요. 구성 변경 때문에 사용자 환경이 느려질 수 있습니다. 또한 시스템이 onSaveInstanceState() 콜백을 사용하여 개발자 대신 저장하는 Bundle을 사용하여 액티비티 상태를 완전히 복원하지 못할 수 있습니다. 이는 대형 객체(예: 비트맵)를 담도록 디자인된 것이 아니며 이 안의 데이터는 반드시 직렬화했다가 메인 스레드에서 다시 역직렬화해야 합니다. 이렇게 하면 메모리를 아주 많이 소모할 수 있으며 구성 변경이 느려질 수 있습니다. 이런 경우에는 ViewModel 객체를 사용하여 액티비티의 일부를 다시 초기화하는 부담을 완화할 수 있습니다. ViewModels는 모든 구성 변경에서 보존되므로 UI 데이터를 다시 쿼리할 필요 없이 보관하기에 좋은 위치입니다. 앱에서 ViewModels를 사용하는 방법에 대한 자세한 내용은 ViewModel 가이드를 참조하세요.

구성 변경 직접 처리

애플리케이션이 특정 구성 변경 중에 리소스를 업데이트하지 않아도 되고 그와 동시에 성능 한계가 있어 액티비티를 다시 시작해서는 안 되는 경우, 액티비티가 구성 변경을 알아서 처리한다고 선언하면 됩니다. 이렇게 하면 시스템이 액티비티를 다시 시작하지 않게 할 수 있습니다.

주의: 구성 변경을 직접 처리하면 대체 리소스를 사용하는 것이 훨씬 더 까다로워질 수 있습니다. 시스템이 개발자 대신 자동으로 이를 적용해주지 않기 때문입니다. 이 기법은 구성 변경으로 인한 재시작을 반드시 피해야만 하는 경우 최후의 수단으로서만 고려해야 하며 대부분 애플리케이션에는 권장하지 않습니다.

액티비티가 구성 변경을 직접 처리한다고 선언하려면 매니페스트 파일의 적절한 <activity> 요소를 편집하고, 처리하려는 구성을 나타내는 값이 있는 android:configChanges 특성을 포함하도록 합니다. 사용 가능한 값은 android:configChanges 특성에 대한 문서에 기록되어 있습니다. 가장 많이 사용되는 값은 "orientation", "screenSize", "keyboardHidden"입니다. "orientation" 값은 화면 방향이 변경될 때 다시 시작되지 않도록 합니다. "screenSize" 값도 방향이 변경될 때 앱이 다시 시작되지 않도록 하지만 Android 3.2(API 레벨 13)부터 적용됩니다. 앱에서 구성 변경을 수동으로 처리하고 싶다면 android:configChanges 특성에서 "orientation""screenSize" 값을 선언해야 합니다. "keyboardHidden" 값은 키보드 가용성이 변경되었을 때 앱이 다시 시작하지 못하도록 합니다. 이 특성에는 여러 개의 구성 값을 선언할 수 있습니다. 각각을 파이프 문자 |로 구분하면 됩니다.

예를 들어 다음 매니페스트 코드는 화면 방향 변경과 키보드 가용성 변경을 둘 다 처리하는 액티비티를 선언합니다.

<activity android:name=".MyActivity"
          android:configChanges="orientation|keyboardHidden"
          android:label="@string/app_name">

이제 이러한 구성 중 하나가 변경되어도 MyActivity는 다시 시작하지 않습니다. 그 대신 MyActivityonConfigurationChanged()에 대한 호출을 받습니다. 이 메서드는 Configuration 객체로 전달되며, 이는 새 기기 구성을 나타냅니다. Configuration의 필드를 읽어보면 새 구성을 확인하고 적절히 변경할 수 있습니다. 그러려면 인터페이스에 사용된 리소스를 업데이트하면 됩니다. 이 메서드가 호출되면 액티비티의 Resources 객체가 업데이트되어 새 구성에 기반한 리소스를 반환하며, 따라서 시스템이 액티비티를 다시 시작하지 않아도 UI의 요소를 손쉽게 재설정할 수 있게 됩니다.

예를 들어, 다음의 onConfigurationChanged() 구현은 현재 기기의 방향을 확인합니다.

Kotlin

override fun onConfigurationChanged(newConfig: Configuration) {
    super.onConfigurationChanged(newConfig)

    // Checks the orientation of the screen
    if (newConfig.orientation === Configuration.ORIENTATION_LANDSCAPE) {
        Toast.makeText(this, "landscape", Toast.LENGTH_SHORT).show()
    } else if (newConfig.orientation === Configuration.ORIENTATION_PORTRAIT) {
        Toast.makeText(this, "portrait", Toast.LENGTH_SHORT).show()
    }
}

Java

@Override
public void onConfigurationChanged(Configuration newConfig) {
    super.onConfigurationChanged(newConfig);

    // Checks the orientation of the screen
    if (newConfig.orientation == Configuration.ORIENTATION_LANDSCAPE) {
        Toast.makeText(this, "landscape", Toast.LENGTH_SHORT).show();
    } else if (newConfig.orientation == Configuration.ORIENTATION_PORTRAIT){
        Toast.makeText(this, "portrait", Toast.LENGTH_SHORT).show();
    }
}

Configuration 객체는 변경된 것뿐만 아니라 현재 구성 전체를 나타냅니다. 대부분의 경우 개발자는 구성이 정확히 어떻게 변경되었는지에는 관심이 없고, 처리 중인 구성에 대체 리소스를 제공하는 모든 리소스를 단순히 재할당하기만 하면 됩니다. 예를 들어, 이제 Resources 객체가 업데이트되었으므로 모든 ImageViewsetImageResource()로 재설정할 수 있으며 새 구성에 적합한 리소스(리소스 제공에 설명되어 있음)가 사용됩니다.

Configuration 필드에서 가져온 값이 Configuration 클래스에서 가져온 특정 상수와 일치하는 정수라는 점을 주의 깊게 보세요. 각 필드에 사용해야 하는 상수에 대한 관련 문서는 Configuration 참조 문서에 있는 적절한 필드를 참조하세요.

명심할 점: 액티비티가 직접 구성 변경을 처리한다고 선언하는 경우, 대체를 제공하는 모든 요소에 대해 본인이 직접 책임을 지게 됩니다. 액티비티가 직접 방향 변경을 처리하고 가로 및 세로 방향 사이에서 바뀌어야 하는 이미지가 있는 경우, 각 리소스를 각 요소에 재할당해야 하며 이를 onConfigurationChanged() 중에 수행해야 합니다.

이러한 구성 변경을 기반으로 애플리케이션을 업데이트하지 않아도 되는 경우, 대신 onConfigurationChanged()를 구현하지 않아도 됩니다. 이런 경우, 구성 변경 전에 쓰였던 리소스가 모두 그대로 사용되고 액티비티의 다시 시작만 피한 것이 됩니다. 그러나 애플리케이션은 언제든 종료되고 이전 상태를 그대로 유지한 채 다시 시작될 수 있어야 합니다. 정상적인 액티비티 수명 주기 중에 상태 유지에서 벗어나기 위한 방안으로 이 기법을 고려해서는 안 됩니다. 애플리케이션을 다시 시작할 수밖에 없는 다른 구성 변경이 있을 뿐만 아니라, 사용자가 애플리케이션을 떠나면 해당 사용자가 다시 돌아오기 전에 상태를 소멸되는 등과 같은 이벤트를 처리해야 하기 때문입니다.