Navigation之详细聊聊Fragment的实现原理

简介: Navigation之详细聊聊Fragment的实现原理

image.png


1. 前言


Fragment真是一个非常老的家伙,它的第一条提交记录是在2010年,而最近的一条记录则是在2021年6月11号,足足11岁了,但是它却老当益壮,在Jetpack中大放异彩,Navigation组件就是基于Fragment的一个跳转组件,Google的单Activity项目结构就是一个Activity和多个Fragment项目结构。多年以来,一提到Fragment,大家脑海中的第一印象可能还停留在平板应用开发中了,它曾经在手机项目中高频使用Fragment的机会还真没那么多。一方面是因为手机项目一般都是多Activity结构实现的,不会涉及到那么多的Fragment使用,另一方面,Fragment也比Activity复杂,相比之下使用有点麻烦,甚至是痛苦,不好定位问题,所以在技术选型时,能避则避。它太难用了,以至于Square团队的Piwai大神(LeakCanary的作者)在2014年发表了一篇倡导反对使用Fragment的文章。不管怎么样,这么多年过去了,Android团队也一直没有放弃对Fragment的支持,甚至在Jetpack中,Fragment开始扮演越来越重要的角色了,最近关于Navigation的倡导使用越来越多了,加上我参与了一个平板项目,所以对Fragment主流程源码进行了一次全面的研究。收获颇多,相信将来对Navigation研究定是大有裨益。


2. 创建Fragment



根据官方文档,写一个简单的Demo。简单了解Fragment的使用。


2.1 新建一个Fragment类


class ExampleFragment extends Fragment {
    public ExampleFragment() {
        super(R.layout.example_fragment);
    }
}

2.2 把Fragment添加到Activity上

把Fragment添加到Activity上可以通过xml文件和代码编程两种方式实现。本文只介绍第二种实现方式。

<!-- res/layout/example_activity.xml -->
<androidx.fragment.app.FragmentContainerView
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/fragment_container_view"
    android:layout_width="match_parent"
    android:layout_height="match_parent" />
public class ExampleActivity extends AppCompatActivity {
    public ExampleActivity() {
        super(R.layout.example_activity);
    }
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        if (savedInstanceState == null) {
            getSupportFragmentManager().beginTransaction()
                .setReorderingAllowed(true)
                .add(R.id.fragment_container_view, ExampleFragment.class, null)
                .commit();
        }
    }
}


我们可以看到,主要是通过FragmentManager来将Fragment添加到fragment_container_view对应的布局中,Demo是蛮简单的,模板代码,网上拷贝一下就能用。但是FragmentManager、Transaction、commit()分别是什么意思,还有待深入探究一番。


3. 深入理解Fragment原理


3.1 Fragment本质是什么


3.1.1 Fragment本质是View


从前面的DEMO我们看到,Fragment会add到FragmentContainerView上面,能被添加到ViewGroup的组件,一定也是View或者ViewGroup。有源码为证:


//androidx.fragment.app.Fragment.java
ViewGroup mContainer;
// The View generated for this fragment.
View mView;

那么既然如此,何必大费周章呢,直接用View来替代Fragment不就好了,addView()、removeView()使用起来更简单直观。


当然了Fragment本质是View但是又不仅限于此, 在真实的项目中,界面往往很复杂,业务逻辑也很复杂,往往需要处理各种UI状态变化,比如:增加一组View,替换一组View,删除一组View,还需要和Activity协作。总之,如果让开发者自己去实现这一套逻辑,恐怕比使用Fragment要麻烦的多吧。尽管Fragment看起来蛮复杂的,但是还是远比我们自己去实现相同功能简单的多。


3.1.2 Fragment本质不仅限于View


Fragment作为一个View可以被添加到Activity的布局中去。但是他更强大,还有以下几个特性:


  1. 处理生命周期,比Activity生命周期还要复杂
  2. 通过FragmentTransaction操作多个Fragment
  3. 通过FragmentManager维护一个回退栈,回退到上一个FragmentTransaction操作的界面


