每日一问 | Fragment 是如何被存储与恢复的？ 有更新

现在我们都知道，意外Destroy后重建的Activity，它原来已添加的那些 Fragment都会被恢复。

这个其实是依赖Bundle来实现的，也就是那些Fragment的相关信息，会在Activity的onSaveInstanceState方法回调时，put到参数outState（Bundle）里面。outState就是ActivityClientRecord的state：

public class ActivityThread {
      //保存Activity信息的Map
    final ArrayMap<IBinder, ActivityClientRecord> mActivities = new ArrayMap<>();

    public static final class ActivityClientRecord {
          //onSaveInstanceState方法中的outState参数所对应的实例
        Bundle state;
        //对应的Activity实例
        Activity activity;
        ......
    }

    public static void main(String[] args) {
        ......
        Looper.loop();
    }
}

而这些ActivityClientRecord实例，都存放在ActivityThread的mActivities里面。

看到了那个熟悉的main方法了吗？

我们可以把这个ActivityThread类当作普通的Java程序来看待，那些Activity只不过是在这个程序里面创建的一个个对象而已，这样的话，就不难理解为什么Activity因意外重建之后，它上次保存在Bundle中的数据还在了。

emmmm，那要是进程被意外杀死了呢？这时候ActivityThread都没了，它mActivities里面的ActivityClientRecord也会跟着没，像这种情况，那些数据还能恢复吗？

如果能的话，很多同学首先会想到的是：可能ActivityThread在临死前把那些数据交给了生命周期更长的进程（比如系统服务）来暂时保管，重新启动时，再把数据要回来。

真的是这样吗？

差不多，不过不是在ActivityThread临死前转交数据，而是在Activity的onSaveInstanceState和onStop方法回调之后，就转交了，因为这个时候Activity已经变得不可见了，有被Destroy的风险。

那它是怎么转交的呢？转交给谁？

先来看几张图：

这是我们的应用进程，现在假设onSaveInstanceState已回调，state已经保存了那些Fragment相关信息。

接着看系统服务那边：

咦，这里有个ActivityRecord，不但名字跟刚刚的ActivityClientRecord很像，而且它里面同样也有个Bundle对象。

没错了，等下ActivityClientRecord的state最终会赋值到ActivityRecord的icicle上的。

先熟悉一下这边的环境吧：

可以看到ActivityRecord的实例由TaskRecord的mActivities来保管，而TaskRecord则存放在ActivityStack的mTaskHistory里面（注意：ActivityRecord和TaskRecord并不是嵌套在ActivityStack中的内部类，把它画在里面只是为了更容易理解）。

ActivityRecord、TaskRecord、ActivityStack分别是什么来的？

• ActivityRecord是用来记录对应Activity的各种信息的，如theme，启动模式、当前是否可见等等（为了排版更简洁，上图只列出来一个icicle），它里面还有很多管理Activity状态的相关方法；

• TaskRecord就是大家耳熟能详的任务栈（从上图可以看出并不真的是栈）了，它的主要职责就是管理ActivityRecord。每当Activity启动时，会先找到合适的TaskRecord（或创建新实例），然后将该Activity所对应的ActivityRecord添加到TaskRecord的mActivities中；

• ActivityStack管理着TaskRecord，当新TaskRecord被创建后，会被添加到它mTaskHistory里面。

进一步了解：

篇幅稍长，为避免偏离主题，把这一小节放到下面一个单独的回答里了。

好我们继续：

可以看到ActivityStack存放在ActivityDisplay的一个List里面，这个ActivityDisplay有一系列操作ActivityStack的方法，比如创建、移除、更新位置等等。

接着往上看，ActivityDisplay的实例由RootActivityContainer保管（每个ActivityDisplay对象都对应着一张屏幕(显示屏)，所以一般情况下mActivityDisplays只有一个元素（一张屏幕））。 从这个类的名字可以大概知道，它就是Activity的最顶层容器了，没错，ActivityRecord那条关系链也到此为止，即：

RootActivityContainer -> ActivityDisplay -> ActivityStack -> TaskRecord -> ActivityRecord。

这五个都是继承自ConfigurationContainer（上个小节有讲解），把它们归为一类不算过分。

RootActivityContainer的上级：ActivityStackSupervisor，从名字上来看，它的职责应该是管理ActivityStack的，在这个类刚出现的时候（4.4(SDK19)，主要是处理ActivityStack、ActivityTask、ActivityRecord相关的业务，比如移动Task/Stack位置、移除Task/Stack，获取/查找各种状态的Task/Stack/Record实例等，功能比较纯粹。但随着版本迭代，它的功能也越来越多，越来越杂，就连Google的工程师也吐槽说这个类快变成垃圾场了。。。

所以在下个版本这个类很有可能会大改。

最外面的ActivityTaskManagerService，大家应该都会觉得挺眼熟（跟AMS的名字差不多，这个类和刚刚的RootActivityContainer一样，都是SDK 29后新增的），它其实就是分担了AMS（ActivityManagerService）的一部分工作而已（当然了，也有不少新东西，但这不是本篇回答的重点，就不多扯了，感兴趣的同学可以去比较一下它们的AIDL文件：IActivityManager.aidl（SDK 28）、IActivityManager.aidl（SDK 29）、IActivityTaskManager.aidl（SDK 29）（注意：它现在级别跟AMS一样，已经是一个系统服务了）），在此之前，各种startActivity还有那些处理Activity的Resume、Pause、Stop、Destroy等工作都是在AMS里面调度的，现在Google把一部分方法移到了ActivityTaskManager中，可能是它觉得AMS也太臃肿了吧。

