点赞关注，不再迷路，你的支持对我意义重大！

🔥 Hi，我是丑丑。本文 「Android 路线」| 导读 —— 从零到无穷大 已收录，这里有 Android 进阶成长路线笔记 & 博客，欢迎跟着彭丑丑一起成长。（联系方式在 GitHub）

前言

• Fragment 是一个历史悠久的组件，从 API 11 引入至今，已经成为 Android 开发中最常用的组件之一；
• 在这个专题里，我们将从「使用 & 核心原理 & 面试」三个层面来讨论 Fragment。如果能帮上忙，请务必点赞加关注，这真的对我非常重要。

目录

1. Fragment 的过去、现在和未来

1.1 Fragment 解决了什么问题？（过去）

Fragment 可以将 Activity 视图拆分为多个区块进行模块化地管理 ，避免了 Activity 视图代码过度臃肿混乱。虽然自定义 View 或 Window 也可以在一定程度拆分 Activity 界面，但事实上它们的职责不同：View / Window 的职责是封装某种视图功能，而 Fragment 是在更高的层次使用控制自定义 View。此外，Fragment 还可以更方便地管理生命周期和事务（虽然我们会通过 MVP 或 MVVM 模式分离业务逻辑，但是对于复杂页面，我们还是无法避免 Activity 视图代码演化的非常臃肿混乱）。

需要注意的是，Fragment 不能脱离 Activity 独立存在，必须由 Activity 或另一个 Fragment 托管，Fragment#onCreateView 实例化的视图最终会被嵌入到宿主的视图树中。

1.2 Fragment 存在什么问题？（现在）

Fragment 的最初设计理念是 “一个微型 Activity” 的角色，正所谓 “欲戴王冠，必受其重”，很多专门为 Activity 设计 的 API 也需要添加到 Fragment 中，比如运行时权限，多窗口模式切换等新 API。这无疑是在无限制地扩充 Fragment 的职责边界，也在增大 Fragment 设计的复杂度，要知道 Fragment 的本质思想是界面模块化而已。

1.3 Fragment 2.0（未来）

Google 正在重新构思 Fragment 的定位，随着 AndroidX Fragment 版本 陆续更新，新版 Fragment 正在渐渐走进我们的视野，我们称新版 Fragment 为 Fragment 2.0，已知的新特性包括：

• FragmentScenario：Fragment 的测试框架；
• FragmentFactory：统一的 Fragment 实例化组件；
• FragmentContainerView：Fragment 专属视图容器；
• OnBackPressedDispatcher：在 Fragment 或其他组件中处理返回按钮事件。

具体分析见：Android | 上车！AndroidX Fragment 新姿势！

2. 说一下 Fragment 的整体结构

现在，我们正式开始讨论 Fragment 的核心工作原理，分析的过程中我会结合读源码，帮助你更清晰地、全面地理解 Fragment 的工作原理。不过，在开始之前我们有必要先梳理 Fragment 源码的整体结构设计，为下文深入阅读源码打下基础。

2.1 代码框架

FragmentActivity.java

final FragmentController mFragments = FragmentController.createController(new HostCallbacks());

protected void onCreate(@Nullable Bundle savedInstanceState) {
    mFragments.attachHost(null /*parent*/);
    super.onCreate(savedInstanceState);

    ...
    // FragmentController 中定义了很多 dispatchXX() 方法
    mFragments.dispatchCreate();
}

如下 UML 类图描述了 Framgent 整体的代码框架：

要点如下：

• FragmentActivity 是 Activity 支持 Fragment 的基础，其中持有一个 FragmentController 中间类，它是 FragmentActivity 和 FragmentManager 的中间桥接者，对 Fragment 的操作最终是分发到 FragmentManager 来处理；

• FragmentManager 承载了 Fragment 的核心逻辑，负责对 Fragment 执行添加、移除或替换等操作，以及添加到返回堆栈。它的实现类 FragmentManagerImpl 是我们主要的分析对象；