//androidx.fragment.app.Fragment.java
static final int INITIALIZING = -1;          // Not yet attached.
static final int ATTACHED = 0;               // Attached to the host.
static final int CREATED = 1;                // Created.
static final int VIEW_CREATED = 2;           // View Created.
static final int AWAITING_EXIT_EFFECTS = 3;  // Downward state, awaiting exit effects
static final int ACTIVITY_CREATED = 4;       // Fully created, not started.
static final int STARTED = 5;                // Created and started, not resumed.
static final int AWAITING_ENTER_EFFECTS = 6; // Upward state, awaiting enter effects
static final int RESUMED = 7;                // Created started and resumed.

从代码我们可以看出,有8种状态。分为两类,View相关的以及和Activity状态相关的。后文会详细介绍,此处点到为止。


3.2 FragmentTransaction


3.2.1 FragmentTransaction概述


软件工程中有一门叫数据库的课程,数据库中有一个叫"事务"的概念,它表示多个操作是原子性的,要么一起成功,要么一起失败,典型的例子就是转账,张三给李四转账100元这么一个事务,存在两个操作,从张三的账户中扣除100元,给李四的账户增加100元。因为有了事务,不会存在只有某一个操作成功,而另一个操作失败的情况,否则后果不堪设想。


在Android中SharedPreference也有commit方法。


SharedPreferences sharedPreferences= getSharedPreferences("data",Context.MODE_PRIVATE);
SharedPreferences.Editor editor = sharedPreferences.edit();
editor.putString("name", “Tom”);
editor.putInt("age", 28);
editor.putBoolean("marrid",false);           
editor.commit();

上述功能,一次提交做了三件事情,putString,putInt,putBoolean。


而FragmentTransaction和SharedPreference类似。它可以同时操作多个Fragment。

假设有布局文件如下:


<LinearLayout android:orientation="vertical">
    <ViewGroup1>
        <Fragment1 />
    </ViewGroup1>
    <ViewGroup2>
        <Fragment2 />
    </ViewGroup2>
    <ViewGroup3>
        <Fragment3 />
    </ViewGroup3>
</LinearLayout>

假设我们想在ViewGroup1上增加Fragment1,ViewGroup2上用Fragment2替换掉,把ViewGroup3上的Fragment移除掉。


伪代码如下:

getSupportFragmentManager().beginTransaction()
    .setReorderingAllowed(true)
    .add(ViewGroup1, Fragment1.class, null)
    .replace(ViewGroup2,Fragment2.class,null)
    .remove(Fragment3)
    .commit();

问:这三个操作我为什么要放到一个事务中呢?我连续执行这三个操作不行吗?

答:有些场景下可以,有些场景下不可以。涉及到回退栈的时候,是否放到事务中,按返回键会有很大的区别。我们把上述三个操作分别命名为OP1、OP2、OP3。如果调用了FragmentTransaction.addToBackStack(),三个操作放到事务中时, 按返回键时会执行与OP1、OP2、OP3相反的操作,即ViewGroup1、ViewGroup2、ViewGroup3同时恢复到处理事务之前的状态。如果三个操作不放到事务中时, 则会依次恢复 ViewGroup3、ViewGroup2、ViewGroup1的状态

3.2.2 FragmentTransaction源码分析


3.2.2.1 支持的操作OP_CMD


//FragmentTransaction.java
static final int OP_NULL = 0;
static final int OP_ADD = 1;
static final int OP_REPLACE = 2;
static final int OP_REMOVE = 3;
static final int OP_HIDE = 4;
static final int OP_SHOW = 5;
static final int OP_DETACH = 6;
static final int OP_ATTACH = 7;
static final int OP_SET_PRIMARY_NAV = 8;
static final int OP_UNSET_PRIMARY_NAV = 9;
static final int OP_SET_MAX_LIFECYCLE = 10;

挑几个一眼就能看懂的。


  1. OP_ADD表示增加Fragment
  2. OP_REPLACE表示替换某个ViewGroup上的Fragment
  3. OP_REMOVE删除Fragment
  4. OP_HIDE隐藏Fragment,等同于View.setVisibility(View.GONE)
  5. OP_SHOW显示Fragment,等同于View.setVisibility(View.VISIBLE)
  6. OP_DETACH detach Fragment
  7. OP_ATTACH attach Fragment


对应的方法分别是:


