看完这篇文章，Jetpack的ViewModel闭着眼睛用

/   今日科技快讯   /

近日，据国外媒体报道，在上海超级工厂提前完工，Model Y预计提前半年升产，德国超级工厂已排上日程等一系列利好因素的刺激下，当地时间周一，电动汽车制造商特斯拉股价上涨6.45%至381.5美元，创下2018年8月以来的最高水平。

/   作者简介   /

大家早上好，不知不觉一周已过半，今天也要努力学习哟！

本篇文章自谭嘉俊的投稿，分享了Jetpack框架中ViewModel的源码分析，相信对大家有所帮助。同时也感谢作者贡献的精彩文章！

谭嘉俊的博客地址：

https://www.jianshu.com/u/257511d0c878

/   前言   /

本文章主要是对ViewModel进行源码分析，建议对着示例代码阅读文章，示例代码如下：

https://github.com/TanJiaJunBeyond/ViewModelDemo

本文章使用的是Android SDK 29的源码分析。

/   定义   /

Android框架管理UI控制器的生命周期（例如：Activity和Fragment），Framework可能决定销毁或者重新创建一个UI控制器，以响应某些用户操作或者设备事件，这些操作或者事件完全超出你的控制。

如果系统销毁或者重新创建一个UI控制器，那么你存储在其中的任何与UI相关的临时数据都丢失，例如：你的应用程序在某个Activity中包含一个用户列表，当配置信息更改重新创建Activity时，新的Activity必须重新获取用户列表。对于简单数据，Activity可以使用onSaveInstanceState()方法，并且在onCreate()方法中从Bundle中恢复数据，但是这种方法只适用于少量的、可以序列化和反序列化的数据，而不是潜在的大量数据的用户列表或者是很多的Bitmap。

另外一个问题是UI控制器经常需要进行异步调用，这可能需要一些时间才能返回，UI控制器需要管理这些调用，并确保系统在销毁后对其进行清理，以避免潜在的内存泄露，这种管理需要大量的维护，并且为了配置更改而重新创建对象的情况下，这是对资源的浪费，因为对象可能不得不重新发出它已经发出的调用。

UI控制器（例如：Activity和Fragment）主要用于显示UI数据、响应用户操作或者处理操作系统通信（例如：权限请求），要求UI控制器也负责从数据库或者网络加载数据会使类膨胀，将过多的责任分配给UI控制器会导致单个类视图自己处理应用程序的所有工作，而不是将工作委托给其他类，这样也会使测试变得更加困难。

将视图数据所有权从UI控制器的逻辑中分离出来会更加简单、更有效，所以官方推出这样一个组件：ViewModel。

ViewModel是一个负责准备和管理Activity或者Fragment的类，它还可以处理Activity和Fragment与应用程序其余部分的通信（例如：调用业务逻辑类）。

ViewModel总是在一个Activity或者一个Fragment创建的，并且只要对应的Activity或者Fragment处于活动状态的话，它就会被保留（例如：如果它是个Activity，就会直到它finished）。

换句话说，这意味着一个ViewModel不会因为配置的更改（例如：旋转）而被销毁，所有的新实例将被重新连接到现有的ViewModel。

ViewModel的目的是获取和保存Activity或者Fragment所需的信息，Activity或者Fragment应该能够观察到ViewModel中的变化，通常通过LiveData或者Android Data Binding公开这些信息。

要注意的是，ViewModel的唯一职责是管理UI的数据，它不应该访问你的视图层次结构或者保留对Activity或者Fragment的引用。

以下这张图片表示Activity经历屏幕旋转而后结束的过程中所处的各种生命周期状态，还在关联的Activity生命周期的旁边显示了ViewModel的生命周期：

/   示例代码   /

项目加上如下依赖：

implementation 'androidx.lifecycle:lifecycle-extensions:2.2.0-alpha02'

由于我这边用到了DataBinding，所以加上如下代码：

dataBinding {
    enabled = true
}

项目结构如下图：

我这边定义了一个继承了ViewModel，并且实现了Observable的ObservableViewModel类，来通知控件数据的变化，也可以使用LiveData来实现这样的功能，代码如下：

package com.tanjiajun.viewmodeldemo.viewmodel