• FragmentHostCallback 是 FragmentManager 向 Fragment 宿主的回调接口，Activity 和 Fragment 中都有内部类实现该接口，所以 Activity 和 Fragment 都可以作为另一个 Fragment 的宿主（Fragment 宿主和 FragmentManager 是 1 : 1 的关系）；

• FragmentTransaction 是 Fragment 事务抽象类，它的实现类 BackStackRecord 是事务管理的主要分析对象。

下图描述了每个宿主与关联的 FragmentManager 的关系：

提示（必看）：在后面的讨论中，我们不会再感知 FragmentActivity 与 Fragment 中间的 FragmentController，因为这属于软件设计模式的实现细节，而不是 Fragment 的核心源码。阅读源码我们一定要拨开表面看本质，抓流程，不要拘泥细枝末节。

2.2 说一下 Fragment 生命周期？

生命周期感知是 Fragment 的最基础的功能，也是面试的重灾区，我认为在 “背诵” 生命周期之前，如果你先向面试官阐述你对以下问题的理解，或许是更棒的回答：

• 问题 1：什么是生命周期，生命周期回调方法（比如 onCreateView()）是生命周期的本质吗？
  答：不然。状态转移才是生命周期的本质（Activity 同理）。生命周期方法的本质是 Fragment 状态转移，当生命周期方法被调用，说明 Fragment 从一个状态转移到另一个状态，而所谓的 “生命周期回调” 只是 Framework 提供给开发者使用的 Hook 点，用于在状态转移时执行自定义逻辑。

• 问题 2：你提到状态转移，那你说下 Fragment 有哪几种状态？
  答：从源码看，AndroidX Fragment 定义了以下五种状态，相对于早期的 Support Fragment 版本少了 STOPPED 等状态，这是因为 Google 认为这些状态是可以对称使用的，例如 STOPPED 状态和 STARTED 状态其实没有本质区别。

Fragment.java

static final int INITIALIZING = 0;     初始状态，Fragment 未创建
static final int CREATED = 1;          已创建状态，Fragment 视图未创建
static final int ACTIVITY_CREATED = 2; 已视图创建状态，Fragment 不可见
static final int STARTED = 3;          可见状态，Fragment 不处于前台
static final int RESUMED = 4;          前台状态，可接受用户交互

• 问题 3：Fragment 生命周期与宿主同步的吗，如果不是，是独立的吗？
  答：不然。Fragment 的生命周期主要受「宿主」、「事务」、「setRetainInstance() API」三个因素影响：当宿主生命周期发生变化时，会触发 Fragment 状态转移到 宿主的最新状态。不过，使用事务和 setRetainInstance() API 也可以使 Fragment 在一定程度上与宿主状态不同步（需要注意：宿主依然在一定程度上形成约束）。
  • 宿主：【见第 3 节】
  • 事务：【见第 4 节】
  • setRetainInstance() API : 【见第 6 节】

下面这张图完整描绘了 Fragment 生命周期：

—— 图片引用自网络

内容很多，别怕。跟着我的节奏一步步分析下去，也就那样了：“就这？🙇”

3. 宿主如何改变 Fragment 状态

前面提到，Fragment 的生命周期受到三个因素影响，我们暂且讨论宿主的因素。

3.1 Activity 与 Fragment 生命周期的同步关系

当宿主生命周期发生变化时，Fragment 的状态会同步到宿主的状态。从源码看，体现在宿主生命周期回调中会调用 FragmentManager 中一系列 dispatchXXX() 方法来触发 Fragment 状态转移。

FragmentActivity

@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
    mFragments.attachHost(null /*parent*/);
    ...
    mFragments.dispatchCreate(); // 最终调用 FragmentManager#dispatchCreate()
}

下表总结了 Activity 生命周期与 Fragment 生命周期的关系：

3.2 状态转移核心源码分析

FragmentManager 中一系列 dispatchXXX() 方法会触发 Fragment 状态转移，我们点进去看看：