//FragmentTransaction.java
public FragmentTransaction add(@NonNull Fragment fragment, @Nullable String tag)  {
    doAddOp(0, fragment, tag, OP_ADD);
    return this;
}
public FragmentTransaction replace(@IdRes int containerViewId, @NonNull Fragment fragment) {
    return replace(containerViewId, fragment, null);
}
public FragmentTransaction remove(@NonNull Fragment fragment) {
    addOp(new Op(OP_REMOVE, fragment));
    return this;
}

3.2.2.2 OP类


public abstract class FragmentTransaction {
    ArrayList<Op> mOps = new ArrayList<>();
    static final class Op {
          int mCmd;
          Fragment mFragment;
          int mEnterAnim;
          int mExitAnim;
          int mPopEnterAnim;
          int mPopExitAnim;
          Lifecycle.State mOldMaxState;
          Lifecycle.State mCurrentMaxState;
          Op() {
          }
          Op(int cmd, Fragment fragment) {
              this.mCmd = cmd;
              this.mFragment = fragment;
              this.mOldMaxState = Lifecycle.State.RESUMED;
              this.mCurrentMaxState = Lifecycle.State.RESUMED;
          }
          Op(int cmd, @NonNull Fragment fragment, Lifecycle.State state) {
              this.mCmd = cmd;
              this.mFragment = fragment;
              this.mOldMaxState = fragment.mMaxState;
              this.mCurrentMaxState = state;
          }
      }
}

从源码中我们可以看到,FragmentTransaction中有ArrayList<Op> mOps。它表示一个事务中需要处理几个操作。而OP类最重要的两个字段就是mCmd和mFragment。表示对某个Fragment执行指定的操作。


3.2.2.3 FragmentTransaction.commit()方法


//FragmentTransaction.java
public abstract class FragmentTransaction {
    public abstract int commit();
}


我们看到commit()方法是个抽象方法。它由BackStackRecord类实现。


final class BackStackRecord extends FragmentTransaction implements
      FragmentManager.BackStackEntry, FragmentManager.OpGenerator {
  @Override
  public int commit() {
      return commitInternal(false);
  }
}

3.3 BackStackRecord


3.3.1 BackStackRecord概述


BackStackRecord是FragmentTransaction的子类,表示它支持同时操作多个Fragment。同时,顾名思义,它会被放到BackStack(回退栈)中。回退栈定义在FragmentManager中,是一个ArrayList集合。


//FragmentManager.java
ArrayList<BackStackRecord> mBackStack;

一言以蔽之,BackStackRecord支持事务操作,同时又会被放入到回退栈中


3.3.2 BackStackRecord commit流程


int commitInternal(boolean allowStateLoss) {
    if (mCommitted) throw new IllegalStateException("commit already called");
    if (FragmentManager.isLoggingEnabled(Log.VERBOSE)) {
        Log.v(TAG, "Commit: " + this);
        LogWriter logw = new LogWriter(TAG);
        PrintWriter pw = new PrintWriter(logw);
        dump("  ", pw);
        pw.close();
    }
    mCommitted = true;
    if (mAddToBackStack) {
        mIndex = mManager.allocBackStackIndex();
    } else {
        mIndex = -1;
    }
    mManager.enqueueAction(this, allowStateLoss);
    return mIndex;
}

该方法最主要的就是调用了FragmentManager.enqueueAction方法


3.4 FragmentManager


3.4.1 FragmentManager概述


从前文,我们知道,对多个Fragment的操作会被记录到FragmentTransaction中,最终调用FragmentManager.enqueueAction方法,真正执行Fragment操作。


3.4.2 操作调用流程


1. FragmentManager.enqueueAction()


void enqueueAction(@NonNull OpGenerator action, boolean allowStateLoss) {
    if (!allowStateLoss) {
        if (mHost == null) {
            if (mDestroyed) {
                throw new IllegalStateException("FragmentManager has been destroyed");
            } else {
                throw new IllegalStateException("FragmentManager has not been attached to a "
                        + "host.");
            }
        }
        checkStateLoss();
    }
    synchronized (mPendingActions) {
        if (mHost == null) {
            if (allowStateLoss) {
                // This FragmentManager isn't attached, so drop the entire transaction.
                return;
            }
            throw new IllegalStateException("Activity has been destroyed");
        }
        mPendingActions.add(action);
        scheduleCommit();
    }
}

