每日一问 Activity 都重建了，你 Fragment凭什么活着？

源码分析 （看之前建议先看看昨晚的回答，会对总体的流程有个大致的了解）

昨天我复制鸿神说的setRetaineInstance到AS中全局搜索的时候，发现居然没有这个方法？？？还在想是不是骗人的啊。。。。然后注意到Retaine这个词，Retaine是什么意思？复制打开百度翻译，没想到百度翻译的结果是“复鞣”？？？什么鬼。。。然后突然想到，会不会是Retain（保留）啊，保留实例吧，于是回到AS中把e删掉，果然搜到了。。

首先看看调用setRetainInstance(true)后会发生什么：

    public void setRetainInstance(boolean retain) {
        mRetainInstance = retain;
        ......
        mRetainInstanceChangedWhileDetached = true;
    }

在赋值给mRetainInstance之后，还把mRetainInstanceChangedWhileDetached设为true。

当FragmentManager添加Fragment的时候，会调用一个makeActive方法：

     final HashMap<String, Fragment> mActive = new HashMap<>();

     void makeActive(Fragment f) {
        mActive.put(f.mWho, f);

        if (f.mRetainInstanceChangedWhileDetached) {
            if (f.mRetainInstance) {
                addRetainedFragment(f);
            } else {
                removeRetainedFragment(f);
            }
            f.mRetainInstanceChangedWhileDetached = false;
        }
    }

可以看到，如果Fragment的mRetainInstanceChangedWhileDetached和mRetainInstance都为true的话，就会调用addRetainedFragment方法：

        private FragmentManagerViewModel mNonConfig;

        void addRetainedFragment(@NonNull Fragment f) {
            ......

            boolean added = mNonConfig.addRetainedFragment(f);

            ......
    }

嗯！它会用到我们昨晚说的那个FragmentManagerViewModel的addRetainedFragment方法，看看它里面是怎样的：

    private final HashSet<Fragment> mRetainedFragments = new HashSet<>();

    boolean addRetainedFragment(@NonNull Fragment fragment) {
        return mRetainedFragments.add(fragment);
    }

没错了，就像昨晚说的那样：设置mRetainInstance为true的Fragment，会添加到FragmentManagerViewModel的mRetainedFragments中。

接着来看看FragmentManagerImpl的FragmentManagerViewModel是怎样保存到ComponentActivity（AppCompatActivity也是间接继承它的）的ViewModelStore里面的：

其实很简单，在FragmentManagerImpl初始化的时候就已经put进去了：

来看看它初始化的方法：

    private FragmentManagerViewModel mNonConfig;

    public void attachController(@NonNull FragmentHostCallback host,
            @NonNull FragmentContainer container, @Nullable final Fragment parent) {

        ......

        // Get the FragmentManagerViewModel
        if (parent != null) {
            mNonConfig = parent.mFragmentManager.getChildNonConfig(parent);
        } else if (host instanceof ViewModelStoreOwner) {
            ViewModelStore viewModelStore = ((ViewModelStoreOwner) host).getViewModelStore();
            mNonConfig = FragmentManagerViewModel.getInstance(viewModelStore);
        } else {
            mNonConfig = new FragmentManagerViewModel(false);
        }
    }

可以看到，mNonConfig初始化时有三个分支，会走哪一个呢？

这个attachController方法，会在FragmentActivity的onCreate方法回调时第一时间调用，而FragmentActivity继承自ComponentActivity，ComponentActivity是实现了ViewModelStoreOwner的！所以这里的分支，会走第二个。

第二个分支，它会调用FragmentManagerViewModel的getInstance方法，并将一个ViewModelStore传进去，可以看到这个ViewModelStore是通过host的getViewModelStore方法来获取的，而此时的host，就是FragmentActivity！来看看它的getViewModelStore方法是怎么样的：

    public ViewModelStore getViewModelStore() {
        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;
    }

    public Object getLastNonConfigurationInstance() {
        return mLastNonConfigurationInstances != null
                ? mLastNonConfigurationInstances.activity : null;
    }

它会先尝试从getLastNonConfigurationInstance方法里获取，如果没有就创建新的对象并返回。

好，回到刚刚说的第二个分支里，当它调用了FragmentManagerViewModel的getInstance方法（ViewModelStore传进去）之后，发生了什么呢？

看看：

    @NonNull
    static FragmentManagerViewModel getInstance(ViewModelStore viewModelStore) {
        ViewModelProvider viewModelProvider = new ViewModelProvider(viewModelStore, FACTORY);
        return viewModelProvider.get(FragmentManagerViewModel.class);
    }

    private static final ViewModelProvider.Factory FACTORY = new ViewModelProvider.Factory() {
        @NonNull
        @Override
        @SuppressWarnings("unchecked")
        public <T extends ViewModel> T create(@NonNull Class<T> modelClass) {
            FragmentManagerViewModel viewModel = new FragmentManagerViewModel(true);
            return (T) viewModel;
        }
    };