提示： 源码方法跳转太多，不利于理解核心流程。我直接帮你梳理出核心流程，跟你直接看源码会不同，但逻辑是相同的。

FragmentManager.java

（源码方法跳转太多，我直接帮你梳理出核心流程，跟你直接看源码会不同，但逻辑是相同的）
public void dispatchCreate() {
    mStateSaved = false;
    mStopped = false;
    moveToState(Fragment.CREATED, false);
    4、处理未执行的事务（见第 4 节）
    execPendingActions();
}

void moveToState(int newState, boolean always) {
    1、状态判断
    if (nextState == mCurState) {
        return;
    }
    mCurState = nextState;

    2、执行添加的 Fragment
    // Must add them in the proper order. mActive fragments may be out of order
    for (int i = 0; i < mAdded.size(); i++) {
        Fragment f = mAdded.get(i);
        // 更新 Fragment 到当前状态
        moveFragmentToExpectedState(f);
    }

    3、执行未添加，但是准备移除的 Fragment
    // Now iterate through all active fragments. These will include those that are removed and detached.
    for (int i = 0; i < mActive.size(); i++) {
        Fragment f = mActive.valueAt(i);
        if (f != null && (f.mRemoving || f.mDetached) && !f.mIsNewlyAdded) {
            // 更新 Fragment 到当前状态
            moveFragmentToExpectedState(f);
        }
    }
}

其中，moveFragmentToExpectedState() 最终调用到 moveToState(Fragment, int) :

FragmentManager.java

-> moveFragmentToExpectedState 最终调用到 
-> 更新 Fragment 到当前状态
void moveToState(Fragment f, int newState) {
    1、准备 Detatch Fragment 的情况，不再与宿主同步，进入 CREATED 状态
    if ((!f.mAdded || f.mDetached) && newState > Fragment.CREATED) {
        newState = Fragment.CREATED;
    }
    
    2、移除 Fragment 的情况，Fragment 不再与宿主同步
    if (f.mRemoving && newState > f.mState) {
        if (f.isInBackStack()) {
            2.1 移除动作添加到返回栈，则进入 CREATED 状态
            newState = Math.min(nextState, Fragment.CREATED);
        } else {
            2.1 移除动作添加到返回栈，则进入 DESTROY 状态
            newState = Math.min(nextState, Fragment.INITIALIZING);
        }
    }

    3、真正执行状态转移
    if (f.mState <= newState ) {
        switch (f.mState) {
            case Fragment.INITIALIZING:
                if (nextState> Fragment.INITIALIZING) {
                    ...
                }
            // fall through
            case Fragment.CREATED:
                ...
                // fall through
            case Fragment.ACTIVITY_CREATED:
                ...
                // fall through
            case Fragment.STARTED:
                ...
        }
    } else {
         switch (f.mState) {
            case Fragment.RESUMED:
                if (newState < Fragment.RESUMED) {
                    ...
                }
            // fall through
            case Fragment.STARTED:
            ...
            // fall through
            case Fragment.ACTIVITY_CREATED:
            ...
            // fall through
            case Fragment.CREATED:
            ...
        }
    }
    ...
}

以上代码已经非常简化了，总结一下：

触发状态转移时，首先会判断 Fragment，如果已经处于目标状态 newState，则会跳过状态转移。然而，并不是 FragmentManager 里所有的 Fragment 都会执行状态转移，只有 「mAdded 为真 && mDetached 为假」 的 Fragment 才会更新到目标状态，其他 Fragment 会脱离宿主状态。最后，状态转移完成后会处理未执行的事务execPendingActions();，可见每次 dispatchXXX() 都会提供一次事务执行的窗口。

不同 Fragment 标志位（Detach / Remove / 返回栈）与最终状态的关系总结如下表：

提示： 这些标志位可以通过事务进行干涉。

3.3 典型场景生命周期

基本规律：Activity 状态转移触发 Fragment 状态转移。