import androidx.databinding.Observable
import androidx.databinding.PropertyChangeRegistry
import androidx.lifecycle.ViewModel

/**
 * Created by TanJiaJun on 2019-11-24.
 */
open class ObservableViewModel : ViewModel(), Observable {

    private val callbacks = PropertyChangeRegistry()

    override fun addOnPropertyChangedCallback(callback: Observable.OnPropertyChangedCallback?) =
        callbacks.add(callback)

    override fun removeOnPropertyChangedCallback(callback: Observable.OnPropertyChangedCallback?) =
        callbacks.remove(callback)

    fun notifyChange() =
        callbacks.notifyCallbacks(this, 0, null)

    fun notifyPropertyChanged(fieldId: Int) =
        callbacks.notifyCallbacks(this, fieldId, null)

}

第一个例子：ViewModel不会因为配置更改而被销毁

在MainActivity中创建MainViewModel，代码如下：

// MainActivity.kt
override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    DataBindingUtil.setContentView<ActivityMainBinding>(this, R.layout.activity_main).also {
        it.viewModel = ViewModelProviders.of(this)[MainViewModel::class.java].apply {
            name = "谭嘉俊"
            age = 25
            gender = "男"
        }
        it.handlers = this
    }
}

这个Activity所对应的界面可以跟随手机屏幕旋转，而且没有通过android:configChanges指定属性，让Activity在指定属性变化的时候，只会调用Activity的onConfigurationChanged()方法，而不会被销毁重建，代码如下：

android:configChanges="orientation|screenSize|keyboardHidden"

当我们旋转手机屏幕的时候，发现这个Activity的内容没有发生变化，符合我们的预期。

第二个例子是：Fragment使用Activity共享的ViewModel处理数据

定义NameViewModel，并且继承我在上面说的ObservableViewModel，代码如下：

package com.tanjiajun.viewmodeldemo.viewmodel

import androidx.databinding.Bindable
import androidx.databinding.library.baseAdapters.BR

/**
 * Created by TanJiaJun on 2019-11-24.
 */
class NameViewModel : ObservableViewModel() {

    @get:Bindable
    var name = ""
        set(value) {
            field = value
            notifyPropertyChanged(BR.name)
        }

}

在FirstNameFragment使用一个和NameActivity生命周期相同的NameViewModel，代码如下：

// FirstNameFragment.kt
private var viewModel: NameViewModel? = null

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    // retainInstance方法下面会解析
    retainInstance = true
    viewModel = activity?.let {
        ViewModelProviders.of(it)[NameViewModel::class.java].apply {
            name = "谭嘉俊"
        }
    }
}

override fun onCreateView(
    inflater: LayoutInflater,
    container: ViewGroup?,
    savedInstanceState: Bundle?
): View? =
    DataBindingUtil.inflate<FragmentFirstNameBinding>(
        inflater,
        R.layout.fragment_first_name,
        container,
        false
    )
        .also {
            // 使用NameActivity共享的NameViewModel
            it.viewModel = viewModel
            it.handlers = this
        }
        .root

retainInstance方法控制在Activity重新创建（例如：配置更改）期间是否重新创建Fragment实例，如果设为true的话，在Activity重新创建的时候，Fragment的生命周期会有点不一样，onCreate(Bundle)方法将不会被调用，因为Fragment没有重新创建，onDestroy()不会被调用，但是onDetach()方法会被调用，因为Fragment只是从它附加的Activity分离而已，onAttach(Activity)方法和onActivityCreated(Bundle)方法仍然会被调用。

// SecondNameFragment.kt
override fun onCreateView(
    inflater: LayoutInflater,
    container: ViewGroup?,
    savedInstanceState: Bundle?
): View? =
    DataBindingUtil.inflate<FragmentSecondNameBinding>(
        inflater,
        R.layout.fragment_second_name,
        container,
        false
    )
        .also { it.handlers = this }
        .root

// 点击按钮后会改变NameViewModel中name的属性值
override fun onChangeNameToAppleClick(view: View) {
    activity?.let { ViewModelProviders.of(it)[NameViewModel::class.java].name = "苹果" }
}