重点来了：

（原来在ActivityManagerService中的activityStopped方法，现在也搬到ActivityTaskManagerService上了。）

就像前面说的那样，当Activity变得不可见时（onSaveInstanceState和onStop回调之后），在应用进程这边会通过ActivityTaskManagerService的activityStopped方法，把刚刚在onSaveInstanceState中满载了数据的Bundle对象，传到系统服务进程那边！ 然后（在系统服务进程这边），会进一步将这个Bundle对象，赋值到对应ActivityRecord的icicle上！就像这样：

嗯，很直观吧。

那么，这个数据是怎么恢复的呢？

很快就好。

进一步了解ActivityRecord、TaskRecord、ActivityStack：

这三个类之间有个共同点：都是继承自ConfigurationContainer，从字面意思可以知道是配置容器，那它包括了哪些配置呢：

• 字体缩放比例；
• 移动国家码(MCC)、移动网络码(MNC)；
• 区域(语言)；
• 颜色模式(饱和度、HDR)；
• 屏幕布局(尺寸(小中大超大)、是否宽屏或长屏幕、布局方向(从左到右、从右到左)、是否圆角屏幕)；
• Window边界范围(l, t, r, b)、Window方向；
• Window显示模式(全屏、画中画、分屏模式-主屏幕、分屏模式-副屏幕、自由拖动)；
• Activity类型(普通、启动器/桌面、最近任务/任务管理器、语音助手)；
• 触屏类型(无触屏、手写笔、手指)；
• 键盘类型(无键盘、QWERTY键盘、12键)、键盘是否可用/弹出；
• 非触摸导航设备(无、方向键(上下左右确定返回)、轨迹球、方向盘)
• UI类型(普通(常规手机)、桌面(电脑版)、车载、智能电视、嵌入式终端机、智能手表、VR设备)、UI模式(日间、夜间)；
• 屏幕密度、可用屏幕宽度、可用屏幕高度；

大概了解一下就可以了~

这个ConfigurationContainer还有三个抽象方法：

public abstract class ConfigurationContainer<E extends ConfigurationContainer> {

    abstract protected int getChildCount();

    abstract protected E getChildAt(int index);

    abstract protected ConfigurationContainer getParent();
}

来看看在三个类中分别是怎么实现的：

ActivityRecord:

final class ActivityRecord extends ConfigurationContainer { 

    private TaskRecord task;

    @Override
    protected int getChildCount() {
        return 0;
    }

    @Override
    protected ConfigurationContainer getChildAt(int index) {
        return null;
    }

    @Override
    protected ConfigurationContainer getParent() {
        return getTaskRecord();
    } 

    TaskRecord getTaskRecord() {
        return task;
    }
}

嗯，因为它最弟弟，没有辈分比它更小的了，所以getChildAt方法返回null，getChildCount是0。

还可以看到它持有一个TaskRecord的引用，这个就是它所属的任务栈了，所以在getParent方法也返回了这个对象。

看下TaskRecord：

class TaskRecord extends ConfigurationContainer { 

    private ActivityStack mStack;

    @Override
    protected int getChildCount() {
        return mActivities.size();
    }

    @Override
    protected ActivityRecord getChildAt(int index) {
        return mActivities.get(index);
    }

    @Override
    protected ConfigurationContainer getParent() {
        return mStack;
    }
}

很容易理解，TaskRecord管理着ActivityRecord，getChildAt方法直接在mActivities里面取对应元素了，它的Parent就是ActivityStack：

class ActivityStack extends ConfigurationContainer {

    private final ArrayList<TaskRecord> mTaskHistory = new ArrayList<>();
    protected final RootActivityContainer mRootActivityContainer;

    @Override
    protected int getChildCount() {
        return mTaskHistory.size();
    }

    @Override
    protected TaskRecord getChildAt(int index) {
        return mTaskHistory.get(index);
    }

    @Override
    protected ActivityDisplay getParent() {
        return getDisplay();
    }

    ActivityDisplay getDisplay() {
        return mRootActivityContainer.getActivityDisplay(mDisplayId);
    }    
}

咦，ActivityStack的getParent方法返回的是ActivityDisplay对象，那就说明它对应的上一级是ActivityDisplay了，ActivityDisplay在那里呢？

ActivityDisplay里面有个叫mStacks的List，那些ActivityStack就是存放在这里的。

有同学可能会有这样疑惑：

ActivityRecord对应着一个Activity实例，TaskRecord对应着一个任务栈，这两个都很容易理解为什么要用List来装（因为它们都可以同时存在多个），但ActivityStack为什么也要用List来装呢？（感觉现在一个实例都已经够用了啊，都能把系统中所有Activity和Task存起来了）

这是因为【Google写成这样是为了方便以后扩展，现在暂时没有用到】还是说【在某种情况下确实需要用到多个实例】呢？

如果ActivityStack会有多个，那应该怎么理解？在什么情况下会出现多个实例？

其实是这样的：

虽然它名字里有Stack这个词（从名字上来看会让人觉得它跟堆栈有关），但实际上它更像是一个【工作区】，玩过Linux桌面系统的同学应该对工作区不陌生：