首次启动：
Activity - onCreate
Fragment - onAttach
Fragment - onCreate
Fragment - onCreateView
Fragment - onViewCreated
Activity - onStart
Fragment - onActivityCreated
Fragment - onStart
Activity - onResume
Fragment - onResume
-------------------------------------------------
退出：
Activity - onPause
Fragment - onPause
Activity - onStop
Fragment - onStop
Activity - onDestroy
Fragment - onDestroyView
Fragment - onDestroy
Fragment - onDetach
-------------------------------------------------
回到桌面：
Activity - onPause
Fragment - onPause
Activity - onStop
Fragment - onStop
-------------------------------------------------
返回：
Activity - onStart
Fragment - onStart
Activity - onResume
Fragment - onResume

4. Fragment 事务管理

现在，我们来讨论影响 Fragment 状态转移的第二个因素：事务。

4.1 事务概述

• 问题 1：事务的特性是什么？ 事务是恢复和并发的基本单位，具备 4 个基本特性：

  • 原子性：事务不可分割，要么全部完成，要么全部失败回滚；
  • 一致性：事务执行前后数据都具有一致性；
  • 隔离性：事务执行过程中，不受其他事务干扰；
  • 持久性：事务一旦完成，对数据的改变就是永久的。在 Android 中体现为 Fragment 状态保存后，commit() 提交事务会抛异常，因为这部分新提交的事务影响的状态无法保存。

• Fragment 事务的作用： 使用事务 FragmentTransaction 可以动态改变 Fragment 状态，使得 Fragment 在一定程度脱离宿主的状态。不过，事务依然受到宿主状态约束，例如：当前 Activity 处于 STARTED 状态，那么 addFragment 不会使得 Fragment 进入 RESUME 状态。只有将来 Activity 进入 RESUME 状态时，才会同步 Fragment 到最新状态。

4.2 你知道不同事务操作的区别吗？

• add & remove：Fragment 状态在 INITIALIZING 与 RESUMED 之间转移；
• detach & attach：Fragment 状态在 CREATE 与 RESUMED 之间转移；
• replace： 先移除所有 containerId 中的实例，再 add 一个 Fragment；
• show & hide： 只控制 Fragment 隐藏或显示，不会触发状态转移，也不会销毁 Fragment 视图或实例；
• hide & detach & remove 的区别： hide 不会销毁视图和实例、detach 只销毁视图不销毁实例、remove 会销毁实例（自然也销毁视图）。不过，如果 remove 的时候将事务添加到回退栈，那么 Fragment 实例就不会被销毁，只会销毁视图。

下图描述了 Fragment 状态转移与宿主和事务的简单关系：

这里有一个让人摸不着头脑的问题，detach Fragment 并不会回调 onDetach()，因为 detach 只会转移到 CREATE 状态，而回调 onDetach() 需要转移到 INITIALIZING。不知道 Google 为什么要采用这么有歧义的命名。

detach Fragment：
Fragment - onPause
Fragment - onStop
Fragment - onDestroyView

4.3 说说看不同事务提交方式的区别？

FragmentTransaction 定义了 5 种提交方式：

需要注意的地方：

• onSaveInstanceState() 保存状态后，事务形成的新状态是不会被保存的。在状态保存之后调用 commit() 或 commitNow() 会抛异常

FragmentManagerImpl.java

private void checkStateLoss() {
    if (mStateSaved || mStopped) {
        throw new IllegalStateException("Can not perform this action after onSaveInstanceState");
    }
}

• 使用 commitNow() 或 commitNowAllowingStateLoss() 提交的事务不允许加入回退栈
  为什么有这个设计呢？可能是 Google 考虑到同时存在同步提交和异步提交的事务，并且两个事务都要加入回退栈时，无法确定哪个在上哪个在下是符合预期的，所以干脆禁止 commitNow() 加入回退栈。如果确实有需要同步执行+回退栈的应用场景，可以采用commit() + executePendingTransactions()的取巧方法。相关源码体现如下：