点击SecondFragment的按钮后，我们再按后退键，退回到上个Fragment，可以看到name已经已经从”谭嘉俊“变成”苹果“了，这里的NameViewModel的生命周期是和NameActivity的生命周期一样，也就是这两个Fragment拿到的都是同一个ViewModel，所以我们可以这样处理附加在同一个Activity的多个Fragment之间的数据。

/   源码分析   /

我们看下ViewModelProviders这个类，代码如下：

// 创建一个ViewModelProvider，在Fragment处于活动状态时保留ViewModel
@NonNull
@MainThread
public static ViewModelProvider of(@NonNull Fragment fragment) {
    return of(fragment, null);
}

// 创建一个ViewModelProvider，在Activity处于活动状态时保留ViewModel
@NonNull
@MainThread
public static ViewModelProvider of(@NonNull FragmentActivity activity) {
    return of(activity, null);
}

@NonNull
@MainThread
public static ViewModelProvider of(@NonNull Fragment fragment, @Nullable Factory factory) {
    // 检查Fragment是否附加在Application
    Application application = checkApplication(checkActivity(fragment));
    // 在上面的方法中factory是传null
    if (factory == null) {
        // 创建一个单例的AndroidViewModelFactory
        factory = ViewModelProvider.AndroidViewModelFactory.getInstance(application);
    }
    // 创建ViewModelProvider，这里会拿到Fragment的ViewModelStore，下面会分析
    return new ViewModelProvider(fragment.getViewModelStore(), factory);
}

@NonNull
@MainThread
public static ViewModelProvider of(@NonNull FragmentActivity activity,
        @Nullable Factory factory) {
    // 检查Activity是否附加在Application
    Application application = checkApplication(activity);
    // 在上面的方法中factory是传null
    if (factory == null) {
        // 创建一个单例的AndroidViewModelFactory
        factory = ViewModelProvider.AndroidViewModelFactory.getInstance(application);
    }
    // 创建ViewModelProvider，这里会拿到Activity的ViewModelStore，下面会分析
    return new ViewModelProvider(activity.getViewModelStore(), factory);
}

我们看下Activity的getViewModelStore()方法，代码如下：

@NonNull
@Override
public ViewModelStore getViewModelStore() {
    // 检查Activity是否附加在Application
    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) {
        // 通过getLastNonConfigurationInstance()方法得到NonConfigurationInstances，下面会分析
        NonConfigurationInstances nc =
                (NonConfigurationInstances) getLastNonConfigurationInstance();
        if (nc != null) {
            // 从NonConfigurationInstances恢复ViewModelStore
            mViewModelStore = nc.viewModelStore;
        }
        // 如果是空的话创建ViewModelStore对象
        if (mViewModelStore == null) {
            mViewModelStore = new ViewModelStore();
        }
    }
    return mViewModelStore;
}

在分析getLastNonConfigurationInstances()方法之前，我们看下onRetainNonConfigurationInstance()方法，它在Activity类中是一个返回null的方法，我们可以找到Activity的子类ComponentActivity，可以看到它重写了这个方法，代码如下：

// ComponentActivity.java
// NonConfigurationInstances是一个final的静态类，里面有两个变量：custom和viewModelStore
static final class NonConfigurationInstances {
    Object custom;
    ViewModelStore viewModelStore;
}

@Override
@Nullable
public final Object onRetainNonConfigurationInstance() {
    // onRetainCustomNonConfigurationInstance()方法已弃用
    Object custom = onRetainCustomNonConfigurationInstance();

    ViewModelStore viewModelStore = mViewModelStore;
    if (viewModelStore == null) {
        // 如果viewModelStore是null的话，证明没人调用getViewModelStore()，所以看看我们最后一个NonConfigurationInstance是否存在ViewModelStore
        NonConfigurationInstances nc =
                (NonConfigurationInstances) getLastNonConfigurationInstance();
        if (nc != null) {
            // 如果有的话，就从NonConfigurationInstances取出ViewModelStore
            viewModelStore = nc.viewModelStore;
        }
    }

    if (viewModelStore == null && custom == null) {
        // 如果ViewModelStore还是null而且custom也是null的话，证明没有NonConfigurationInstances
        return null;
    }

    // 如果有ViewModelStore或者有custom的话，就创建NonConfigurationInstances对象，并且对其进行赋值
    NonConfigurationInstances nci = new NonConfigurationInstances();
    nci.custom = custom;
    nci.viewModelStore = viewModelStore;
    return nci;
}

