AndroidWorld基础知识Android

你真的懂 Fragment 吗？—— AndroidX Frag

2021-05-09  本文已影响0人  彭旭锐

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

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

前言

目录

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 实例化的视图最终会被嵌入到宿主的视图树中。

类 角色 MVVM 分层 生命周期感知
Activity 视图控制器 View 层 感知
Fragment 视图控制器 View 层 感知
View 视图 View 层 不感知
Window 视图 View 层 不感知

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，已知的新特性包括：

具体分析见：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 整体的代码框架：

要点如下：

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

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

2.2 说一下 Fragment 生命周期？

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

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;          前台状态，可接受用户交互

下面这张图完整描绘了 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 生命周期的关系：

Activity 生命周期 FragmentManager Fragment 状态转移 Fragment 生命周期回调
onCreate dispatchCreate INITIALIZING
-> CREATE		 -> onAttach
-> onCreate
onStart（首次） dispatchActivityCreated
dispatchStart		 CREATE
-> ACTIVITY_CREATED
-> STARTED		 -> onCreateView
-> onViewCreated
-> onActivityCreated
-> onStart
onStart（非首次） dispatchStart ACTIVITY_CREATED
-> STARTED		 -> onStart
onResume dispatchResume STARTED
-> RESUMED（Fragment 可交互）		 -> onResume
onPause dispatchPause RESUMED
-> STARTED		 -> onPause
onStop dispatchStop STARTED
-> ACTIVITY_CREATED		 -> onStop
onDestroy dispatchDestroy ACTIVITY_CREATED
-> CREATED
-> INITIALIZING		 -> onDestroyView
-> onDestroy
-> onDetach

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 / 返回栈）与最终状态的关系总结如下表：

情况 判断 描述 最终状态
1 f.mRemoving 移除 Fragment.INITIALIZING
2 f.mRemoving && f.isInBackStack() 移除，但添加进返回栈 Fragment.CREATED
3 !f.mAdded || f.mDetached 未添加 Fragment.CREATED
4 f.mAdded 已添加 newState（同步到宿主状态）

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

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 事务概述

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

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

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

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

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

FragmentTransaction 定义了 5 种提交方式：

API 描述 是否同步
commit() 异步提交事务，不允许状态丢失 异步
commitAllowingStateLoss() 异步提交事务，允许状态丢失 异步
commitNow() 同步提交事务，不允许状态丢失 同步
commitNowAllowingStateLoss() 同步提交事务，允许状态丢失 同步
executePendingTransactions() 同步执行事务队列中的全部事务 同步

需要注意的地方：

FragmentManagerImpl.java

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

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;
}

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

5.1 添加方法

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

<fragment>属性 描述
class Fragment 的全限定类名
android:name Fragment 的全限定类名（与 class 没有差别，但 class 优先）
android:id Fragment 唯一标识
android:tag Fragment 唯一标识（id 和 tag 至少设置一个）

举例：

<?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>

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 {
         ...
    }
}

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

在我之前写的一篇文章里已经详细讨论过布局解析的全过程：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 概述

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 的话题还有很多，今天我们只讨论了其中最核心的部分，更多内容我后续会继续发布更多文章来讨论。

参考资料

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

上一篇下一篇

猜你喜欢

热点阅读