工作区可以让你在桌面中不重叠地开启多个最大化窗口（就像把一张屏幕，变成了多张屏幕一样），还可以通过快捷键在不同工作区之间自由来回切换，极大地提升了工作效率。

而且每个工作区都是一个相对独立的空间——按下alt + tab只能切换当前所在工作区中的窗口，起到一个隔离的作用。

emmmm，也许Google爸爸正是为了能把不同类型的Activity归类（隔离）起来，才把ActivityStack用List装的吧。

当Activity启动时，系统会根据该Activity的类型和Window显示模式（忘了有哪些类型和模式的同学请自觉滑回上面列出的ConfigurationContainer配置那里）来决定它所对应的TaskRecord应该放在哪个Stack（如果没有合适的就创建）。

我分别看了27、28、29这三个版本的SDK源码，发现【27】和【28、29】在为TaskRecord选择Stack时的策略是有些区别的。

先说相同的地方，相同的地方是它们都会为特定的Activity类型和Window显示模式来准备一些专属的Stack，比如：

• HOME_STACK（启动器/桌面专属Stack）；
• RECENTS_STACK（ 最近任务/任务管理器专属）；
• ASSISTANT_STACK（语音助手专属）；
• FULLSCREEN_WORKSPACE_STACK（全屏应用专属）；
• PINNED_STACK（画中画专属）；
• FREEFORM_WORKSPACE_STACK（自由拖动窗口专属）；

画中画在日常开发中是比较少机会能接触到，但大家一定都体验过，比如微信视频通话时，右上角的那个浮动小窗，就是画中画模式。还有在YouTube客户端中按下HOME键后，正在播放的视频会以小窗形式呈现在右下角，这个小窗同样也是通过画中画模式来实现的。

自由拖动的窗口在手机上更罕见，它是这样的：

就像桌面版系统一样，可以自由拖动和缩放窗口。只是因为手机屏幕小，这个选项默认是关闭的，要开启来体验下的同学可以在连接手机后，打开AS底部的Terminal窗口，把下面的命令粘贴上去然后回车等待手机重启就行了。

shell script adb shell settings put global enable_freeform_support 1 && adb shell sleep 2 && adb reboot

这条命令就是把系统设置里的enable_freeform_support选项改成1并在2秒后重启的意思。

好，回到上一个话题，除了这些专属Stack，还有一种 "通用" 的Stack，它们的ID是动态分配的，所以叫DYNAMIC_STACK。一般情况下，普通类型的Activity所属TaskRecord都是放在这些Stack里面的，当系统在为这些TaskRecord选择Stack时，会先判断能不能直接放置在callingActivity(即调用startActivity的那个Activity)所属Stack上，如果不能，则检查当前是否处于分屏模式，是的话就会进一步检查主屏幕Stack是否存在，存在就直接放置在副屏幕Stack上（不存在则创建）。如果没有开启分屏模式，则倒序遍历ActivityDisplay(当前所在屏幕)的mStacks，并逐个判断Stack是否上面列出的专属Stack之一，如果不是：

• SDK 27的做法是，进一步判断这个Stack是否DYNAMIC_STACK，是则直接重用。要是到最后也没找到DYNAMIC_STACK，就会创建新的实例。
• SDK 28、29则会对这个Stack的类型和目标Activity类型进行匹配，比如，当前遍历到的Stack它的类型是HOME_STACK，那么目标Activity类型也必须是 启动器/桌面 类型才能重用。如果当前Stack类型不是上面列出的几个专属Stack，则会检查它的Window显示模式是否分屏模式，都不是的话，就创建新Stack（注意：因为一开始已经是判断了不是分屏模式才会遍历ActivityDisplay的mStacks，所以如果此时启动的是普通类型的Activity，就每次都会创建新Stack（因为都不符合重用的条件，不知道这是Bug还是Google有意为之））。

现在我们知道了SDK【27】和【28、29】在选择Stack时的主要区别就是DYNAMIC_STACK的创建时机。如果同时开启多个普通应用，一般情况下，【28、29】版本的Stack数量是要比【27】多的。

小结：

• ActivityRecord、TaskRecord、ActivityStack这三个类都是继承自ConfigurationContainer；
• ConfigurationContainer里面记录着各种系统特征、状态和Activity信息；
• ActivityStack的getChildAt方法返回TaskRecord对象，TaskRecord的getChildAt方法返回ActivityRecord对象；
• ActivityStack用List来装，是因为系统要将不同类型/Window显示模式的Activity像工作区那样归类/隔离起来；
• 一般情况下（没有开启分屏或自由拖动等模式），在SDK【28、29】上，每个普通应用进程都会独占一个ActivityStack，而【27】版本则会共用一个DYNAMIC_STACK；

先回答问题三：如何恢复？

首先是在FragmentActivity的onSaveInstanceState中：

@Override
protected void onSaveInstanceState(Bundle outState) {
    super.onSaveInstanceState(outState);
    markFragmentsCreated();
    Parcelable p = mFragments.saveAllState();
    if (p != null) {
        outState.putParcelable(FRAGMENTS_TAG, p);
    }
    // ....
}

发现调用了mFragments.saveAllState()，这个mFragments是一个FragmentController，最后会调用到FragmentManager.saveAllState()