onRetainNonConfigurationInstance()方法是在一个Activity因为配置改变而被销毁时被调用，这时就会创建一个新的实例，它会在onStop()方法和onDestroy()方法两者之间调用，我们可以在这里返回对象，甚至是Activity的实例也可以，之后我们可以在新的Activity的实例通过getLastNonConfigurationInstance()方法来检索，拿到我们想要的对象。

我们之前也用过onSaveInstanceState方法，调用这个方法可以在Activity被终止之前检索每个实例的状态，以便可以在onCreate方法或者onRestoreInstanceState方法中恢复状态，两个方法都会传入我们之前想要保留的Bundle对象，注意你还要给你的View设置id，因为它是通过id保存当前有焦点的View，在Android P版本中，这个方法将在onStop()方法之后调用，在之前的版本中，这个方法将在onStop()方法之前调用，并不能保证它将在onPause()方法之前或之后调用，这个方法默认实现保存了关于Activity的视图层次状态的临时信息，例如：EditText中的文本和ListView或者RecyclerView中的滚动条位置。

那onSaveInstanceState方法和onRetainNonConfigurationInstance()方法还有什么区别呢？其中一点是前者是保存到Bundle，Bundle是有类型限制和大小限制的，而且也要在主线程序列化和反序列化数据，而后者是保存到Object，类型和大小都没有限制。

我们继续看源码，从上面分析可知，会创建ViewModelStore对象，我们看下ViewModelStore的源码，代码如下：

public class ViewModelStore {

    // 创建一个key为String，value为ViewModel的HashMap对象
    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());
    }

    // 清除内部存储并且通知存储在这个HashMap中的所有的ViewModel不再被使用
    public final void clear() {
        for (ViewModel vm : mMap.values()) {
            vm.clear();
        }
        mMap.clear();
    }
}

它是通过HashMap存放ViewModel的，然后我们回到上面ViewModelProviders的of方法，可以看到它创建了ViewModelProvider对象，看下它的构造方法，代码如下：

// ViewModelProvider.java
public ViewModelProvider(@NonNull ViewModelStore store, @NonNull Factory factory) {
    mFactory = factory;
    mViewModelStore = store;
}

构造方法就两个参数，第一个是ViewModelStore，用于存放ViewModel；第二个参数是Factory，用于实例化多个ViewModel的工厂。

在我们的示例代码中，我们调用了ViewModelProvider的get方法，传入的是我们创建的ViewModel的Class对象，看下相关的代码，代码如下：

// ViewModelProvider.java
private static final String DEFAULT_KEY =
        "androidx.lifecycle.ViewModelProvider.DefaultKey";

@NonNull
@MainThread
public <T extends ViewModel> T get(@NonNull Class<T> modelClass) {
    // 得到ViewModel的Class对象的Java语言规范定义的底层类的规范名称
    String canonicalName = modelClass.getCanonicalName();
    if (canonicalName == null) {
        throw new IllegalArgumentException("Local and anonymous classes can not be ViewModels");
    }
    // 调用下面的get方法，传入“DEFAULT_KEY:modelClass的规范名称”字符串和ViewModel的Class对象
    return get(DEFAULT_KEY + ":" + canonicalName, modelClass);
}

@SuppressWarnings("unchecked")
@NonNull
@MainThread
public <T extends ViewModel> T get(@NonNull String key, @NonNull Class<T> modelClass) {
    // 通过key从ViewModelStore中的HashMap中得到ViewModel
    ViewModel viewModel = mViewModelStore.get(key);

    // 判断从ViewModelStore中得到的ViewModel是否是Class对象的一个实例，也就是说判断ViewModelStore中是否存在我们想要的ViewModel
    if (modelClass.isInstance(viewModel)) {
        // 如果有的话就返回对应的ViewModel
        return (T) viewModel;
    } else {
        //noinspection StatementWithEmptyBody
        if (viewModel != null) {
            // TODO: log a warning.
        }
    }
    // 如果没有的话就创建ViewModel
    if (mFactory instanceof KeyedFactory) {
        viewModel = ((KeyedFactory) (mFactory)).create(key, modelClass);
    } else {
        // 根据上面的代码可知，mFactory是Factory的实现类NewInstanceFactory的子类AndroidViewModelFactory，所以我们调用的是这段逻辑
        viewModel = (mFactory).create(modelClass);
    }
    // 将创建好的ViewModel存放到ViewModelStore
    mViewModelStore.put(key, viewModel);
    // 返回ViewModel
    return (T) viewModel;
}

