Jetpack-Lifecycle
Jetpack-LiveData
ViewModel
ViewModel是以能感知生命周期的方式存儲和管理界面相關數據的組件。感知生命周期是說當Activity或Fragment創建第一個實例的時候，它開始創建，當Activity銷毀或者Fragment分離的時候，它自動清理。比如：當屏幕旋轉時，它不會被重新創建，數據能夠被恢復。
當Activity配置發生變化時，我們也可以通過onSaveInstanceState() 方法保存數據，從 onCreate()或onRestoreInstanceState方法中恢復其數據，但這種方式僅適合可以序列化再反序列化的少量數據，而不適合較大數量的數據，如用戶列表；而ViewModel可以。
Activity或Fragment主要用于界面的展示，如果數據存儲和恢復的相關邏輯放在其中，會使Activity或Fragment變得臃腫。使用ViewModel可以將它們分離開來。
使用
class MyViewModel : ViewModel() {
private val users: MutableLiveData<List<User>> by lazy {
MutableLiveData().also {
it.value = loadUsers()
}
}
fun getUsers(): LiveData<List<User>> {
return users
}
private fun loadUsers()：List<User> {
//todo
}
}
class MyActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
//通過ViewModelProviders獲取ViewModel實例
val model = ViewModelProviders.of(this)[MyViewModel::class.java]
model.getUsers().observe(this, Observer<List<User>>{ users ->
//todo
})
}
}
ViewModel還存在一個子類：AndroidViewModel，它的構造方法接收一個Application類型的參數，方便在ViewModel中使用Context。
//定義
class MyViewModel(application:Application) : AndroidViewModel(application) {}
//獲取實例
mViewModel = ViewModelProviders.of(this,ViewModelProvider.AndroidViewModelFactory(application)).get(MyViewModel::class.java)
從上面看到當ViewModel的構造方法中有參數時，在獲取實例的時候，傳入了一個參數：ViewModelProvider.factory，那么這個Factory的作用是什么呢？當我們調用ViewModelProviders.of(activity)獲取ViewModel實例的時候，它內部會默認調用ViewModel無參構造方法來創建實例；但是當ViewModel的構造方法有依賴時，這時候就需要我們自定義Factory來實例化ViewModel。比如：ViewModel的構造方法含有一個Int類型的參數，Factory的實現如下：
class MyViewModel(id: Int) : ViewModel() {}
//自定義Factory
class MyViewModelFactory(private val arg: Int) : ViewModelProvider.Factory {
override fun <T : ViewModel?> create(modelClass: Class<T>): T {
return modelClass.getConstructor(Int::class.java).newInstance(arg)
}
}
生命周期
ViewModel的存在是從第一次獲取ViewModel實例一直到Activity完全銷毀或者Fragment分離，Activity因配置發生變化而重新創建時，ViewModel是不會重新創建的。
當ViewModel銷毀的時候，它會調用onCleared()方法，來清理相關的資源。
因為ViewModel比Activity的生命周期要長，所以ViewMode一定不能持有View的引用。
實現原理
我們要使用ViewModel，首先調用ViewModelProviders.of(this).get(MyViewModel::class.java)來獲取實例。我們就以此為分析的入口，看一下該方法的實現：
public static ViewModelProvider of(@NonNull FragmentActivity activity) {
return of(activity, null);
}
public static ViewModelProvider of(@NonNull FragmentActivity activity,@Nullable Factory factory) {
Application application = checkApplication(activity);
if (factory == null) {
factory = ViewModelProvider.AndroidViewModelFactory.getInstance(application);
}
return new ViewModelProvider(activity.getViewModelStore(), factory);
}
從上面可以看出最終都會調用兩個參數的方法，new ViewModelProvider(activity.getViewModelStore(), factory);，第一個參數通過Activity獲取一個ViewModelStore對象，該方法是在ComponentActivity中實現的：
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.");
}
if (mViewModelStore == null) {
NonConfigurationInstances nc = (NonConfigurationInstances) getLastNonConfigurationInstance();
if (nc != null) {
// Restore the ViewModelStore from NonConfigurationInstances
mViewModelStore = nc.viewModelStore;
}
if (mViewModelStore == null) {
mViewModelStore = new ViewModelStore();
}
}
return mViewModelStore;
}
Activity在配置發生變化時，如橫豎屏切換會觸發onSaveInstanceState()方法來保存狀態，除此之外Activity還提供了一個方法onRetainNonConfigurationInstance來保存狀態，最大的不同在于這個方法可以返回一個包含有狀態信息的Object。該方法是在onSaveInstanceState()方法之后調用，該方法不允許重寫。
public final Object onRetainNonConfigurationInstance() {
Object custom = onRetainCustomNonConfigurationInstance();
ViewModelStore viewModelStore = mViewModelStore;
if (viewModelStore == null) {
// No one called getViewModelStore(), so see if there was an existing
// ViewModelStore from our last NonConfigurationInstance
NonConfigurationInstances nc =
(NonConfigurationInstances) getLastNonConfigurationInstance();
if (nc != null) {
viewModelStore = nc.viewModelStore;
}
}
if (viewModelStore == null && custom == null) {
return null;
}
NonConfigurationInstances nci = new NonConfigurationInstances();
nci.custom = custom;
nci.viewModelStore = viewModelStore;
return nci;
}
Activity在配置發生變化的時候保存了viewModelStore，放到了NonConfigurationInstances中。上面的操作都圍繞著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);
}
Set<String> keys() {
return new HashSet<>(mMap.keySet());
}
public final void clear() {
for (ViewModel vm : mMap.values()) {
vm.clear();
}
mMap.clear();
}
}
ViewModelStore的代碼很簡單，就是用一個HashMap來存儲ViewModel。那么ViewModel又是從什么時候存進去的呢？那就要從ViewModel的創建說起，我們獲取ViewModel的實例調用的是ViewModelProvider的get()方法。
public <T extends ViewModel> T get(@NonNull Class<T> modelClass) {
String canonicalName = modelClass.getCanonicalName();
if (canonicalName == null) {
throw new IllegalArgumentException("Local and anonymous classes can not be ViewModels");
}
return get(DEFAULT_KEY + ":" + canonicalName, modelClass);
}
public <T extends ViewModel> T get(@NonNull String key, @NonNull Class<T> modelClass) {
ViewModel viewModel = mViewModelStore.get(key);
if (modelClass.isInstance(viewModel)) {
return (T) viewModel;
} else {
//noinspection StatementWithEmptyBody
if (viewModel != null) {
// TODO: log a warning.
}
}
if (mFactory instanceof KeyedFactory) {
viewModel = ((KeyedFactory) (mFactory)).create(key, modelClass);
} else {
viewModel = (mFactory).create(modelClass);
}
mViewModelStore.put(key, viewModel);
return (T) viewModel;
}
get()方法的實現也比較簡單：先判斷緩存中是否存在ViewModel，如果不存在就使用Factory創建一個實例，然后加入到緩存中。
ViewModel存儲在ViewModelStore中，而ViewModelStore在Activity配置變化的時候會在onRetainNonConfigurationInstance()方法中保存起來，也就是說ViewModelStore不會因為Activity配置發生變化而重新創建。所以ViewModel也不會重新創建。
那么ViewModel是在什么時候銷毀的呢？ViewModel存儲在ViewModelStore里面的mMap中，它中有一個clear()方法,用來清除這個mMap，也就是清除ViewModel，那么我們就看一下這個方法是在哪里調用的？
public ComponentActivity() {
...
getLifecycle().addObserver(new LifecycleEventObserver() {
@Override
public void onStateChanged(@NonNull LifecycleOwner source,
@NonNull Lifecycle.Event event) {
if (event == Lifecycle.Event.ON_DESTROY) {
if (!isChangingConfigurations()) {
getViewModelStore().clear();
}
}
}
});
...
}
在Activity創建的時候會通過Lifecycle添加一個觀察者，觀察Activity的ON_DESTROY狀態。當處于該狀態時，判斷是否是配置變化觸發的，如果不是則調用ViewModelStore的clear()方法。從這里也可以看出，當Activity配置變化的時候并不會清理ViewModel。在Jetpack-Lifecycle中我們知道，當Activity調用onDestroy()時，狀態會變為ON_DESTROY。
public final void clear() {
for (ViewModel vm : mMap.values()) {
vm.clear();
}
mMap.clear();
}
在clear()方法中會調用ViewModel的clear()方法
final void clear() {
mCleared = true;
if (mBagOfTags != null) {
synchronized (mBagOfTags) {
for (Object value : mBagOfTags.values()) {
// see comment for the similar call in setTagIfAbsent
closeWithRuntimeException(value);
}
}
}
onCleared();
}
protected void onCleared() {
}
所以在ViewModel即將銷毀的時候會回調它的onCleared()方法，我們可以在該方法中做一些清理的工作。