BackStackRecord.java

@Override
public void commitNow() {
    disallowAddToBackStack();
    mManager.execSingleAction(this, false);
}

@Override
public void commitNowAllowingStateLoss() {
    disallowAddToBackStack();
    mManager.execSingleAction(this, true);
}
@NonNull
public FragmentTransaction disallowAddToBackStack() {
    if (mAddToBackStack) {
        throw new IllegalStateException("This transaction is already being added to the back stack");
    }
    mAllowAddToBackStack = false;
    return this;
}    

• commitNow() 和 executePendingTransactions() 都是同步执行，有区别吗？
  commitNow() 是同步执行当前事务，而 executePendingTransactions() 是同步执行事务队列中的全部事务。

5. 如何把 Fragment 加载到界面上？

5.1 添加方法

有两种方式可以将 Fragment 添加到 Activity 视图上：静态加载 + 动态加载

• 静态加载： 静态加载是指在布局文件中使用 <fragment> 标签添加 Fragment 的方式，要点总结如下：

举例：

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="horizontal"
    android:layout_width="match_parent"
    android:layout_height="match_parent">
    <fragment android:name="com.example.TestFragmentFragment"
            android:id="@+id/list"
            android:layout_weight="1"
            android:layout_width="0dp"
            android:layout_height="match_parent" />
</LinearLayout>

• 动态加载： 动态加载是指在代码中使用事务 FragmentTransaction 添加 Fragment 的方式。例如：

TextFragment fragment = new TextFragment();
fragmentTransaction.add(R.id.containerId, fragment);
fragmentTransaction.commit();

5.2 Fragment 静态加载源码分析

从布局文件添加 Fragment 本质上是 xml 解析为视图树的过程，这个过程由 LayoutInflater 完成。最终，<fragment> 标签的解析工作最终是交给 FragmentManager#onCreateView(...) 处理的，让我们来看看具体是如何处理的，源码如下：

FragmentManagerImpl.java

（已简化）
public View onCreateView(@Nullable View parent, @NonNull String name, @NonNull Context context, @NonNull AttributeSet attrs) {
    1、解析属性
    String fname = 解析 class 属性
    if (fname == null) {
        fname    = 解析 android:name 属性
    }
    int id       = 解析 android:id 属性
    String tag   = 解析 android:tag 属性
    
    2、根据 id 或 tag 重用已经创建的 Fragment
    Fragment fragment = id != View.NO_ID ? findFragmentById(id) : null;
    if (fragment == null && tag != null) {
        fragment = findFragmentByTag(tag);
    }
    if (fragment == null && containerId != View.NO_ID) {
        fragment = findFragmentById(containerId);
    }

    3、新建 Fragment
    if (fragment == null) {
        3.1 反射创建 Fragment 实例
        fragment = getFragmentFactory().instantiate(context.getClassLoader(), fname);
        3.2 mFromLayout 设置为 true
        fragment.mFromLayout = true;
        fragment.mFragmentId = id != 0 ? id : containerId;
        fragment.mContainerId = containerId;
        fragment.mTag = tag;
        fragment.mInLayout = true;
        fragment.mFragmentManager = this;
        fragment.mHost = mHost;
        fragment.onInflate(mHost.getContext(), attrs, fragment.mSavedFragmentState);
        3.3 添加 Fragment，立即状态转移
        addFragment(fragment, true);
    } else if (fragment.mInLayout) {
        ...
    } else {
        ...
    }

    4.1 将 id 设置给 Fragment 根布局
    if (id != 0) {
        fragment.mView.setId(id);
    }
    4.2 将 tag 设置给 Fragment 根布局
    if (fragment.mView.getTag() == null) {
        fragment.mView.setTag(tag);
    }
    
    5、返回 Fragment 根布局
    return fragment.mView;
}