该方法最终调用到scheduleCommit()方法


2. FragmentManager.scheduleCommit()


void scheduleCommit() {
    synchronized (mPendingActions) {
        boolean postponeReady =
                mPostponedTransactions != null && !mPostponedTransactions.isEmpty();
        boolean pendingReady = mPendingActions.size() == 1;
        if (postponeReady || pendingReady) {
            mHost.getHandler().removeCallbacks(mExecCommit);
            mHost.getHandler().post(mExecCommit);
            updateOnBackPressedCallbackEnabled();
        }
    }
}

该方法最终通过Handler执行mExecCommit


3. FragmentManager.mExecCommit


private Runnable mExecCommit = new Runnable() {
    @Override
    public void run() {
        execPendingActions(true);
    }
};

该方法最终调用execPendingActions


4. FragmentManager.execPendingActions()


boolean execPendingActions(boolean allowStateLoss) {
    ensureExecReady(allowStateLoss);
    boolean didSomething = false;
    while (generateOpsForPendingActions(mTmpRecords, mTmpIsPop)) {
        mExecutingActions = true;
        try {
            removeRedundantOperationsAndExecute(mTmpRecords, mTmpIsPop);
        } finally {
            cleanupExec();
        }
        didSomething = true;
    }
    updateOnBackPressedCallbackEnabled();
    doPendingDeferredStart();
    mFragmentStore.burpActive();
    return didSomething;
}

重点关注removeRedundantOperationsAndExecute(mTmpRecords, mTmpIsPop)


5. FragmentManager.removeRedundantOperationsAndExecute()


private void removeRedundantOperationsAndExecute(@NonNull ArrayList<BackStackRecord> records,
            @NonNull ArrayList<Boolean> isRecordPop) {
}

方法比较长省略代码,最终调用executeOpsTogether


6. FragmentManager.executeOpsTogether


private void executeOpsTogether(@NonNull ArrayList<BackStackRecord> records,
          @NonNull ArrayList<Boolean> isRecordPop, int startIndex, int endIndex) {
}

方法比较长省略代码,最终调用executeOps方法


7. FragmentManager.executeOps()


private static void executeOps(@NonNull ArrayList<BackStackRecord> records,
            @NonNull ArrayList<Boolean> isRecordPop, int startIndex, int endIndex) {
    for (int i = startIndex; i < endIndex; i++) {
        final BackStackRecord record = records.get(i);
        final boolean isPop = isRecordPop.get(i);
        if (isPop) {
            record.bumpBackStackNesting(-1);
            // Only execute the add operations at the end of
            // all transactions.
            boolean moveToState = i == (endIndex - 1);
            record.executePopOps(moveToState);
        } else {
            record.bumpBackStackNesting(1);
            record.executeOps();
        }
    }
}

该方法分为两种情况,入栈和出栈,对应commit()和FragmentManager.popBackStack()操作。


8. FragmentManager.executeOps()