Parcelable saveAllState() {
    // Make sure all pending operations have now been executed to get
    // our state update-to-date.
    forcePostponedTransactions();
    endAnimatingAwayFragments();
    execPendingActions();
    mStateSaved = true;
    mSavedNonConfig = null;
    if (mActive == null || mActive.size() <= 0) {
        return null;
    }

    // First collect all active fragments.
    int N = mActive.size();
    FragmentState[] active = new FragmentState[N];
    boolean haveFragments = false;
    for (int i=0; i<N; i++) {
        Fragment f = mActive.valueAt(i);
        if (f != null) {
            haveFragments = true;

            FragmentState fs = new FragmentState(f);
            active[i] = fs;
            if (f.mTarget != null) {
                if (fs.mSavedFragmentState == null) {
                    fs.mSavedFragmentState = new Bundle();
                }
                putFragment(fs.mSavedFragmentState, FragmentManagerImpl.TARGET_STATE_TAG, f.mTarget);
                if (f.mTargetRequestCode != 0) {
                    fs.mSavedFragmentState.putInt(FragmentManagerImpl.TARGET_REQUEST_CODE_STATE_TAG, f.mTargetRequestCode);
                }
            }
            // 省略大量代码
        }
    }
    // 省略大量代码：保存其他信息

    FragmentManagerState fms = new FragmentManagerState();
    fms.mActive = active;
    fms.mAdded = added;
    fms.mBackStack = backStack;
    if (mPrimaryNav != null) {
        fms.mPrimaryNavActiveIndex = mPrimaryNav.mIndex;
    }
    fms.mNextFragmentIndex = mNextFragmentIndex;
    saveNonConfig();
    return fms;
}

FragmentState和FragmentManagerState都是Parcelable，在里面保存信息到Parcel，这个信息最后是保存在AMS里的。

然后看看恢复，在FragmentActivity.onCreate()里，有个参数叫savedInstanceState，是个Bundle，可以获取到保存的信息：

protected void onCreate(@Nullable Bundle savedInstanceState) {
    // ...
    if (savedInstanceState != null) {
        Parcelable p = savedInstanceState.getParcelable(FRAGMENTS_TAG);
        mFragments.restoreAllState(p, nc != null ? nc.fragments : null);
        // ...
    }
    // ...
}

进入到FragmentManager.restoreAllState()：

void restoreAllState(Parcelable state, FragmentManagerNonConfig nonConfig) {
    if (state == null) return;
    FragmentManagerState fms = (FragmentManagerState)state;
    if (fms.mActive == null) return;
    // First re-attach any non-config instances we are retaining back
    // to their saved state, so we don't try to instantiate them again.
    if (nonConfig != null) {
        // 省略
    }
    // Build the full list of active fragments, instantiating them from
    // their saved state.
    mActive = new SparseArray<>(fms.mActive.length);
    for (int i=0; i<fms.mActive.length; i++) {
        FragmentState fs = fms.mActive[i];
        if (fs != null) {
            FragmentManagerNonConfig childNonConfig = null;
            if (childNonConfigs != null && i < childNonConfigs.size()) {
                childNonConfig = childNonConfigs.get(i);
            }
            ViewModelStore viewModelStore = null;
            if (viewModelStores != null && i < viewModelStores.size()) {
                viewModelStore = viewModelStores.get(i);
            }
            Fragment f = fs.instantiate(mHost, mContainer, mParent, childNonConfig, viewModelStore);
            mActive.put(f.mIndex, f);
            fs.mInstance = null;
        }
    }
    // 省略
}

在FragmentState里会重建Fragment，并且恢复保存的状态信息：

public Fragment instantiate(FragmentHostCallback host, FragmentContainer container,
    Fragment parent, FragmentManagerNonConfig childNonConfig, ViewModelStore viewModelStore) {
    if (mInstance == null) {
        if (container != null) {
            mInstance = container.instantiate(context, mClassName, mArguments);
        } else {
            mInstance = Fragment.instantiate(context, mClassName, mArguments);
        }
        // 省略：恢复状态信息
    }
    return mInstance;
}

继续深入看看是怎么重建的Fragment：

public static Fragment instantiate(Context context, String fname, @Nullable Bundle args) {
    try {
        Class<?> clazz = sClassMap.get(fname);
        if (clazz == null) {
            // Class not found in the cache, see if it's real, and try to add it
            clazz = context.getClassLoader().loadClass(fname);
            sClassMap.put(fname, clazz);
        }
        Fragment f = (Fragment) clazz.getConstructor().newInstance();
        if (args != null) {
            args.setClassLoader(f.getClass().getClassLoader());
            f.setArguments(args);
        }
        return f;
    } // 省略：异常处理
}

这里通过反射机制重新创建出了一个Fragment。

恢复的流程大概就是这样，当然省略了很多细节，感兴趣的可以自己去跟踪。

然后回答一下问题二：Fragment 恢复是真的和重建前使用的是同一个对象吗？

有两种情况：

• 设置了RetainInstance，并且进程还在：

  设置了RetainInstance，Fragment会被保存到nonConfig里，重建时会直接拿出这个已有的Fragment，不会重新创建。

  这里可以看看之前的一个问答：Activity 都重建了，你 Fragment凭什么活着？，大佬的讲解很详细，我就不班门弄斧啦。

• 没有设置RetainInstance，或者进程已经被kill掉了：

  这种情况下，没有可以直接获得的Fragment，会通过反射创建出一个新的Fragment，这个fragment肯定和之前那个不是同一个对象。

我的理解大概就是这样，如果有什么错误欢迎指出~

（另外说句题外话，洋神能审核一下后台吗，我分享了几篇觉得还不错的文章来着）