-> 3.3 添加 Fragment，立即状态转移
public void addFragment(Fragment fragment, boolean moveToStateNow) {
    ...
    if (moveToStateNow) {
        moveToState(fragment); // 状态转移
    }
}
-> 状态转移
void moveToState(Fragment f, int newState, ...) {
    ...
    if (f.mState <= newState ) {
        switch (f.mState) {
            case Fragment.INITIALIZING:
                if (nextState> Fragment.INITIALIZING) {
                    ...
                }
            // fall through
            case Fragment.CREATED:
                if (f.mFromLayout && !f.mPerformedCreateView) { // 如果来自布局，并且未执行过 onCreateView
                    最终调用：
                    mView = onCreateView(inflater, container, savedInstanceState);
                    f.onViewCreated(f.mView, f.mSavedFragmentState);
                    提示：最终在 LayoutInflater 中执行 viewGroup.addView(view, params);
                }
                if (!f.mFromLayout) { // 不是来自布局
                    最终调用：
                    mView = onCreateView(inflater, container, savedInstanceState);
                    f.onViewCreated(f.mView, f.mSavedFragmentState);
                    if (container != null) {
                        container.addView(f.mView);
                    }
                }
                ...
                // fall through
            case Fragment.ACTIVITY_CREATED:
                ...
                // fall through
            case Fragment.STARTED:
                ...
        }
    } else {
         ...
    }
}

以上代码已经非常简化了，代码虽然长但是流程很清楚：

• 1、FragmentManager 根据布局中的 id 属性或 tag 属性来重用 Fragment，如果不存在则通过反射来创建 Fragment 实例。
• 2、设置 mFromLayout 为 true，并立即执行状态转移。在 moveToState() 的 CREATE 分支会根据 mFromLayout 判断：如果来自布局，并且未执行过 onCreateView，才会回调 Fragment#onCreateView 创建 View 实例。
• 3、最终回溯到 LayoutInflater 中，执行 ViewGroup#addView(mView)，将 Fragment 根布局添加到父布局中（所以，我们不用在 Fragment 里创建的视图时调用 addView() ）。

在我之前写的一篇文章里已经详细讨论过布局解析的全过程：Android | 带你探究 LayoutInflater 布局解析原理，关于 <fragment> 的部分在第 4.2 节，记得去看看。

5.3 Fragment 动态加载源码分析

Fragment 事务的源码在 第 4.4 节 已经讨论过了，我们知道了通过事务添加 / 移除的 Fragment 最终还是会走到 moveToState(...) 来执行状态转移。在创建 View 实例后，mView 也会直接添加到 containerId 容器上。

5.4 静态加载和动态加载的区别体现在哪里？

静态加载和动态加载的主要区别体现在 执行加载操作的消息周期不同：静态加载和布局解析是在同一个 Handler 消息周期中，而动态加载和事务提交不一定在一个 Handler 消息周期中（取决于调用 commit() 还是 commitNow()）。

5.5 静态加载和动态加载的优缺点？

这个问题看似合理，但其实经不起推敲，是个伪命题。较常见的说法是静态加载简单直接，而动态加载灵活性跟高。 提出这个说法的人其实忽略了一点：从布局文件中静态加载的 Fragment 也可以使用事务进行动态操作，静态加载也是具有灵活性的。

比较合理的问法是：静态加载和动态加载各适合什么场景？静态加载适合于界面初始化时就确定显示位置和时机的 Fragment，从布局文件中加载可以方便预览。相反地，动态加载适用于初始化时无法确定显示位置和时机的 Fragment，需要依赖代码中的判断条件动态判断。

演示：使用事务操作从布局文件中静态加载的 Fragment
with(supportFragmentManager.beginTransaction()) {
    val fragmentA = supportFragmentManager.findFragmentById(R.id.FragmentA)
    if (null != fragmentA) {
        hide(fragmentA)
        commit()
    }
}

6. setRetainInstance() 到底做了什么？