我们看下AndroidViewModelFactory的create方法，代码如下：

// ViewModelProvider中的静态内部类AndroidViewModelFactory
@NonNull
@Override
public <T extends ViewModel> T create(@NonNull Class<T> modelClass) {
    // 判断AndroidViewModel所表示的类或接口是否与modelClass所表示的类或接口相同，或者是否为其超类或超接口
    if (AndroidViewModel.class.isAssignableFrom(modelClass)) {
        //noinspection TryWithIdenticalCatches
        try {
            // 创建ViewModel对象
            return modelClass.getConstructor(Application.class).newInstance(mApplication);
        } catch (NoSuchMethodException e) {
            throw new RuntimeException("Cannot create an instance of " + modelClass, e);
        } catch (IllegalAccessException e) {
            throw new RuntimeException("Cannot create an instance of " + modelClass, e);
        } catch (InstantiationException e) {
            throw new RuntimeException("Cannot create an instance of " + modelClass, e);
        } catch (InvocationTargetException e) {
            throw new RuntimeException("Cannot create an instance of " + modelClass, e);
        }
    }
    // 根据我们的示例代码，我们传入的modelClass不是AndroidViewModel，而且也不是为其超类或者超接口，所以会执行以下逻辑
    return super.create(modelClass);
}

ViewModel是不能传入任何有Context引用的对象，这样导致内存泄露，如果需要使用的话，可以使用AndroidViewModel。

然后会调用它的父类NewInstanceFactory的create方法，代码如下：

@SuppressWarnings("ClassNewInstance")
@NonNull
@Override
public <T extends ViewModel> T create(@NonNull Class<T> modelClass) {
    //noinspection TryWithIdenticalCatches
    try {
        // 创建由modelClass类对象表示的类的新实例
        return modelClass.newInstance();
    } catch (InstantiationException e) {
        throw new RuntimeException("Cannot create an instance of " + modelClass, e);
    } catch (IllegalAccessException e) {
        throw new RuntimeException("Cannot create an instance of " + modelClass, e);
    }
}

刚才我们看的是Activity的getViewModelStore()方法，现在看下Fragment的getViewModelStore()方法，代码如下：

// Fragment.java
@NonNull
@Override
public ViewModelStore getViewModelStore() {
    // 判断Fragment是否已经与Activity分离
    if (mFragmentManager == null) {
        throw new IllegalStateException("Can't access ViewModels from detached fragment");
    }
    return mFragmentManager.getViewModelStore(this);
}

调用了FragmentManagerImpl的getViewModelStore方法，代码如下：

// FragmentManagerImpl.java
@NonNull
ViewModelStore getViewModelStore(@NonNull Fragment f) {
    return mNonConfig.getViewModelStore(f);
}

成员变量mNonConfig是FragmentManagerVIewModel的引用，我们看下FragmentManagerViewModel的getViewModelStore方法，代码如下：

// FragmentManagerViewModel.java
@NonNull
ViewModelStore getViewModelStore(@NonNull Fragment f) {
    ViewModelStore viewModelStore = mViewModelStores.get(f.mWho);
    if (viewModelStore == null) {
        viewModelStore = new ViewModelStore();
        mViewModelStores.put(f.mWho, viewModelStore);
    }
    return viewModelStore;
}

成员变量mViewModelStores是key为String、value为ViewModelStore的HashMap的引用，它是跟随Fragment的生命周期，根据Frament的内部唯一名称从这个HashMap中得到ViewModelStore，如果是空的话，就创建一个新的ViewModelStore对象，并且放入mViewModelStores，然后返回这个对象；如果不是空的话，就返回刚才从HashMap取得的ViewModelStore。