void executeOps() {
        final int numOps = mOps.size();
        for (int opNum = 0; opNum < numOps; opNum++) {
            final Op op = mOps.get(opNum);
            final Fragment f = op.mFragment;
            if (f != null) {
                f.setPopDirection(false);
                f.setNextTransition(mTransition);
                f.setSharedElementNames(mSharedElementSourceNames, mSharedElementTargetNames);
            }
            switch (op.mCmd) {
                case OP_ADD:
                    f.setAnimations(op.mEnterAnim, op.mExitAnim, op.mPopEnterAnim, op.mPopExitAnim);
                    mManager.setExitAnimationOrder(f, false);
                    mManager.addFragment(f);
                    break;
                case OP_REMOVE:
                    f.setAnimations(op.mEnterAnim, op.mExitAnim, op.mPopEnterAnim, op.mPopExitAnim);
                    mManager.removeFragment(f);
                    break;
                case OP_HIDE:
                    f.setAnimations(op.mEnterAnim, op.mExitAnim, op.mPopEnterAnim, op.mPopExitAnim);
                    mManager.hideFragment(f);
                    break;
                case OP_SHOW:
                    f.setAnimations(op.mEnterAnim, op.mExitAnim, op.mPopEnterAnim, op.mPopExitAnim);
                    mManager.setExitAnimationOrder(f, false);
                    mManager.showFragment(f);
                    break;
                case OP_DETACH:
                    f.setAnimations(op.mEnterAnim, op.mExitAnim, op.mPopEnterAnim, op.mPopExitAnim);
                    mManager.detachFragment(f);
                    break;
                case OP_ATTACH:
                    f.setAnimations(op.mEnterAnim, op.mExitAnim, op.mPopEnterAnim, op.mPopExitAnim);
                    mManager.setExitAnimationOrder(f, false);
                    mManager.attachFragment(f);
                    break;
                case OP_SET_PRIMARY_NAV:
                    mManager.setPrimaryNavigationFragment(f);
                    break;
                case OP_UNSET_PRIMARY_NAV:
                    mManager.setPrimaryNavigationFragment(null);
                    break;
                case OP_SET_MAX_LIFECYCLE:
                    mManager.setMaxLifecycle(f, op.mCurrentMaxState);
                    break;
                default:
                    throw new IllegalArgumentException("Unknown cmd: " + op.mCmd);
            }
            if (!mReorderingAllowed && op.mCmd != OP_ADD && f != null) {
                if (!FragmentManager.USE_STATE_MANAGER) {
                    mManager.moveFragmentToExpectedState(f);
                }
            }
        }
        if (!mReorderingAllowed && !FragmentManager.USE_STATE_MANAGER) {
            // Added fragments are added at the end to comply with prior behavior.
            mManager.moveToState(mManager.mCurState, true);
        }
    }

该方法做了两件事,其一:根据OP.mCmd,操作FragmentManager对应的方法,该步骤并不会真正执行操作,也只是做记录操作,其二:调用mManager.moveToState(mManager.mCurState, true)

最终会调用到mManager.moveToState(Fragment f, int newState)方法,它是Fragment框架中真正核心方法


3.5 FragmentManager的核心方法void moveToState(Fragment f, int newState)


作为核心方法,并没有放在3.4章节中,只是为了突出它的核心地位。