事实上，从 androidx.fragment 1.3.0 开始，setRetainInstance() 这个 API 已经废弃了。不过，考虑到这个 API 的重要性，我们还是花费一点时间来回顾一下。

6.1 概述

• 问题 1：什么时候应该使用 setRetainInstance(true)？
  答：在配置变更时（例如屏幕旋转），整个 Activity 需要销毁重建，顺带着 Activity 中的 Fragment 也需要销毁重建。而设置 setRetainInstance(true) 的 Fragment 对象在 Activity 销毁重建的过程中不会被销毁。

• 问题 2：setRetainInstance(true) 对 Fragment 生命周期的影响？
  答：在 Activity 销毁时，Fragment 不会回调 onDestroy()，而是直接回调 onDestroyView() + onDetach()；在 Activity 重建时，Fragment 不会回调 onCreate()，而是直接回调 onCreateView()。

• 问题 3：为什么废弃 setRetainInstance()？
  答：引入 ViewModel 后，setRetainInstance() API 开始变得鸡肋。ViewModel 已经提供了在 Activity 重建等场景下保持数据的能力，虽然 setRetainInstance() 也具备相同功能，但需要利用 Fragment 来间接存储数据，使用起来不方便，存储粒度也过大。

6.2 setRetainInstance() 核心源码分析

Fragment.java

@Deprecated
public void setRetainInstance(boolean retain) {
    mRetainInstance = retain;
    if (mFragmentManager != null) {
        if (retain) {
            mFragmentManager.addRetainedFragment(this);
        } else {
            mFragmentManager.removeRetainedFragment(this);
        }
    } else {
        mRetainInstanceChangedWhileDetached = true;
    }
}

FragmentManager.java

void addRetainedFragment(@NonNull Fragment f) {
    mNonConfig.addRetainedFragment(f);
}

FragmentManagerViewModel.java

void addRetainedFragment(@NonNull Fragment fragment) {
    if (mIsStateSaved) {
        if (FragmentManager.isLoggingEnabled(Log.VERBOSE)) {
            Log.v(TAG, "Ignoring addRetainedFragment as the state is already saved");
        }
        return;
    }
    if (mRetainedFragments.containsKey(fragment.mWho)) {
        return;
    }
    mRetainedFragments.put(fragment.mWho, fragment);
    if (FragmentManager.isLoggingEnabled(Log.VERBOSE)) {
        Log.v(TAG, "Updating retained Fragments: Added " + fragment);
    }
}

这段代码并不复杂，当我们调用 Fragment#setRetainInstance(true)时，最终会将 Fragment 添加到一个 ViewModel 中。ViewModel 是具备在 Activity 重建是恢复数据的能力的，现在的问题转换为 ViewModel 为什么可以恢复数据？

简单来说，在 Activity 销毁时，最终会调用 Activity#retainNonConfigurationInstances() 保存 ActivityClientRecord，并托管给 ActivityManagerService。这个过程就相当于把 Fragment 保存到更长的生命周期了。关于 ViewModel 的具体分析，我后面会专门写一篇文章，期待吗？

7. 总结

我们前面讲了 Fragment 一些历史问题的由来，以及它的一些核心特性，包括生命周期、事务、加载方式和已过时的 setRetainInstance(true)。关于 Fragment 的话题还有很多，今天我们只讨论了其中最核心的部分，更多内容我后续会继续发布更多文章来讨论。

参考资料

• Fragment 的过去、现在和将来 —— 谷歌开发者
• Fragment 的过去、现在和将来（Youtube 视频版） —— Android Dev Summit '19
• Fragment 指南 —— 官方文档
• Activity 都重建了，你 Fragment 凭什么活着？ —— Wan Android
• 今天考察下 Fragment 相关两个不常见 API —— Wan Android
• Fragment 是如何被存储与恢复的？ —— Wan Android
• Fragment 生命周期 —— 更木小八 著
• Fragment 不为人知的细节 —— 三雒 著

创作不易，你的「三连」是丑丑最大的动力，我们下次见！