UI 상태 저장 개요

• Activity의 UI 상태를 적시에 보존하고 복원하는 것은 사용자 환경의 중요한 부분
• 사용자는 UI 상태가 동일하게 유지되길 기대하지만, 시스템은 Activity 및 저장된 상태를 폐기
• 사용자 기대치와 시스템 동작 간의 간극을 메우려면 ViewModel 객체, onSaveInstanceState() 메서드 또는 로컬 저장소를 조합하여, 애플리케이션 및 활동 인스턴스 전환 과정에서 UI 상태를 유지해야
• 이러한 옵션을 조합하는 방법은 UI 데이터의 복잡성, 앱 사용 사례 및 메모리 사용량 대비 검색 속도를 고려하여 결정해야 합니다.
• 앱은 UI 상태에 관한 사용자 기대치를 충족하고 매끄럽고 원활한 UI를 제공해야
  = 특히 회전과 같이 자주 발생하는 구성 변경 이후, UI로 데이터를 로드할 때 지연이 발생하지 않도록
• 대부분의 경우 ViewModel과 onSaveInstanceState()를 모두 사용

사용자 기대치 및 시스템 동작

사용자가 UI 상태를 닫는 경우

• 사용자는 다음 동작으로 Activity을 완전히 닫을 수 있습니다.
  • 뒤로 버튼 누르기
  • 개요(최근 사용) 화면에서 Activity 스와이프
  • Activity에서 상위 항목으로 이동
  • 설정 화면에서 앱 종료
  • 일종의 '마무리' 작업 완료(Activity.finish()에 의해 지원됨)
• 사용자가 Activity를 완전히 닫는 경우, 영구적으로 Activity에서 벗어났다고 가정
  = Activity 인스턴스는 내부에 저장된 상태, 그리고 Activity와 관련하여 저장된 인스턴스 상태 기록과 함께 메모리에서 폐기되고 삭제
  = Activity를 다시 열 경우 Activity가 완전히 새로 시작될 것으로 예상
• 완전한 닫기에 관한 몇 가지 예외
  = 브라우저에서 뒤로 버튼을 사용하여 브라우저를 종료하기 전에 보고 있었던 정확한 웹페이지로 되돌아갈 것으로 기대

시스템에서 시작된 UI 상태 닫기

UI 상태를 유지하기 위한 옵션
UI 상태에 관한 사용자 기대치가 기본 시스템 동작과 일치하지 않으면 사용자의 UI 상태를 저장하고 복원하여 시스템에서 시작된 폐기를 사용자가 인식할 수 있도록 해야 합니다.

UI 상태를 유지하기 위한 각각의 옵션은 사용자 환경에 영향을 주는 다음과 같은 측정기준에 따라 다릅니다.

속성들	ViewModel	저장된 인스턴스 상태	영구 저장소
저장소 위치	메모리 내	디스크에 직렬화	디스크 또는 네트워크 내
구성 변경 시에도 유지	예	예	예
시스템에서 시작된 프로세스 중단 시에도 유지	아니요	예	예
사용자의 완전한 활동 닫기/onFinish() 시에도 유지	아니요	아니요	예
데이터 제한	복잡한 객체도 괜찮지만 사용 가능한 메모리에 의해 공간이 제한됨	원시(primitive) 유형 및 문자열과 같은 단순하고 작은 객체만 해당	디스크 공간 또는 네트워크 리소스에서 검색하는 비용/시간에 의해서만 제한됨
읽기/쓰기 시간	빠름(메모리 액세스만)	느림(직렬화/역직렬화 및 디스크 액세스 필요)	느림(디스크 액세스 또는 네트워크 트랜잭션 필요)

ViewModel을 사용하여 구성 변경 처리

