황진호

황진호

공부한걸 요약해서 기록해놓는 블로그

[Android] 상태 관리 #1 AAC-ViewModel

8 분 소요

Android State Management

앱에서 사용자가 화면영역에서 선택하고 보여졌던 상태들은 안드로이드 lifecycle의 변화에 따라 언제든지 사라질 수 있고, 그에 대한 대응을 해주는 것은 사용자 경험 측면에서 중요하다.

예시로 앱의 process는 사용자에 의해 제거될 수 도있지만, 메모리부족, ANR 등의 이유로 시스템에 의해서 강제로 종료될 수도 있다. 특히 백그라운드의 경우 프로세스 우선순위 정책에 의해 언제든지 시스템에 의해 제거될수 있다.

시스템에서 가장 높은 중요도를 갖는 프로세스는 포그라운드이고, Activity 또는 Fragment가 포그라운드 상태를 가지고 보여주며, 처리하는 영역이다.

이때, 앱에서 제공하는 비즈니스에 따라 포그라운드내의 상태를 어느정도 저장하고 복원해주는 처리가 필요하고 구글에서는 3가지 방법을 가이드하고 있다.

  1. AAC-ViewModel 로의 State Holder : configuration change에도 유지 but, process 종료시 유지못함
  2. SavedState api : process 종료에도 유지 but, Bundle을 사용하여 적고 단순한 형태의 데이터에 적합
  3. Local cache : 모든 경우에 유지, 복잡하고 많은 데이터에 적합 but, api 수행의 위 두가지보다 오랜 지연시간이 존재

상황에 따라 위의 세가지들을 적절하게 사용하여 상태를 관리할 수 있고 하나씩 정리해 보자

AAC - ViewModel

먼저 AAC - ViewModel은 MVVM구조에서의 VM과는 역할이 다르다. 이것은 대다수의 개발자들이 아는 상식이고, VM의 경우 MS에서 제시했던 디자인패턴으로 구글에서는 안드로이드에 맞게 설정했으나 개념과 목적자체가 다르다.

AAC-ViewModel의 등장은 configuration change에 따라 activity/fragment의 lifecycle이 destroy ~ create 로 바뀌어 가면서 화면내의 상태를 잃어버리는 문제에 대응하고, 화면과 관련된 UI 로직을 캡슐화 하기 위함이다.

Configuration Change

configuration change는 Locale(언어)변경, 테마변경(다크테마), 화면 회전 등의 이유로 Configuration 객체의 값이 바뀌는 것을 말하고, 그에따라 activity가 재생성 되어 화면의 상태를 잃게 된다.

구글은 이를 대응하기 위해 AAC - ViewModel 을 만들었고, UI State Holder 라고 부른다.

그렇다면 ViewModel은 어째서 구성변경에 영향을 받지 않을까?

ViewModel_Lifecycle

ViewModel의 경우 위의 사진에서 보이듯, Activity의 lifecycle 보다 좀더 큰 범위를 가지고 있어서 구성변경(destory ~ create) 에도 불구하고 instance가 제거 ~ 재생성되지 않고 그렇다고 중복 생성되지도 않는다.

ViewModelProvider & ViewModelStore

ViewModel 인스턴스를 생성하기 위해서 흔히 알듯이 ViewModelProvider라는 ViewModel 생성을 위한 Utility 클래스가 필요하다.

