美文网首页AndroidWorld基础知识Android
你真的懂 Fragment 吗?—— AndroidX Frag

你真的懂 Fragment 吗?—— AndroidX Frag

作者: 彭旭锐 | 来源:发表于2021-05-09 12:51 被阅读0次

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

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

    角色 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,已知的新特性包括:

    • 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 生命周期的关系:

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

    • 问题 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 种提交方式:

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

    需要注意的地方:

    • 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 的方式,要点总结如下:
    <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>
    
    • 动态加载: 动态加载是指在代码中使用事务 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 吗?—— AndroidX Frag

        本文链接:https://www.haomeiwen.com/subject/evnolltx.html