• 사용자가 애플리케이션을 사용하는 동안 UI 관련 데이터를 저장 및 관리하는 데 이상적
• UI 데이터에 빠르게 액세스할 수 있다
• 회전이나 창 크기 조절 및 일반적으로 발생하는 기타 구성 변경 시, 네트워크 또는 디스크에서 데이터를 다시 가져오는 것을 피할 수 있다
• 메모리에 데이터를 보관하므로, 디스크 또는 네트워크의 데이터보다 검색 비용이 낮다
• 구성 변경 중에는 메모리에 남아 있으며, 시스템은 구성 변경으로 인한 새 Activity 인스턴스와 ViewModel을 자동으로 연결
• 사용자가 Activity 또는 프래그먼트를 종료할 때 또는 개발자가 finish()를 호출할 때, ViewModel은 시스템에 의해 자동으로 폐기
• 시스템에서 시작된 프로세스 중단 중에 폐기
  = onSaveInstanceState()(또는 기타 일부 디스크 지속성)와 결합하여 ViewModel 객체를 사용해야
  = 시스템이 중단된 이후 뷰 모델이 데이터를 다시 로드할 수 있도록 savedInstanceState에 식별자를 보관해야
• 구성 변경 시 UI 상태를 저장하기 위해 준비한 '메모리 내' 솔루션이 이미 있다면 ViewModel을 사용하지 않아도 됨

onSaveInstanceState()를 백업으로 사용하여 시스템에서 시작된 프로세스 중단 처리

• 시스템이 Activity 또는 프래그먼트와 같은 UI 컨트롤러를 폐기하고 나중에 다시 생성할 때 컨트롤러의 상태를 다시 로드하는 데 필요한 데이터를 저장
• 저장된 인스턴스 상태 번들은 구성 변경 및 프로세스 중단에도 유지되지만, onSavedInstanceState()가 데이터를 디스크에 직렬화하기 때문에 저장용량 및 속도에 의해 제한됨
• 직렬화될 객체가 복잡하면 직렬화 시 많은 메모리가 소비
• 직렬화 프로세스는 구성 변경 시 기본 스레드에서 발생하기 때문에 직렬화가 장기적으로 실행되면 프레임 하락 및 시각적인 끊김 현상이 발생할 수 있음
• 비트맵과 같은 대량의 데이터, 또는 길이가 긴 직렬화나 역직렬화가 필요한 복잡한 데이터 구조를 저장하는 데 onSavedInstanceState()를 사용해서는 안 됨
  = 기본 유형 및 String 같은 단순하고 작은 객체만 저장해야 함
• 대부분의 앱은 onSaveInstanceState()를 구현하여 시스템에서 시작된 프로세스 중단을 처리
• 구성을 변경하는 동안 데이터베이스에서 데이터를 다시 로드하는데 시간을 낭비 않으려면 ViewModel을 계속 사용
  참고: ViewModel의 저장된 상태 모듈을 사용하여 ViewModel 객체의 저장된 상태에 액세스할 권한을 제공할 수 있습니다. 이 저장된 상태는 SavedStateHandle이라는 객체를 통해 액세스할 수 있습니다. Android 수명 주기 인식 구성요소 Codelab에서 사용 방식을 확인할 수 있습니다.

SavedStateRegistry를 사용하여 저장된 상태에 연결

• Fragment 1.1.0 또는 전이 종속 항목인 Activity 1.0.0부터, UI 컨트롤러(Activity 또는 Fragment)가 SavedStateRegistryOwner를 구현하고 컨트롤러에 결합되는 SavedStateRegistry를 제공

• SavedStateRegistry를 사용하면, 저장된 UI 컨트롤러의 상태와 구성요소가 연결되어 소비하거나 기여할 수 있음
  = 저장된 ViewModel의 상태 모듈은 SavedStateRegistry를 사용하여 SavedStateHandle를 만들어 ViewModel 객체에 제공
  = getSavedStateRegistry()를 호출하여 UI 컨트롤러 내에서 SavedStateRegistry를 검색할 수 있음