到这里，ViewModel的创建和得到的源码就分析得差不多了，然后我们看下ViewModel什么时候被销毁，在上面分析ViewModelStore源码的时候，我们看到有个clear方法，这个方法用来清除内部存储并且通知存储在这个HashMap中的所有的ViewModel不再被使用，如果ViewModel跟随的Activity的生命周期的话，它会在如下代码调用这个方法：

public ComponentActivity() {
    // 省略部分代码
    getLifecycle().addObserver(new LifecycleEventObserver() {
        @Override
        public void onStateChanged(@NonNull LifecycleOwner source,
                @NonNull Lifecycle.Event event) {
            // 判断是否接收到Activity的destroy状态
            if (event == Lifecycle.Event.ON_DESTROY) {
                // 如果接收到，判断是否因为配置更改导致的destroy
                if (!isChangingConfigurations()) {
                    // 如果不是，调用ViewModelStore的clear方法
                    getViewModelStore().clear();
                }
            }
        }
    });
    // 省略部分代码
}

如果ViewModel跟随的是Fragment的生命周期的话，它会在如下代码调用这个方法：

// FragmentManagerViewModel.java
void clearNonConfigState(@NonNull Fragment f) {
    if (FragmentManagerImpl.DEBUG) {
        Log.d(FragmentManagerImpl.TAG, "Clearing non-config state for " + f);
    }
    // 清除并且删除Fragment的子配置状态
    FragmentManagerViewModel childNonConfig = mChildNonConfigs.get(f.mWho);
    if (childNonConfig != null) {
        childNonConfig.onCleared();
        mChildNonConfigs.remove(f.mWho);
    }
    // 清除并且删除Fragment的ViewModelStore
    ViewModelStore viewModelStore = mViewModelStores.get(f.mWho);
    if (viewModelStore != null) {
        viewModelStore.clear();
        mViewModelStores.remove(f.mWho);
    }
}

在如下代码调用clearNonConfigState这个方法：

// FragmentManagerImpl.java
@SuppressWarnings("ReferenceEquality")
void moveToState(Fragment f, int newState, int transit, int transitionStyle,
                 boolean keepActive) {
    // 省略部分代码
    if (f.mState <= newState) {
        // 省略部分代码
    } else if (f.mState > newState) {
        switch (f.mState) {
            // 省略部分代码
            case Fragment.CREATED:
                if (newState < Fragment.CREATED) {
                    // 省略部分代码
                    if (f.getAnimatingAway() != null || f.getAnimator() != null) {
                        // 省略部分代码
                    } else {
                        if (DEBUG) Log.v(TAG, "movefrom CREATED: " + f);
                        boolean beingRemoved = f.mRemoving && !f.isInBackStack();
                        // 判断Fragment是否正在remove，同时还没放入后退栈，或者判断是否FragmentManagerViewModel是否应该销毁
                        if (beingRemoved || mNonConfig.shouldDestroy(f)) {
                            boolean shouldClear;
                            // 判断mHost是否是ViewModelStoreOwner的实例
                            if (mHost instanceof ViewModelStoreOwner) {
                                // 如果是，shouldClear的值就是FragmentManagerViewModel是否已经清除
                                shouldClear = mNonConfig.isCleared();
                            } else if (mHost.getContext() instanceof Activity) {
                                Activity activity = (Activity) mHost.getContext();
                                shouldClear = !activity.isChangingConfigurations();
                            } else {
                                shouldClear = true;
                            }
                            // 根据beingRemoved或者shouldClear的值来判断是否需要清除ViewModel
                            if (beingRemoved || shouldClear) {
                                // 如果是，调用clearNonConfigState方法
                                mNonConfig.clearNonConfigState(f);
                            }
                            // 执行Fragment的onDestroy()方法
                            f.performDestroy();
                            dispatchOnFragmentDestroyed(f, false);
                        } else {
                            f.mState = Fragment.INITIALIZING;
                        }
                        // 省略部分代码
                    }
                }
        }
    }

    // 省略部分代码
}

到这里，ViewModel的销毁的源码分析得差不多了。