void moveToState(@NonNull Fragment f, int newState) {
    FragmentStateManager fragmentStateManager = mFragmentStore.getFragmentStateManager(f.mWho);
    if (fragmentStateManager == null) {
        // Ideally, we only call moveToState() on active Fragments. However,
        // in restoreSaveState() we can call moveToState() on retained Fragments
        // just to clean them up without them ever being added to mActive.
        // For these cases, a brand new FragmentStateManager is enough.
        fragmentStateManager = new FragmentStateManager(mLifecycleCallbacksDispatcher,
                mFragmentStore, f);
        // Only allow this FragmentStateManager to go up to CREATED at the most
        fragmentStateManager.setFragmentManagerState(Fragment.CREATED);
    }
    // When inflating an Activity view with a resource instead of using setContentView(), and
    // that resource adds a fragment using the <fragment> tag (i.e. from layout and in layout),
    // the fragment will move to the VIEW_CREATED state before the fragment manager
    // moves to CREATED. So when moving the fragment manager moves to CREATED and the
    // inflated fragment is already in VIEW_CREATED we need to move new state up from CREATED
    // to VIEW_CREATED. This avoids accidentally moving the fragment back down to CREATED
    // which would immediately destroy the Fragment's view. We rely on computeExpectedState()
    // to pull the state back down if needed.
    if (f.mFromLayout && f.mInLayout && f.mState == Fragment.VIEW_CREATED) {
        newState = Math.max(newState, Fragment.VIEW_CREATED);
    }
    newState = Math.min(newState, fragmentStateManager.computeExpectedState());
    if (f.mState <= newState) {
        // If we are moving to the same state, we do not need to give up on the animation.
        if (f.mState < newState && !mExitAnimationCancellationSignals.isEmpty()) {
            // The fragment is currently being animated...  but!  Now we
            // want to move our state back up.  Give up on waiting for the
            // animation and proceed from where we are.
            cancelExitAnimation(f);
        }
        switch (f.mState) {
            case Fragment.INITIALIZING:
                if (newState > Fragment.INITIALIZING) {
                    fragmentStateManager.attach();
                }
                // fall through
            case Fragment.ATTACHED:
                if (newState > Fragment.ATTACHED) {
                    fragmentStateManager.create();
                }
                // fall through
            case Fragment.CREATED:
                // We want to unconditionally run this anytime we do a moveToState that
                // moves the Fragment above INITIALIZING, including cases such as when
                // we move from CREATED => CREATED as part of the case fall through above.
                if (newState > Fragment.INITIALIZING) {
                    fragmentStateManager.ensureInflatedView();
                }
                if (newState > Fragment.CREATED) {
                    fragmentStateManager.createView();
                }
                // fall through
            case Fragment.VIEW_CREATED:
                if (newState > Fragment.VIEW_CREATED) {
                    fragmentStateManager.activityCreated();
                }
                // fall through
            case Fragment.ACTIVITY_CREATED:
                if (newState > Fragment.ACTIVITY_CREATED) {
                    fragmentStateManager.start();
                }
                // fall through
            case Fragment.STARTED:
                if (newState > Fragment.STARTED) {
                    fragmentStateManager.resume();
                }
        }
    } else if (f.mState > newState) {
        switch (f.mState) {
            case Fragment.RESUMED:
                if (newState < Fragment.RESUMED) {
                    fragmentStateManager.pause();
                }
                // fall through
            case Fragment.STARTED:
                if (newState < Fragment.STARTED) {
                    fragmentStateManager.stop();
                }
                // fall through
            case Fragment.ACTIVITY_CREATED:
                if (newState < Fragment.ACTIVITY_CREATED) {
                    if (isLoggingEnabled(Log.DEBUG)) {
                        Log.d(TAG, "movefrom ACTIVITY_CREATED: " + f);
                    }
                    if (f.mView != null) {
                        // Need to save the current view state if not
                        // done already.
                        if (mHost.onShouldSaveFragmentState(f) && f.mSavedViewState == null) {
                            fragmentStateManager.saveViewState();
                        }
                    }
                }
                // fall through
            case Fragment.VIEW_CREATED:
                if (newState < Fragment.VIEW_CREATED) {
                    FragmentAnim.AnimationOrAnimator anim = null;
                    if (f.mView != null && f.mContainer != null) {
                        // Stop any current animations:
                        f.mContainer.endViewTransition(f.mView);
                        f.mView.clearAnimation();
                        // If parent is being removed, no need to handle child animations.
                        if (!f.isRemovingParent()) {
                            if (mCurState > Fragment.INITIALIZING && !mDestroyed
                                    && f.mView.getVisibility() == View.VISIBLE
                                    && f.mPostponedAlpha >= 0) {
                                anim = FragmentAnim.loadAnimation(mHost.getContext(),
                                        f, false, f.getPopDirection());
                            }
                            f.mPostponedAlpha = 0;
                            // Robolectric tests do not post the animation like a real device
                            // so we should keep up with the container and view in case the
                            // fragment view is destroyed before we can remove it.
                            ViewGroup container = f.mContainer;
                            View view = f.mView;
                            if (anim != null) {
                                FragmentAnim.animateRemoveFragment(f, anim,
                                        mFragmentTransitionCallback);
                            }
                            container.removeView(view);
                            if (FragmentManager.isLoggingEnabled(Log.VERBOSE)) {
                                Log.v(FragmentManager.TAG, "Removing view " + view + " for "
                                        + "fragment " + f + " from container " + container);
                            }
                            // If the local container is different from the fragment
                            // container, that means onAnimationEnd was called, onDestroyView
                            // was dispatched and the fragment was already moved to state, so
                            // we should early return here instead of attempting to move to
                            // state again.
                            if (container != f.mContainer) {
                                return;
                            }
                        }
                    }
                    // If a fragment has an exit animation (or transition), do not destroy
                    // its view immediately and set the state after animating
                    if (mExitAnimationCancellationSignals.get(f) == null) {
                        fragmentStateManager.destroyFragmentView();
                    }
                }
                // fall through
            case Fragment.CREATED:
                if (newState < Fragment.CREATED) {
                    if (mExitAnimationCancellationSignals.get(f) != null) {
                        // We are waiting for the fragment's view to finish animating away.
                        newState = Fragment.CREATED;
                    } else {
                        fragmentStateManager.destroy();
                    }
                }
                // fall through
            case Fragment.ATTACHED:
                if (newState < Fragment.ATTACHED) {
                    fragmentStateManager.detach();
                }
        }
    }
    if (f.mState != newState) {
        if (isLoggingEnabled(Log.DEBUG)) {
            Log.d(TAG, "moveToState: Fragment state for " + f + " not updated inline; "
                    + "expected state " + newState + " found " + f.mState);
        }
        f.mState = newState;
    }
}