public open class ViewModelProvider
@JvmOverloads
constructor(
    private val store: ViewModelStore,
    private val factory: Factory,
    private val defaultCreationExtras: CreationExtras = CreationExtras.Empty,
) { ''' }

이 클래스의 생성자를 보면 viewModelStore, factory, CreationExtras 가 전달되고 있는데 이러한 여러 인자들을 주입하여 ViewModel 인스턴스를 만들기 쉽게하는 유틸리티 클래스라고 보면 된다. 그리고 이클래스의 get() 메소드로 ViewModel 인스턴스를 생성하여 반환하는데,

 @MainThread
 public open operator fun <T : ViewModel> get(key: String, modelClass: Class<T>): T {
     val viewModel = store[key]
     if (modelClass.isInstance(viewModel)) {
         (factory as? OnRequeryFactory)?.onRequery(viewModel!!)
         return viewModel as T
     } else {
         @Suppress("ControlFlowWithEmptyBody")
         if (viewModel != null) {
         }
     }
     val extras = MutableCreationExtras(defaultCreationExtras)
     extras[VIEW_MODEL_KEY] = key
				
     return try {
         factory.create(modelClass, extras)
     } catch (e: AbstractMethodError) {
         factory.create(modelClass)
     }.also { store.put(key, it) }
 }

가장 첫줄에서 store라는 변수는 ViewModelStore클래스의 인스턴스이고, 이곳에서 key를 전달하여 viewModel 인스턴스를 가져오고 있는데, 이는 ViewModelStore 인스턴스이다.

public class ViewModelStore {

    private final HashMap<String, ViewModel> mMap = new HashMap<>();

    final void put(String key, ViewModel viewModel) {
        ViewModel oldViewModel = mMap.put(key, viewModel);
        if (oldViewModel != null) {
            oldViewModel.onCleared();
        }
    }

    final ViewModel get(String key) {
        return mMap.get(key);
    }

    ''' 생략 '''
}

그 내부를 보면 ViewModelStore안에서 HashMap 자료구조로 key-value 형태로 ViewModel 인스턴스를 관리하고 있다. 즉, ViewModel 인스턴스는 하나만 존재한다는 것이다.

나머지 ViewModelProvider#get() 메소드의 상세한 내용들은 밑에서 다루기로 하고,

public interface ViewModelStoreOwner {
    /**
     * Returns owned {@link ViewModelStore}
     *
     * @return a {@code ViewModelStore}
     */
    @NonNull
    ViewModelStore getViewModelStore();
}


public class ComponentActivity extends androidx.core.app.ComponentActivity implements
        ContextAware,
        LifecycleOwner,
        ViewModelStoreOwner,
        HasDefaultViewModelProviderFactory,
        SavedStateRegistryOwner,
        ''' {
				
    private ViewModelStore mViewModelStore;
				
    @Override
    public ViewModelStore getViewModelStore() {
        if (getApplication() == null) {
            throw new IllegalStateException("Your activity is not yet attached to the "
                    + "Application instance. You can't request ViewModel before onCreate call.");
        }
        ensureViewModelStore();
        return mViewModelStore;
    }

    void ensureViewModelStore() {
        if (mViewModelStore == null) {
            NonConfigurationInstances nc =
                    (NonConfigurationInstances) getLastNonConfigurationInstance();
            if (nc != null) {
                // Restore the ViewModelStore from NonConfigurationInstances
                mViewModelStore = nc.viewModelStore;
            }
            if (mViewModelStore == null) {
                mViewModelStore = new ViewModelStore();
            }
        }
    }

ViewModelStoreOwner는 ViewModelStore를 반환하는 #getViewModelStore() 메소드를 가지는 인터페이스로 이를 구현하는 클래스는 CompoentActivity와 Fragment 이다.

즉, ViewModelStore를 관리하는 책임이 있는 ViewModelStoreOwner 인터페이스를 구현하는 ComponentActivity와 Fragment가 그역할을 담당하고 있으며, ViewModelStore 내에서 HashMap으로 ViewModel 인스턴스를 관리하고 있다는 점으로 보아 우리가 만든 ViewModel 인스턴스는 ComponentActivity 나 Fragment 가 각각 하나씩 들고 있으면서 캐싱해놓고 사용한다는 것을 알수있다.

또한, 이코드로 어떻게 ViewModel 인스턴스가 configuration change에도 유지할수 있으며, 중복생성 되지 않았는가에 대해 알수있었는데, ComponentActivity가 ViewModelStoreOwner에서 추상화한 getViewModelStore()를 구현하여 ViewModelStore 인스턴스를 생성하고 반환하며,

ViewModel 인스턴스를 만들기 위해서는 ViewModelProvider 클래스가 필요하고, 이클래스의 생성자에 필요한 ViewModelStore인스턴스를 CompoentActivity.getViewModelStore()를 통해 가져오고 있다.

그리고 getViewModelStore() 구현체를 보면 static 클래스 인스턴스인 NonConfigurationInstances 로 viewModel 인스턴스를 가져오면서 configuration change에도 불구하고 인스턴스를 재생성하지 않고 유지하여 가져올수 있는것이다.

정리하자면,

  1. ViewModelStoreOwner 의 역할을하는 ComponentActivity가 ViewModelStore 인스턴스를 생성하고 반환하는 getViewModelStore()를 구현한다.
  2. ViewModel 인스턴스를 만들기 위해 필요한 Utility 클래스인 ViewModelProvider에 생성자로 getViewModelStore()의 viewModelStore 인스턴스를 전달한다.
  3. ViewModelStore는 HashMap 구조로 ViewModel 인스턴스들을 Key-Value 형태로 캐싱하고 있다.
  4. getViewModelStore는 configuration change에 따라 activity가 재생성되어도 static 클래스로 유지하는 NonConfigurationInstances의 viewModelStore 인스턴스를 반환하여 재생성하지 않고 인스턴스를 유지할 수 있다.

여기서 중요한 키워드가 한가지 나왔다. activity가 재생성되어도 static 클래스로 인스턴스를 유지하기 위해서는 메모리에서 유지되어야만 한다. 즉, 프로세스가 종료되었을 때는 메모리에서 모두 제거되기 때문에 NonConfigurationInstances를 잃어버리고 ViewModel 로 상태를 유지할 수 없다.

자, 이제 왜 구성변경에 영향을 받지 않는지 확인했으니 ViewModelProvider로 돌아가서 ViewModel 인스턴스를 어떻게 생성하고 제거되고 있는지 살펴보겠다.

ViewModelProvider

public open class ViewModelProvider
@JvmOverloads
constructor(
    private val store: ViewModelStore,
    private val factory: Factory,
    private val defaultCreationExtras: CreationExtras = CreationExtras.Empty,
) { 

    public constructor(
        owner: ViewModelStoreOwner
    ) : this(owner.viewModelStore, defaultFactory(owner), defaultCreationExtras(owner))
		
    public constructor(
	owner: ViewModelStoreOwner, 
	factory: Factory
    ) : this(owner.viewModelStore, factory, defaultCreationExtras(owner))

}

internal fun defaultCreationExtras(owner: ViewModelStoreOwner): CreationExtras {
    return if (owner is HasDefaultViewModelProviderFactory) {
        owner.defaultViewModelCreationExtras
    } else CreationExtras.Empty
}

internal fun defaultFactory(owner: ViewModelStoreOwner): Factory = 
    if (owner is HasDefaultViewModelProviderFactory) 
        owner.defaultViewModelProviderFactory 
    else 
        instance

ViewModel 생성에는 ViewModelStore, ViewModelProvider.Factory, CreationExtras 세가지의 인스턴스가 필요하다.

public abstract class CreationExtras internal constructor() {
    internal val map: MutableMap<Key<*>, Any?> = mutableMapOf()

    public interface Key<T>

    public abstract operator fun <T> get(key: Key<T>): T?

    object Empty : CreationExtras() {
        override fun <T> get(key: Key<T>): T? = null
    }
}

CreationExtras 는 ViewModel 생성에 필요한 application, savedStateRegistryOwner, ViewModelStoreOwner, 그리고 CompoentActivity 가 가지는 Intent의 extras나 Fragment가 transaction으로 전환될 때 전달되는 Bundle Argument 들을 Map 자료구조에 저장해서 가져오는 용도로 사용한다.

팩토리패턴으로 객체 생성을 분리시키고 보니, ViewModel 인스턴스 생성에 필요한 요소들을 파라미터로 넘기기에는 Factory 인스턴스 생성 당시에 그정보들을 모두 가지기 어렵기 때문에 사용한다고 적혀있다.

ViewModelProvider.Factory 는 인터페이스로 우리가 흔히 알고있는 디자인패턴의 생성패턴중 팩토리패턴이 사용되었다.

public interface Factory {
		
    public fun <T : ViewModel> create(modelClass: Class<T>): T {
        throw UnsupportedOperationException(
            "Factory.create(String) is unsupported.  This Factory requires " +
                "`CreationExtras` to be passed into `create` method."
        )
    }

    public fun <T : ViewModel> create(modelClass: Class<T>, extras: CreationExtras): T =
        create(modelClass)

    companion object {
        @JvmStatic
        fun from(vararg initializers: ViewModelInitializer<*>): Factory =
            InitializerViewModelFactory(*initializers)
    }
				
}

factory 인터페이스로 인스턴스의 생성 로직을 분리하고, 이에 대한 구현체들은 총 3가지이다.

  • NewInstanceFactory
  • AndroidViewModelFactory
  • SavedStateViewModelFactory

ViewModel 클래스가 아닌 application을 가지는 AndroidViewModel 클래스를 상속받는다면 AndroidViewModelFactory로 생성되며, AndroidViewModelFactory에서 application이 null 일때 NewInstanceFactory를 통해 생성한다. default로는 SavedStateViewModelFactory로 생성된다.

ViewModelProvider 생성자 세가지 모두 ViewModelStoreOwner 로 부터 가져오는데 위의 내용에서 알았듯이, ComponentActivity가 가지고 있는 ViewModelStore 나 default 값들을 가져온다.

@NonNull
@Override
public ViewModelProvider.Factory getDefaultViewModelProviderFactory() {
    if (mDefaultFactory == null) {
        mDefaultFactory = new SavedStateViewModelFactory(
                getApplication(),
                this,
                getIntent() != null ? getIntent().getExtras() : null);
    }
    return mDefaultFactory;
}

@NonNull
@Override
@CallSuper
public CreationExtras getDefaultViewModelCreationExtras() {
    MutableCreationExtras extras = new MutableCreationExtras();
    if (getApplication() != null) {
        extras.set(ViewModelProvider.AndroidViewModelFactory.APPLICATION_KEY, getApplication());
    }
    extras.set(SavedStateHandleSupport.SAVED_STATE_REGISTRY_OWNER_KEY, this);
    extras.set(SavedStateHandleSupport.VIEW_MODEL_STORE_OWNER_KEY, this);
    if (getIntent() != null && getIntent().getExtras() != null) {
        extras.set(SavedStateHandleSupport.DEFAULT_ARGS_KEY, getIntent().getExtras());
    }
    return extras;
}
		
@MainThread
public inline fun <reified VM : ViewModel> ComponentActivity.viewModels(
   	noinline extrasProducer: (() -> CreationExtras)? = null,
    noinline factoryProducer: (() -> Factory)? = null
): Lazy<VM> {
    val factoryPromise = factoryProducer ?: {
        defaultViewModelProviderFactory
    }

    return ViewModelLazy(
        VM::class,
        { viewModelStore },
        factoryPromise,
        { extrasProducer?.invoke() ?: this.defaultViewModelCreationExtras }
    )
}

getDefaultViewModelProviderFactory() 에서는 SavedStateViewModelFactory인스턴스를 application, savedStateRegistryOwner, intent.extras 로 생성하여 가져오는 모습이고,

getDefaultViewModelCreationExtras() 에서는 새로운 CreationExtras 인스턴스에 application, SavedStateRegistryOwner, ViewModelStoreOwner, Intent.extras 를 넣어 가져오는 모습이다.

여기서 알수있는 사실은 default값들은 모두 savedStateRegistry 에 관여되어 있고 우리가 일반적으로 ViewModel 인스턴스를 by viewModels() 로 생성할 때 상태관리의 2번방법을 사용하고 있다는 점들이다.

다시 돌아가서, ViewModelProvider 인스턴스로 생성자 타임에 3가지 파라미터가 필요했고 ViewModelProvider#get() 메소드를 통해 ViewModel 인스턴스 생성을 보면

 @MainThread
 public open operator fun <T : ViewModel> get(key: String, modelClass: Class<T>): T {
     val viewModel = store[key]
     if (modelClass.isInstance(viewModel)) {
         (factory as? OnRequeryFactory)?.onRequery(viewModel!!)
         return viewModel as T
     } else {
         @Suppress("ControlFlowWithEmptyBody")
         if (viewModel != null) {
         }
     }
     val extras = MutableCreationExtras(defaultCreationExtras)
     extras[VIEW_MODEL_KEY] = key
				
     return try {
         factory.create(modelClass, extras)
     } catch (e: AbstractMethodError) {
         factory.create(modelClass)
     }.also { store.put(key, it) }
 }

get() 메소드 내에서 ViewModelStore 내에 인스턴스가 존재하는지 확인하고 존재하지 않는다면 factory.create() 를 수행해서 ViewModel 인스턴스를 생성하고 ViewModelStore에 저장한뒤 반환하고 있고,

이미 존재한다면 해당 Factory 구현체에 onRequery()에 ViewModel 인스턴스를 넣어 수행시킨뒤 반환한다.

onRequery 메소드의 경우 ViewModelProvider.Factory의 구현체 3가지중에 SavedStateViewModelFactory 만이 이것을 구현하고 있으므로 as? 로 캐스팅했을 때 null이 아니면 onRequry()를 수행시키는 것이다.

해당부분은 다음 챕터에서 설명하며, 그렇다면 ViewModel 인스턴스가 생성되고 나서 제거되는 과정은 어떨까?

ViewModelStore.clear()

public ComponentActivity() {
    Lifecycle lifecycle = getLifecycle();

    if (lifecycle == null) {
        throw new IllegalStateException("getLifecycle() returned null in ComponentActivity's "
                + "constructor. Please make sure you are lazily constructing your Lifecycle "
                + "in the first call to getLifecycle() rather than relying on field "
                + "initialization.");
    }
				
    getLifecycle().addObserver(new LifecycleEventObserver() {
        @Override
        public void onStateChanged(@NonNull LifecycleOwner source,
                @NonNull Lifecycle.Event event) {
            if (event == Lifecycle.Event.ON_DESTROY) {
                mContextAwareHelper.clearAvailableContext();
                if (!isChangingConfigurations()) {
                    getViewModelStore().clear();
                }
                mReportFullyDrawnExecutor.activityDestroyed();
            }
        }
    });
}

ComponentActivity의 생성자 시점에 lifecycleOwner의 구현체이므로 lifecycle을 가져와 ON_DESTROY 이벤트가 수행되는 시점에 getViewModelStore()로 인스턴스를 가져와 clear() 한다.

이때 Activity.isChangingConfigurations() 를 통해 현재 configuration change가 일어났는지 확인하고 그렇지 않은경우에 대해서만 viewmodelstore.clear()를 호출한다는 것을 인지하여야 한다.

public class ViewModelStore {

    private final HashMap<String, ViewModel> mMap = new HashMap<>();
		
    public final void clear() {
        for (ViewModel vm : mMap.values()) {
            vm.clear();
        }
        mMap.clear();
    }
}

그리고 내부에 가지고 있는 ViewModel들을 모두 clear() 호출하여 종료되게 된다.

정리해보자면,

  1. ViewModel 인스턴스를 생성하기 위해서는 ViewModelProvider 클래스가 필요하다.
  2. ViewModelProvider 인스턴스 생성에는 ViewModelStore, ViewModelProvider.Factory, CreationExtras 가 필요하다.
  3. ViewModelStore는 viewModel 인스턴스를 Map 자료구조로 관리
  4. CreationExtras는 ViewModelFactory 인스턴스 생성시점에 필요한 application, ViewModelStore(Owner), intent.extras를 모두 갖기 어렵기 때문에 주입의 편리를 위해 사용
  5. ViewModelProvider.Factory는 팩토리패턴으로 생성 로직을 분리하고, 구현체는 NewInstanceFactory, AndroidViewModelFactory, SavedStateViewModelFactory가 존재
  6. default 프로퍼티들로 savedStateViewModel 인스턴스가 by viewModels() 프로퍼티 델리게이트 패턴으로 생성된다.
  7. activity의 lifecycle이 ON_DESTROYED 이벤트가 수행될 때 ViewModelStore.clear() 로 ViewModel 인스턴스들이 모두 제거된다.

다음 챕터에서는 SavedState api로 상태관리 2번과정이 어떻게 구현되고 있고 어떤목적을 달성하고 있는지 정리해보겠다.

태그:

카테고리:

업데이트:

댓글남기기

참고

의존성 주입에 대한 고찰

4 분 소요

안드로이드 앱 개발 프로젝트들을 살펴보면, 대부분 DI 관련 라이브러리인 Hilt, Koin, Dagger2 등을 사용한 것을 볼 수 있습니다. 프로젝트들을 되돌아보면서 내가 정말 알고 사용하는 것이 맞나? 하고 점검하는 시간을 가지는 중에 DI 에 대한 의문? 이 생겨서 글로 남...

[Kotlin] Coroutine : Flow

5 분 소요

코루틴의 플로우는 어원인 흐름에서 유추 가능하듯이 물이 흐르는 파이프나 시냇물 처럼 데이터가 흐르는 통로를 말합니다. 플로우 이전에 Kotlin.Coroutine 에서는 코루틴간에 통신을 위해서 Channel 을 제공하고 있었습니다. 채널은 생산자와 소비자가 있고 생산자가 데이터를...

[Kotlin] Coroutine : Suspend 살펴보기

6 분 소요

Jetsbrains 의 Kotlinx.Coroutines 는 비동기 작업을 쉽게 동기로 작성하고 실행할 수 있는 기능을 제공하는 라이브러리 입니다. Coroutine 의 핵심인 Suspend 키워드는 Kotlin Compiler 가 compile time 에 특정 코드를 생성 및 ...