/   onSaveInstanceState和ViewModel   /

onSaveInstanceState是生命周期的一个回调方法，用来保存以下两种状态下的少量UI相关的数据：

• 应用的进程在后台的时候由于内存限制而被终止。
• 配置更改。

onSaveInstanceState不是被设计用来储存类似Bitmap这样大的数据，而是储存小的、与UI相关的、能够被序列化和反序列化的数据，上面也提及过了，这里就不再赘述了。

ViewModel有以下好处：

• ViewModel可以架构设计更加良好，UI代码和数据分离，使代码更加遵循单一职责原则、更加模块化、更易于测试。
• ViewModel能储存更大、更复杂的数据，而且数据类型也没有限制，甚至可以储存Activity实例。

要注意的是，ViewModel只能在配置更改造成相关的销毁下得到保留，而不能在被终止的进程中得到保留，也就是说在应用的进程在后台的时候由于内存限制而被终止，ViewModel也会被销毁。

因此我们最好两者结合来处理保存和恢复UI状态，如果要保证数据不丢失，就要对数据进行本地持久化。

/   题外话   /

如果应用在特定配置更改期间无需更新资源，并且因性能限制你需要避免Activity重启，则可声明Activity自行处理配置更改，从而阻止系统重启Activity。

我们可以通过在AndroidManifest文件中，找到相应<activity>元素，添加android:configChanges属性，在声明多个配置值的时候，可以通过|字符对其进行分隔。

Android官方不建议对大多数应用使用此方法，因为这样做可能会提高使用备用资源的难度。

有如下属性：

• density：显示密度发生变更，例如：用户可能已指定不同的显示比例，或者有不同的显示现处于活跃状态。请注意：此项为 API 级别 24 中的新增配置。
• fontScale：字体缩放系数发生变更，例如：用户已选择新的全局字号。
• keyboard：键盘类型发生变更，例如：用户插入外置键盘。
• keyboardHidden：键盘无障碍功能发生变更，例如：用户显示硬键盘。
• layoutDirection：布局方向发生变更，例如：自从左至右 (LTR) 更改为从右至左 (RTL)。**请注意：此项为 API 级别 17 中的新增配置。
• locale：语言区域发生变更，例如：用户已为文本选择新的显示语言。
• mcc：IMSI 移动设备国家/地区代码 (MCC) 发生变更，例如：检测到 SIM 并更新 MCC。
• mnc：IMSI 移动设备网络代码 (MNC) 发生变更，例如：检测到 SIM 并更新 MNC。
• navigation：导航类型（轨迹球/方向键）发生变更。（这种情况通常不会发生。）
• orientation：屏幕方向发生变更，例如：用户旋转设备。请注意：如果应用面向 Android 3.2（API 级别 13）或更高版本的系统，则还应声明screenSize配置，因为当设备在横向与纵向之间切换时，该配置也会发生变更。
• screenLayout：屏幕布局发生变更，例如：不同的显示现可能处于活跃状态。
• screenSize：当前可用屏幕尺寸发生变更。该值表示当前可用尺寸相对于当前纵横比的变更，当用户在横向与纵向之间切换时，它便会发生变更。请注意：此项为 API 级别 13 中的新增配置。
• smallestScreenSize：物理屏幕尺寸发生变更。该值表示与方向无关的尺寸变更，因此它只有在实际物理屏幕尺寸发生变更（如切换到外部显示器）时才会变化。对此配置所作变更对应smallestWidth配置的变化。请注意：此项为 API 级别 13 中的新增配置。
• touchscreen：触摸屏发生变更。（这种情况通常不会发生。）
• uiMode：界面模式发生变更，例如：用户已将设备置于桌面或车载基座，或者夜间模式发生变更。如需了解有关不同界面模式的更多信息，请参阅UiModeManager。请注意：此项为 API 级别 8 中的新增配置。

所有这些配置变更都可能影响到应用所看到资源值，因此调用onConfigurationChanged()方法时，通常有必要再次检索所有资源（包括视图布局、可绘制对象等），以正确处理变更。

推荐阅读：

欢迎关注我的公众号

学习技术或投稿

长按上图，识别图中二维码即可关注