保存在ActivityRecord中的数据是如何恢复的？

假设应用进程(有Activity)在后台运行(按了HOME键)时，因系统内存不足被强行结束，一段时间后重新启动，那么：

既然是重新启动进程，那肯定会执行到ActivityThread的main方法，我们就从这个main方法开始，顺藤摸瓜：

public final class ActivityThread extends ClientTransactionHandler {

    public static void main(String[] args) {
        ......
        Looper.prepareMainLooper();
        ......  
        ActivityThread thread = new ActivityThread();
        thread.attach(false, startSeq);
        ......  
        Looper.loop();

        throw new RuntimeException("Main thread loop unexpectedly exited");
    }

}

相信这段代码大家都看得想吐了吧。。。几乎每一篇【Handler机制分析】还有【为什么Looper.loop不会卡死】的文章都有它的身影，而我们这次同样也绕不开它。

可以看到在Looper初始化了之后，会创建一个ActivityThread对象，并调用它的attach方法：

public final class ActivityThread extends ClientTransactionHandler {

    final ApplicationThread mAppThread = new ApplicationThread();

    private void attach(boolean system, long startSeq) {
        ......
        if (!system) {
            ......
            final IActivityManager mgr = ActivityManager.getService();
            try {
                mgr.attachApplication(mAppThread, startSeq);
            } catch (RemoteException ex) {
                throw ex.rethrowFromSystemServer();
            }
            ......
        } else {
            ......
        }
    }    
}

刚刚调用attach方法时，第一个参数system传的是false（表示启动的是普通应用而非系统进程），所以会进入if里面。

在if里面会调用IActivityManager的attachApplication方法，并将ApplicationThread的实例传了过去，那现在就到了系统服务AMS那边咯：

public class ActivityManagerService extends IActivityManager.Stub {

    public ActivityTaskManagerInternal mAtmInternal;

    public ActivityManagerService(...){
         mAtmInternal = LocalServices.getService(ActivityTaskManagerInternal.class);
    }

    @Override
    public final void attachApplication(
            IApplicationThread thread, long startSeq) {
        ......
        attachApplicationLocked(thread, callingPid, callingUid, startSeq);
        ......
    }

    private final boolean attachApplicationLocked(
            IApplicationThread thread, int pid, 
            int callingUid, long startSeq) {
        ......
        else if (instr2 != null) {
            thread.bindApplication(...);
        } else {
            thread.bindApplication(...);
        }
        ......
        mAtmInternal.attachApplication(...);
        ......
    }
}

attachApplication里面会调用attachApplicationLocked，这个方法里面会先回调ApplicationThread的bindApplication（ContentProvider和Application就是在bindApplication时初始化的）。

现在看最后一行，那个mAtmInternal，其实是ActivityTaskManagerService的内部类LocalService：

public class ActivityTaskManagerService extends IActivityTaskManager.Stub {

    RootActivityContainer mRootActivityContainer;

    class LocalService extends ActivityTaskManagerInternal {

        ......

        @Override
        public boolean attachApplication(ProcessController wpc) {
            return mRootActivityContainer.attachApplication(wpc);
        }
    }
}

它直接调用了RootActivityContainer的attachApplication方法：

class RootActivityContainer extends ConfigurationContainer
        implements DisplayManager.DisplayListener {

    ActivityStackSupervisor mStackSupervisor;
    private final ArrayList<ActivityDisplay> mActivityDisplays = new ArrayList<>();

    boolean attachApplication(WindowProcessController app) throws RemoteException {
        final String processName = app.mName;
        boolean didSomething = false;
        for (int displayNdx = mActivityDisplays.size() - 1; displayNdx >= 0; --displayNdx) {
            final ActivityDisplay display = mActivityDisplays.get(displayNdx);
            final ActivityStack stack = display.getFocusedStack();
            if (stack != null) {
                stack.getAllRunningVisibleActivitiesLocked(mTmpActivityList);
                final ActivityRecord top = stack.topRunningActivityLocked();
                final int size = mTmpActivityList.size();
                for (int i = 0; i < size; i++) {
                    final ActivityRecord activity = mTmpActivityList.get(i);
                    if (activity.app == null && app.mUid == activity.info.applicationInfo.uid
                            && processName.equals(activity.processName)) {
                        ......
                        if (mStackSupervisor.realStartActivityLocked(activity, app,
                                top == activity /* andResume */, true /* checkConfig */)) {
                            didSomething = true;
                        }
                        ......
                    }
                }
            }
        }
        return didSomething;
    }
}

这个方法稍微有点复杂，它大概做了这几件事：

1. 遍历mActivityDisplays集合（大多数情况下只有一个实例，对应一张屏幕），从ActivityDisplay.mStacks中查找当前持有焦点的Stack（如果没有找到，会获取mStacks最后一个可见且可接受焦点的Stack实例）；

2. 如果能找到符合条件的Stack，会进一步将这个Stack里面的TaskRecord（任务栈）中的ActivityRecord实例放到mTmpActivityList中，当然了，这些ActivityRecord必须是没有finish并且可以正常显示内容的（注意！现在这些实例，都是现成的，不是新创建的！也就是说，上一次被Kill了的Application它所创建的那些Activity对应的Records也还在这里！）；