很简单，就是先创建一个ViewModelProvider对象，创建ViewModelProvider对象时，会把参数ViewModelStore（也就是ComponentActivity中的ViewModelStore对象）和一个FACTORY传进去，这个FACTORY，它里面有个create方法，里面会返回一个新的FragmentManagerViewModel对象。

创建了ViewModelProvider对象之后，会直接return（注意这里的return是return到mNonConfig的赋值语句中的） ViewModelProvider的get方法的返回值，也就是说，mNonConfig最终引用的对象，就是ViewModelProvider的get方法返回的对象。

那现在来看看ViewModelProvider这个类：

    public class ViewModelProvider {
        private final Factory mFactory;
        private final ViewModelStore mViewModelStore;

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

        public <T extends ViewModel> T get(@NonNull String key, @NonNull Class<T> modelClass) {

            ......

            ViewModel viewModel = (mFactory).create(modelClass);
            mViewModelStore.put(key, viewModel);

            return (T) viewModel;
        }
    }

emmm，它的get方法，会先调用mFactory的create方法来获取一个ViewModel对象（注意！这个mFactory就是我们刚刚说的那个，也就是create方法会返回FragmentManagerViewModel对象了），接着！会把这个ViewModel put到mViewModelStore（还记得这个mViewModelStore吗？不记得就看一下上面分析分支那里）里面去！这也就对应了我们昨晚说的：在初始化时就已经把自身put进去了。

好，现在知道了设置mRetainInstance为true的Fragment最终会间接保存到ComponentActivity的ViewModelStore里面。

那么接下来，就看看这个ViewModelStore它是怎么传递到新创建的Activity中的：

在Activity里面有个onRetainNonConfigurationInstance，但它是一个空方法，这个方法在ComponentActivity中被重写了：

    private ViewModelStore mViewModelStore;

    public final Object onRetainNonConfigurationInstance() {

        ......

        ViewModelStore viewModelStore = mViewModelStore;

        ......

        NonConfigurationInstances nci = new NonConfigurationInstances();
        nci.viewModelStore = viewModelStore;
        return nci;
    }

    static final class NonConfigurationInstances {
        ......
        ViewModelStore viewModelStore;
    }

就像昨晚说的那样，在这个方法内，会把ViewModelStore交给新创建的NonConfigurationInstances来保存，并返回了这个NonConfigurationInstances对象。

那么，这个方法会在哪里调用呢？

Activity的retainNonConfigurationInstances方法中：

    NonConfigurationInstances retainNonConfigurationInstances() {
        Object activity = onRetainNonConfigurationInstance();

        ......

        NonConfigurationInstances nci = new NonConfigurationInstances();
        nci.activity = activity;
        return nci;
    }

    static final class NonConfigurationInstances {
        Object activity;
        ......
    }

嗯，在retainNonConfigurationInstances方法里，又多套了一层，那这个方法又会在哪些调用呢？

ActivityThread的performDestroyActivity方法！

    ActivityClientRecord performDestroyActivity(IBinder token, boolean finishing, int configChanges, boolean getNonConfigInstance, String reason) {

        ActivityClientRecord r = mActivities.get(token);
            ......
        if (r != null) {
            ......
            r.lastNonConfigurationInstances = r.activity.retainNonConfigurationInstances();
            ......
        }
        mActivities.remove(token);
        return r;
    }

看吧，这样就把设置mRetainInstance为true的Fragment间接保存在ActivityClientRecord里了！

当执行完Destroy任务之后，接着会调用performLaunchActivity方法，并将刚刚performDestroyActivity方法返回的那个ActivityClientRecord对象传进去了：

    private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
        Activity activity = null;
        ......
        try {
            activity = mInstrumentation.newActivity(cl, component.getClassName(), r.intent);
        } catch (Exception e) {
        }
        ......
        try {
            if (activity != null) {
                ......
                activity.attach(appContext, this, getInstrumentation(), r.token, r.ident, app, r.intent, r.activityInfo, title, r.parent, r.embeddedID,
                r.lastNonConfigurationInstances, config, r.referrer, r.voiceInteractor, window, r.configCallback);
                ......
            }
        } catch (Exception e) {
        }
        ......
        return activity;
    }

看！在创建了新的Activity实例之后，又把刚刚存在ActivityClientRecord的那个lastNonConfigurationInstances取出来，并传进新Activity的attach方法里了：

    NonConfigurationInstances mLastNonConfigurationInstances;

    final void attach(Context context, ActivityThread aThread, Instrumentation instr, IBinder token, int ident, Application application, Intent intent, ActivityInfo info, CharSequence title, Activity parent, String id, NonConfigurationInstances lastNonConfigurationInstances, Configuration config, String referrer, IVoiceInteractor voiceInteractor, Window window, ActivityConfigCallback activityConfigCallback) {
        ......
        mLastNonConfigurationInstances = lastNonConfigurationInstances;
        ......
    }

emmm，在这个方法中，把lastNonConfigurationInstances赋值给Activity的成员变量mLastNonConfigurationInstances了，也就是说，原来在旧Activity中那些Fragment实例，现在已经传到了新的Activity里了。

传到新Activity之后，发生了什么？

现在，请看回上面 "mNonConfig初始化时有三个分支" 那一段！！！