相关文章
|
6月前
|
Android开发
RecyclerView的简单使用在activity和fragment中
RecyclerView的简单使用在activity和fragment中
99 0
|
XML 缓存 Android开发
QMUI实战(二)—Activity 和 Fragment,我们该选择谁?
在一开始,官方只提供了 Activity 来作为 UI 界面的载体,因此我们也别无选择,只能用它。而在 Android 3.0 后,Fragment 也面世了,它一开始是用于适配平板的,以邮件列表与详情的适配为例,手机端够小,因此开始展示列表,点击进入详情,而平板够大,则可以列表显示在左侧,详情显示在右侧,点击列表只是切换详情。对于这种适配场景,列表页和详情页必须在同一个 Activity 里了,而这便是我所知道的 Fragment 诞生的场景了。
198 0
|
XML Java Android开发
Android——RecyclerView简单实现及Viewbinding优化
本文是博主对Adapter(适配器)的一些理解,为了加深对Adapter的理解以及记录自己的阶段学习而写,同时也适合初学者阅读,参考本条博客的逻辑进行学习。
417 0
|
XML 移动开发 数据可视化
每日记录自己的Android项目(二)—Viewbinding,WebView,Navigation
今天是想把做一个跳转页面的时候调到H5页面去,但是这个页面我用app来承载,不要调到浏览器去。
191 0
每日记录自己的Android项目(二)—Viewbinding,WebView,Navigation
|
存储 Android开发
android ViewPager + Fragment + Tablayout 实现嵌套页面导航(二)
android ViewPager + Fragment + Tablayout 实现嵌套页面导航
android ViewPager + Fragment + Tablayout 实现嵌套页面导航(二)
|
编译器 Android开发 容器
android ViewPager + Fragment + Tablayout 实现嵌套页面导航(一)
android ViewPager + Fragment + Tablayout 实现嵌套页面导航
android ViewPager + Fragment + Tablayout 实现嵌套页面导航(一)
|
Android开发
ViewPager源码分析(2):滑动及冲突处理
我的简书同步发布:ViewPager源码分析(2):滑动及冲突处理 转载请注明出处:【huachao1001的专栏:http://blog.csdn.net/huachao1001】 上一篇介绍了ViewPager的onMeasure和onLayout两个方法,这是自定义View最基本的两个函数。但是我们的ViewPager有个需求就是滑动,接下来我们一起去学习ViewPager在滑动方面做了哪些工作,以及ViewPager如何处理与子View之间的滑动冲突。由于ViewPager的子View有Decor View还有普通的子View,而本篇文章讲的主要是普通子View,因此,不再去刻意区
ViewPager源码分析(2):滑动及冲突处理
|
Android开发
【Android 插件化】VirtualApp 源码分析 ( 添加应用源码分析 | LaunchpadAdapter 适配器 | 适配器添加元素 | PackageAppData 元素 )
【Android 插件化】VirtualApp 源码分析 ( 添加应用源码分析 | LaunchpadAdapter 适配器 | 适配器添加元素 | PackageAppData 元素 )
315 0
【Android 插件化】VirtualApp 源码分析 ( 添加应用源码分析 | LaunchpadAdapter 适配器 | 适配器添加元素 | PackageAppData 元素 )
|
前端开发 开发者
一道面试题:ViewPager中的Framgent如何实现懒加载?
setUserVisiblity已被废弃,推荐使用 setMaxLifecycle 处理 Fragment 在 ViewPager 中的懒加载
417 0
一道面试题:ViewPager中的Framgent如何实现懒加载?
DHL
|
设计模式 算法 安全
0xA05 Android 10 源码分析:Dialog加载绘制流程以及在Kotlin、DataBinding中的使用
0xA05 Android 10 源码分析:Dialog加载绘制流程以及在Kotlin、DataBinding中的使用
DHL
415 0
0xA05 Android 10 源码分析:Dialog加载绘制流程以及在Kotlin、DataBinding中的使用