3. 遍历mTmpActivityList，判断mTmpActivityList中每一个ActivityRecord对象是否符合startActivity的条件（条件为：当前没有被其他Application持有，并且用户ID和进程名都一样），符合的话会调用realStartActivityLocked方法，把ActivityRecord传进去。注意看第三个参数andResume，它是判断当前activity是不是top，这个top就是当前任务栈顶的那个ActivityRecord实例，意思是：如果start栈顶的Activity，那就要把生命周期设置为Resumed状态，其他的都是Paused；

好了，来看看这个realStartActivityLocked方法：

public class ActivityStackSupervisor implements RecentTasks.Callbacks {

    final ActivityTaskManagerService mService;

    boolean realStartActivityLocked(ActivityRecord r, WindowProcessController proc,
                                    boolean andResume, boolean checkConfig) throws RemoteException {

        ......

        try {
            // Create activity launch transaction.
            final ClientTransaction clientTransaction = ClientTransaction.obtain(
                    proc.getThread(), r.appToken);

            clientTransaction.addCallback(LaunchActivityItem.obtain(new Intent(r.intent),
                    System.identityHashCode(r), r.info,
                    mergedConfiguration.getGlobalConfiguration(),
                    mergedConfiguration.getOverrideConfiguration(), r.compat,
                    r.launchedFromPackage, task.voiceInteractor, proc.getReportedProcState(),
                    r.icicle, r.persistentState, results, newIntents,
                    dc.isNextTransitionForward(), proc.createProfilerInfoIfNeeded(),
                    r.assistToken));

            // Set desired final state.
            final ActivityLifecycleItem lifecycleItem;
            if (andResume) {
                lifecycleItem = ResumeActivityItem.obtain(dc.isNextTransitionForward());
            } else {
                lifecycleItem = PauseActivityItem.obtain();
            }
            clientTransaction.setLifecycleStateRequest(lifecycleItem);

            // Schedule transaction.
            mService.getLifecycleManager().scheduleTransaction(clientTransaction);

        } catch (RemoteException e) {
            if (r.launchFailed) {
                // This is the second time we failed -- finish activity and give up.
                Slog.e(TAG, "Second failure launching "
                        + r.intent.getComponent().flattenToShortString() + ", giving up", e);
                proc.appDied();
                stack.requestFinishActivityLocked(r.appToken, Activity.RESULT_CANCELED, null,
                        "2nd-crash", false);
                return false;
            }

            // This is the first time we failed -- restart process and
            // retry.
            r.launchFailed = true;
            proc.removeActivity(r);
            throw e;
        }

        ......

        return true;
    }
}

代码有点长，但逻辑很清晰：

首先是创建了一个ClientTransaction对象，并给它添加了Callback和通过setLifecycleStateRequest方法传进去了一个ActivityLifecycleItem对象实例。接着会调用ClientLifecycleManager的scheduleTransaction方法，把这个ClientTransaction对象传了进去。

可以看到这里还对异常做了处理：如果在scheduleTransaction（跨进程通讯）过程中发生了异常（比如常见的TransactionTooLargeException），会立即重启目标进程，然后进行第二次尝试，如果第二次还是出了异常的话，就会强行结束掉目标进程。这里就可以解释另一个问题中的：为什么startActivity时Intent携带512K的数据，进程会突然闪退而且Logcat中看不到Log？

刚刚提到的几个陌生的类：ClientTransaction、ActivityLifecycleItem、ClientLifecycleManager，是SDK 28（即 9.0）之后才有的。这里有必要先讲一下它们之间的关系以及各自的作用（特意网上搜了下，发现网上还没有讲解这一块知识的相关文章，嘿嘿~）：

我们不妨把这些类代入到烟花从制造，到销售，再到燃放的各个环节中。

首先是制造烟花：

烟花就是ClientTransactionItem，上面说的Callback和ActivityLifecycleItem，它们都继承自抽象类ClientTransactionItem：

左边蓝色的几个，就是那些Callback了（因位置有限只列举了五个比较有代表性的实现类），这些Callback的主要作用就是通知/控制ActivityThread进行相关操作（等下会详细说）。

右边的ActivityLifecycleItem依然是一个抽象类，由四个子类来实现，分别对应Activity的四个状态：Running、Paused、Stopped、Destroyed。ActivityLifecycleItem还比左边的Callback多了一样东西：TargetState（目标生命周期），等下详细讲解。

Callback和ActivityLifecycleItem的父类ClientTransactionItem，继承了BaseClientRequest接口：

它有三个方法，注意，除execute之外，其余两个（preExecute和postExecute）都是有default修饰（默认空实现）的，所以我们等下重点看子类实现的execute方法就行了。

（这个execute方法的实现，代表着烟花绽放的形状）

嗯，烟花做好了之后，接下来是打包装（ClientTransaction）：

可以看到这个ClientTransaction把ActivityLifecycleItem和Callback都装了进去（注意Callback是一个List，表示可以有多个Callback，不过大部分情况下只会有一个）。

好了，打包完，是时候把它运到档口销售了：

点击打开原图

烟花 （ClientTransactionItem） 打包 （ClientTransaction） 完成之后，厂家 （ClientLifecycleManager） 会把它交给中转站 （ApplicationThread） ，中转站通过有关部门 （ClientTransactionHandler） 的安全检查 （ClientTransactionItem.preExecute） 之后，就会允许在烟花店 （ActivityThread.H） 里销售。最后，顾客 （TransactionExecutor） 会从烟花店中把烟花买回来燃放 （ClientTransactionItem.execute），放完之后，自然就把烟花壳扔掉了 （ClientTransactionItem.postExecute）。