懒得滑回去看的话，这里就直接说了：

还记不记得mNonConfig是一个ViewModel？

还记不记得，它会在创建时put到ComponentActivity的ViewModelStore里？

还记不记得，它里面有一个Fragment的集合，用来保存那些设置了RetainInstance为true的Fragment？

嗯！当FragmentActivity的onCreate回调时，会尝试从新Activity的mLastNonConfigurationInstances中拿出旧Activity的那个mNonConfig实例！并赋值给新Activity的mNonConfig！

恢复了mNonConfig实例后，接下来会发生什么？

其实还有很多代码要贴，起码200行吧，这里先偷个懒，直接用文字描述算了，嘿嘿~ 如果有同学想继续看，那就等我写完手头上的文章再补充。

恢复了mNonConfig实例后，会回调到FragmentManagerImpl的restoreSaveState方法，这个方法里面会做些什么呢？

会把mNonConfig里面的那些Fragment拿出来，放到FragmentManagerImpl的mActive中（mActive是一个HashMap<String, Fragment> ）。

接着，FragmentActivity会调用FragmentManagerImpl的dispatchCreate方法，把那些旧Fragment重新激活！

那么，从 “保存” 到 “恢复” 的整个流程，到这里就结束了。

把Fragment的RetainInstance设置为true，当Activity旋转后，Fragment对象会发生变化吗？

对象不会变，还是原来的实例。

但是在Activity Destroy时，这个Fragment却不会回调onDestroy，而是直接回调onDetach。

Activity作为Fragment的寄主，都销毁重建了，Fragment是怎么做到不重新创建对象的呢？

总的来说，也是通过onSaveInstanceState方法来保存实例的，当Activity重新创建的时候，会把存在Bundle里面的实例重新取出来（如果有的话），并回调对应的生命周期方法。

详细一点，是这样的（整个流程有点复杂，可能要多看几次才能理解。。。）：

在ComponentActivity（AppCompatActivity也是间接继承它的）中，有个成员变量ViewModelStore，这个ViewModelStore里面有个HashMap<String, ViewModel>，没错，就是用来保存ViewModel对象实例的；

在FragmentManager（Impl）中，有个成员变量FragmentManagerViewModel（继承自ViewModel），叫mNonConfig，它会在ComponentActivity的onCreate方法回调时初始化，注意！在它初始化的时候，还会顺便把它自身put到ComponentActivity的ViewModelStore里面的HashMap中！

刚刚说的FragmentManagerViewModel，它里面有个HashSet<Fragment>，叫mRetainedFragments，当我们调用Fragment的setRetainInstance方法时，如果传的是true的话，那么这个Fragment会顺便扔到前面说的mRetainedFragments中（注意！这个时候，那些设置了RetainInstance为true的Fragment，已经是间接存在于ComponentActivity的ViewModelStore中的了！）；

旋转屏幕的时候：

在ActivityThread performDestroyActivity时（Activity的onDestroy也是这个时候回调），ComponentActivity会把它的ViewModelStore（也就是间接保存了那些Fragment的那个实例），交给新创建的NonConfigurationInstances对象保管，而这个NonConfigurationInstances对象，最终会赋值给ActivityClientRecord的lastNonConfigurationInstances！

接着，ActivityThread会调用handleLaunchActivity方法，重新通过反射创建Activity实例，并调用Activity的attach方法（注意！调用attach方法时会把刚刚存在ActivityClientRecord中的lastNonConfigurationInstances（里面间接保存了那些Fragment）也传进去！）；

在Activity的attach方法里面，会把参数lastNonConfigurationInstances赋值给Activity的成员变量mLastNonConfigurationInstances！

当Activity的onCreate方法被回调时，在FragmentActivity（AppCompatActivity也是间接继承它的）中的实现，第一时间会初始化FragmentManager；

在初始化FragmentManager过程中，会顺便初始化刚刚说到的成员变量mNonConfig（也就间接保存那些Fragment的ViewModel）；

在初始化刚刚说到的成员变量mNonConfig时，会调用ComponentActivity（FragmentActivity继承自它）的getViewModelStore方法来获取上面说到的ViewModelStore对象！

getViewModelStore方法是怎么返回的呢？它会先尝试从Activity中的mLastNonConfigurationInstances（刚刚说attach方法时有介绍）里面获取！获取不到才创建新对象。这时候肯定能获取到了，那么现在的mNonConfig对象，就已经是旋转屏幕前的对象了！

还没完！接着，FragmentActivity会间接回调FragmentManager的restoreSaveState方法，这个方法是做什么的呢？

就是会把保存在mNonConfig中的HashSet<Fragment>里面那些Fragment（就是前面说的那些setRetainInstance为true的Fragment），全部重新添加到FragmentManager中！！！

源码分析明天再写，好困啊（我太难了）。

查看FragmentManager源码 -> saveNonConfig -> FragmentManagerNonConfig -> 存到了ActivityThread, 和ViewModel一样。

其实如果将这个命题改为 viewmodel 如何自动保存和恢复（config 变化时重建）的话，可能分析起来要简单些，然后再 扩展fragment 比较好理解，