• 저장된 상태에 기여하는 구성요소는 saveState()라는 단일 메서드를 정의하는 SavedStateRegistry.SavedStateProvider를 구현해야 함

• saveState() 메서드를 통해 구성요소가 자체에서 저장되어야 하는 상태가 포함된 Bundle을 반환할 수 있음.

• SavedStateRegistry는 UI 컨트롤러의 수명 주기의 상태 저장 단계에서 이 메서드를 호출합니다

• SavedStateProvider를 등록하려면 SavedStateRegistry에서 registerSavedStateProvider()를 호출하여, 제공자의 데이터뿐만 아니라 제공자 자체와도 연결할 키를 전달

• 이전에 저장된 제공자 데이터는 SavedStateRegistry에서 consumeRestoredStateForKey()를 호출한 후, 제공자의 데이터와 연결된 키를 전달하는 방법을 통해 저장된 상태에서 검색할 수 있음

• Activity 또는 Fragment 내에서 super.onCreate()를 호출한 후에 onCreate()에 SavedStateProvider를 등록할 수 있음

• 또는 SavedStateRegistryOwner에서 LifecycleObserver를 설정하여 LifecycleOwner를 구현하고 ON_CREATE 이벤트 발생 시 SavedStateProvider를 등록할 수 있음

• LifecycleObserver를 사용하면 SavedStateRegistryOwner 자체에서 이전에 저장된 상태의 등록 및 검색을 분리할 수 있음

class SearchManager : SavedStateRegistry.SavedStateProvider {
    companion object {
        private const val QUERY = "query"
    }
    private val query: String? = null

    ...

    override fun saveState(): Bundle {
        return bundleOf(QUERY to query)
    }
}

class SearchManager(registryOwner: SavedStateRegistryOwner) : SavedStateRegistry.SavedStateProvider {
    companion object {
        private const val PROVIDER = "search_manager"
        private const val QUERY = "query"
    }

    private val query: String? = null

    init {
        // Register a LifecycleObserver for when the Lifecycle hits ON_CREATE
        registryOwner.lifecycle.addObserver(LifecycleEventObserver { _, event ->
            if (event == Lifecycle.Event.ON_CREATE) {
                val registry = registryOwner.savedStateRegistry

                // Register this object for future calls to saveState()
                registry.registerSavedStateProvider(PROVIDER, this)

                // Get the previously saved state and restore it
                val state = registry.consumeRestoredStateForKey(PROVIDER)

                // Apply the previously saved state
                query = state?.getString(QUERY)
            }
        }
    }

    override fun saveState(): Bundle {
        return bundleOf(QUERY to query)
    }

    ...
}

class SearchFragment : Fragment() {
    private var searchManager = SearchManager(this)
    ...
}

참고: SavedStateRegistry는 onSaveInstanceState()와 동일한 Bundle에 데이터를 저장하므로, 동일한 고려사항과 데이터 제한이 적용됩니다.

로컬 지속성을 사용하여 복잡하거나 큰 데이터의 프로세스 중단 처리

• 영구 로컬 저장소(데이터베이스 또는 공유 환경설정)는 애플리케이션이 사용자의 기기에 설치되어 있는 동안(사용자가 앱의 데이터를 삭제하지 않는 한) 유지

• 이러한 로컬 저장소는 시스템에서 시작된 활동 및 애플리케이션 프로세스 중단 시에도 유지되지만 검색하는 데 비용이 많이 듦
  = 데이터를 로컬 저장소에서 메모리로 읽어와야 하기 때문

• 활동을 열고 닫을 때 손실하지 않으려는 모든 데이터를 저장하기 위해, 대개 영구 로컬 저장소는 이미 애플리케이션 아키텍처의 일부일 수 있습니다.

• ViewModel이나 저장된 인스턴스 상태는, 장기 저장소 솔루션이 아니므로 데이터베이스와 같은 로컬 저장소를 대체하지 못합니다.
  = 일시적인 UI 상태를 임시 저장하는 데에만 이러한 메커니즘을 사용하고 다른 앱 데이터에는 영구 저장소를 사용해야

• 로컬 저장소를 활용하여 앱 모델 데이터를 장기적으로(예: 기기 재시작 전체에 걸쳐) 유지하는 방법에 관한 자세한 내용은 앱 아키텍처 가이드를 참고

UI 상태 관리: 분할 및 정복

UI 상태를 효율적으로 저장 및 복원하기 위해 - 데이터 복잡도, 액세스 속도 및 전체 기간의 균형에 따라 사용되는 다양한 유형의 데이터를 저장 등을 고려하여 아래 방식을 섞어 사용

• 로컬 지속성
  : 활동을 열고 닫을 때 손실하지 않으려는 모든 데이터를 저장
  : 예) 오디오 파일 및 메타데이터가 포함된 노래 객체 컬렉션