哈哈，整个流程就是这样。

Android 9.0之后，把ActivityThread一部分方法抽象了一下，放在ClientTransactionHandler里面（依然由ActivityThread去实现）：

public abstract class ClientTransactionHandler {

    void scheduleTransaction(ClientTransaction transaction) {
        transaction.preExecute(this);
        sendMessage(ActivityThread.H.EXECUTE_TRANSACTION, transaction);
    }

    public abstract Activity handleLaunchActivity(...);

    public abstract void performRestartActivity(...);

    public abstract void handleStartActivity(...);

    public abstract void handleResumeActivity(...);

    public abstract void handlePauseActivity(...);

    public abstract void handleStopActivity(...);

    public abstract void handleDestroyActivity(...);

    public abstract void handleRelaunchActivity(...);

    public abstract void handleTopResumedActivityChanged(...);

    public abstract void handleWindowVisibility(...);

    public abstract void handleSendResult(...);

    public abstract void handleActivityConfigurationChanged(...);

    ......
}

而那些Callback和ActivityLifecycleItem的execute方法的实现，其实就是直接调用上面这些抽象出来的方法而已，比如LaunchActivityItem：

public class LaunchActivityItem extends ClientTransactionItem {

    @Override
    public void execute(ClientTransactionHandler client, IBinder token,
            PendingTransactionActions pendingActions) {

        ActivityClientRecord r = new ActivityClientRecord(token, mIntent, mIdent, mInfo,
                mOverrideConfig, mCompatInfo, mReferrer, mVoiceInteractor, mState, mPersistentState,
                mPendingResults, mPendingNewIntents, mIsForward,
                mProfilerInfo, client, mAssistToken);

        client.handleLaunchActivity(r, pendingActions, null /* customIntent */);
    }    
}

看吧，在创建了ActivityClientRecord对象之后就直接调用了ClientTransactionHandler（ActivityThread）的handleLaunchActivity方法。

像其他的TopResumedActivityChangeItem、WindowVisibilityItem也有对应的方法：handleWindowVisibility、handleTopResumedActivityChanged

ActivityLifecycleItem那四个子类就更不用说了。

emmmm，前面说到，ActivityLifecycleItem会比Callbacks多携带一个东西：TargetState，这个是做什么用的呢？

其实是这样的：

ActivityLifecycleItem的目的就是切换目标Activity的状态（Running、Paused、Stopped、Destroyed）。

比如Activity当前状态是Running，要把它切换到Destroyed的话，就可以打包一个DestroyActivityItem。

但是DestroyActivityItem的execute方法里面只会调用ActivityThread的handleDestroyActivity方法，众所周知，Activity从Running到Destroyed，中间还会经过onPause和onStop，那中间空缺的这两个回调，怎么补上呢？

这时候就需要一个TargetState来告诉TransactionExecutor最终会停留在哪个状态，TransactionExecutor的cycleToPath方法会根据这个TargetState来平滑生命周期，比如一个状态为Running的Activity，在TransactionExecutor接收到DestroyActivityItem后，调用ActivityThread的handleDestroyActivity方法之前，会先通过TransactionExecutorHelper的getLifecyclePath方法来计算出中间需要补上哪些回调，然后在performLifecycleSequence方法中把这些回调补上，最后才执行DestroyActivityItem的execute也就是ActivityThread的handleDestroyActivity方法。

好了，现在算是把整个流程搞清楚了，继续回到上面的realStartActivityLocked方法：

public class ActivityStackSupervisor implements RecentTasks.Callbacks {

    final ActivityTaskManagerService mService;

    boolean realStartActivityLocked(ActivityRecord r, WindowProcessController proc,
                                    boolean andResume, boolean checkConfig) throws RemoteException {

        ......

         // Create activity launch transaction.
         final ClientTransaction clientTransaction = ClientTransaction.obtain(
                 proc.getThread(), r.appToken);

         clientTransaction.addCallback(LaunchActivityItem.obtain(new Intent(r.intent),
                 System.identityHashCode(r), r.info,
                 mergedConfiguration.getGlobalConfiguration(),
                 mergedConfiguration.getOverrideConfiguration(), r.compat,
                 r.launchedFromPackage, task.voiceInteractor, proc.getReportedProcState(),
                 r.icicle, r.persistentState, results, newIntents,
                 dc.isNextTransitionForward(), proc.createProfilerInfoIfNeeded(),
                 r.assistToken));

         // Set desired final state.
         final ActivityLifecycleItem lifecycleItem;
         if (andResume) {
             lifecycleItem = ResumeActivityItem.obtain(dc.isNextTransitionForward());
         } else {
             lifecycleItem = PauseActivityItem.obtain();
         }
         clientTransaction.setLifecycleStateRequest(lifecycleItem);

         // Schedule transaction.
         mService.getLifecycleManager().scheduleTransaction(clientTransaction);

        ......

        return true;
    }
}

现在看起来就很轻松：

它首先是给ClientTransaction打包了一个LaunchActivityItem，再打包ResumeActivityItem（假设andResume为true，即栈顶的Activity）。

LaunchActivityItem是Callback，所以会比ResumeActivityItem（ActivityLifecycleItem）先执行，那么，当这个烟花包（ClientTransaction）在应用进程那边被顾客（TransactionExecutor）拆开时，会依次做这几件事：

1. Callback：ActivityThread.handleLaunchActivity（里面会回调对应Activity的onCreate方法）；
2. 因为ResumeActivityItem所对应的生命周期是ON_RESUME，中间还缺了个ON_START，所以ActivityThread.handleStartActivity会在TransactionExecutor的performLifecycleSequence方法中先被调用；
3. 当Activity的onStart回调之后，会检测这个Activity所对应的ActivityClientRecord有没有上次保存了的Bundle，如果有的话，就会回调onRestoreInstanceState方法，把上一次的Bundle传进去！
4. 最后到ResumeActivityItem.execute，这方法里面会调用ActivityThread.handleResumeActivity方法；

这样，Activity就正常启动了。

第3点说到，Activity的onStart回调之后，会检测这个Activity是否有上次保存了的Bundle，那么，这个Bundle数据是怎么来的呢？

上次介绍恢复流程的时候讲过，Activity的onSaveInstanceState方法参数中的那个Bundle实例，最终会保存到系统服务进程那边的ActivityRecord.icicle里面。

现在，请继续看上面的realStartActivityLocked方法：

在创建LaunchActivityItem对象的时候，是不是把ActivityRecord的icicle传进了LaunchActivityItem的obtain方法中？！

来看一下这个LaunchActivityItem：

public class LaunchActivityItem extends ClientTransactionItem {

    private Bundle mState;
    ......

    @Override
    public void execute(ClientTransactionHandler client, IBinder token,
                        PendingTransactionActions pendingActions) {
        Trace.traceBegin(TRACE_TAG_ACTIVITY_MANAGER, "activityStart");
        ActivityClientRecord r = new ActivityClientRecord(token, mIntent, mIdent, mInfo,
                mOverrideConfig, mCompatInfo, mReferrer, mVoiceInteractor, mState, mPersistentState,
                mPendingResults, mPendingNewIntents, mIsForward,
                mProfilerInfo, client, mAssistToken);
        client.handleLaunchActivity(r, pendingActions, null /* customIntent */);
        Trace.traceEnd(TRACE_TAG_ACTIVITY_MANAGER);
    }

    public static LaunchActivityItem obtain(..., Bundle state, ...) {
        LaunchActivityItem instance = ObjectPool.obtain(LaunchActivityItem.class);
        if (instance == null) {
            instance = new LaunchActivityItem();
        }
        setValues(instance, intent, ident, info, curConfig, overrideConfig, compatInfo, referrer,
                voiceInteractor, procState, state, persistentState, pendingResults,
                pendingNewIntents, isForward, profilerInfo, assistToken);

        return instance;
    }

    private static void setValues(LaunchActivityItem instance, ..., Bundle state, ....) {

        ......

        instance.mState = state;

        ......

    }
}

obtain方法里面会通过setValues方法给LaunchActivityItem的属性赋值，那个mState对应的就是ActivityRecord.icicle！

当TransactionExecutor执行它的execute方法时，就会把这个mState进一步传到新创建的ActivityClientRecord对象里面！这样，原来保存在系统进程的Bundle，就重新交回到应用进程了！在Activity的onStart回调之后，这个Bundle就会传到Activity的onRestoreInstanceState方法中！

总结：

Activity的数据是怎么保存的？

Activity切换到Stopped状态时，会回调onSaveInstanceState方法，接着，这个方法参数中的Bundle对象，会通过Binder传到系统服务进程那边，保存在ActivityRecord.icicle中。

进程被Kill后，保存的数据是怎么恢复的？

因为这些数据保存在系统服务进程，所以无论应用进程怎么被Kill，那些保存了的数据也还在。

当进程的Activity重新启动，RootActivityContainer会优先查找已存在的对应的ActivityRecord（如果上一次是被意外杀死，那么对应的ActivityRecord肯定还在的）;

找到之后，会按照正常流程启动Activity，上次保存在icicle的那些数据，也会跟随LaunchActivityItem一起被带到应用进程中；

应用进程接收到此LaunchActivityItem后，会调用ActivityThread的handleLaunchActivity方法，这个方法需要一个ActivityClientRecord对象作为参数，所以在调用handleLaunchActivity方法之前会创建一个ActivityClientRecord对象。刚刚传过来的icicle，也会在此时赋值到这个新创建的ActivityClientRecord对象的state上；

handleLaunchActivity方法里面会调用performLaunchActivity，Activity的onCreate也是在这方法中回调的，大家都知道，onCreate方法也有个叫savedInstanceState的Bundle参数，所以在回调onCreate方法的时候，会把ActivityClientRecord的state传进去；

handleLaunchActivity方法执行完毕之后，handleStartActivity会被调用，在这里面会判断ActivityClientRecord的state是否不为空（不为空则代表有数据可恢复），如果是的话，则回调对应Activity的onRestoreInstanceState方法。整个恢复流程到此结束。

我当然知道题目问的是Fragment而不是Activity，但是别忘了，这些Fragment数据同样也是保存在那个Bundle中！

接下来的Fragment恢复细节，可以看 @残页 同学的回答。

emmm...模拟Activity杀死重建,可以再开发者模式里面，把“不保留活动”打开，A跳转B之后，A就会被杀死。B返回时，A就重建了~

看了各位大佬的回答 有几个小问题：

1 就像缘老大 说的 activity在onSaveInstanceState跟onStop 回调之后会把数据在系统服务保留一份，那么只要是意外杀死的，重启时是不是就可以去系统服务要数据，也就是意外杀死数据不会丢？