• ViewModel
  : 관련 UI 컨트롤러를 표시하는 데 필요한 모든 데이터를 메모리에 저장합니다.
  : 예) 최근 검색한 노래 객체 및 최근 검색어
• onSaveInstanceState()
  : 시스템에서 UI 컨트롤러를 중지한 후 다시 생성할 때 액티비티 상태를 손쉽게 다시 로드하는 데 필요한 소량의 데이터를 저장
  : 복잡한 객체는 여기에 저장하지 않고 로컬 저장소에 보존하고 onSaveInstanceState()에 이러한 객체의 고유 ID를 저장
  : 예) 최근 검색어 저장

• 예를 들어 노래 라이브러리를 검색

• 사용자가 노래를 추가하면 ViewModel은 즉시 이 데이터가 로컬에 유지되도록 위임

• 새로 추가된 이 노래가 UI에 표시되어야 하는 경우 노래가 추가되었음을 반영하도록 ViewModel 객체의 데이터도 업데이트

• 이때 기본 스레드에서 모든 데이터베이스 삽입 작업을 진행해야 합니다.

• 사용자가 노래를 검색할 때 데이터베이스에서 로드되어 UI 컨트롤러에 표시될 노래 데이터는 아무리 복잡하더라도 즉시 ViewModel 객체에 저장되어야 함

• 또한 검색어 자체는 ViewModel 객체에 저장되어야 합니다.

• Activity가 백그라운드로 전환되면 시스템은 onSaveInstanceState()를 호출

• 검색어는 onSaveInstanceState() 번들에 저장

• 이 소량의 데이터는 저장하기 쉽습니다. 그리고 이 데이터는 활동을 현재 상태로 되돌리는 데 필요한 모든 정보이기도 합니다.

복잡한 상태 복원: 조각 재조립

사용자가 활동으로 돌아갈 때 활동이 다시 생성되는 시나리오에는 두 가지

• 활동이 시스템에 의해 중지된 후 다시 생성
  = 활동의 쿼리가 onSaveInstanceState() 번들에 저장되어 있으며 이 쿼리를 ViewModel에 전달
  = ViewModel은 캐시된 검색결과가 없음을 확인한 후, 주어진 검색어를 사용하여 검색결과 로드를 위임

• 구성 변경 후 활동이 생성
  = 활동의 쿼리가 onSaveInstanceState() 번들에 저장되어 있으며 ViewModel에 이미 캐시된 검색결과가 저장되어 있음
  = onSaveInstanceState() 번들에서 ViewModel로 쿼리를 전달하면 ViewModel은 필요한 데이터를 이미 로드했으며 데이터베이스를 다시 쿼리할 필요가 없음을 파악

참고: 활동이 처음 생성되면 onSaveInstanceState() 번들에는 데이터가 없으며 ViewModel 객체는 비어 있습니다. ViewModel 객체를 만들 때 빈 쿼리를 전달함으로써 로드할 데이터가 아직 없음을 ViewModel 객체에 알려줄 수 있습니다. 그러면 활동은 빈 상태에서 시작됩니다.