在Android中，真实作为承载页面级别的组件就两个：Activity和Fragment。说起Activity，我想同伴们都非常了解，假如想新建一个页面，那么就创立一个Activity，这个是传统的开发思想。
同伴们能够想一想，当一个项目成规模今后，Activity的量级达到了50+ or 100+，这个时分页面之间的跳转就需求路由来办理，假如想写startActivity写到吐，那么也没问题。那么有没有好的办法能够非常方便地办理页面，并且能够用最少数的Activity，主张同伴们去了解下Navigation，其内部有一套Fragment的办理机制。
为啥要出这篇Fragment核心原理分析，便是由于在项目中运用Navigation的时分遇到了一些问题，可是同伴们或许关于Fragment的原理不是那么了解，像生命周期、Fragment事务办理、回退栈等，那么在运用Navigation的时分，假如想要Hook Navigation源码，不知道怎么处理Fragment之间的跳转逻辑，那么看了这篇文章，或许会有所协助。
1 Fragment根底概念
1.1 Fragment的生命周期
首要咱们先要知道，Fragment是不能像Activity那样独立存在，你能够认为它是一个View，它必须要依赖于Activity存在，并且是受Activity的生命周期影响，然后改动本身的生命周期，反之它没有影响Activity生命周期的能力。
那么咱们从源码的视点看一下，Activity是怎么影响Fragment的生命周期的，然后从实例出发验证一下与源码是否一致。那么咱们从FragmentActivity的onCreate办法开端，当Activity调用onCreate办法的时分，就会回调这个办法。
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
mFragmentLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_CREATE);
mFragments.dispatchCreate();
}
首要咱们看一下，mFragments是什么，它是一个FragmentController，从字面意思上看，是Fragment的一个控制器
final FragmentController mFragments = FragmentController.createController(new HostCallbacks());
当Activity履行onCreate办法的时分，终究是调用FragmentManager的dispatchCreate办法
public void dispatchStart() {
mHost.mFragmentManager.dispatchStart();
}
void dispatchCreate() {
mStateSaved = false;
mStopped = false;
mNonConfig.setIsStateSaved(false);
// 核心代码 - 1
dispatchStateChange(Fragment.CREATED);
}
核心代码 – 1
咱们看下Fragment的生命周期是怎么产生变化的，首要在dispatchStateChange办法中，会传入一个int值，
private void dispatchStateChange(int nextState) {
try {
mExecutingActions = true;
mFragmentStore.dispatchStateChange(nextState);
moveToState(nextState, false);
if (USE_STATE_MANAGER) {
Set<SpecialEffectsController> controllers = collectAllSpecialEffectsController();
for (SpecialEffectsController controller : controllers) {
controller.forceCompleteAllOperations();
}
}
} finally {
mExecutingActions = false;
}
execPendingActions(true);
}
这个值从INITIALIZING -> RESUMED是升序排序，这儿咱们或许会有疑问，Fragment的onPause、onStop、onDestory去哪了，为啥只到了RESUMED。
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.
别着急，咱们往下看moveToState办法。
void moveToState(int newState, boolean always) {
if (mHost == null && newState != Fragment.INITIALIZING) {
throw new IllegalStateException("No activity");
}
if (!always && newState == mCurState) {
return;
}
mCurState = newState;
if (USE_STATE_MANAGER) {
mFragmentStore.moveToExpectedState();
} else {
// Must add them in the proper order. mActive fragments may be out of order
for (Fragment f : mFragmentStore.getFragments()) {
moveFragmentToExpectedState(f);
}
// Now iterate through all active fragments. These will include those that are removed
// and detached.
for (FragmentStateManager fragmentStateManager :
mFragmentStore.getActiveFragmentStateManagers()) {
Fragment f = fragmentStateManager.getFragment();
if (!f.mIsNewlyAdded) {
moveFragmentToExpectedState(f);
}
boolean beingRemoved = f.mRemoving && !f.isInBackStack();
if (beingRemoved) {
mFragmentStore.makeInactive(fragmentStateManager);
}
}
}
startPendingDeferredFragments();
if (mNeedMenuInvalidate && mHost != null && mCurState == Fragment.RESUMED) {
mHost.onSupportInvalidateOptionsMenu();
mNeedMenuInvalidate = false;
}
}
其间，核心办法为moveFragmentToExpectedState，传入的参数为存储的Fragment实例，终究生命周期的同步，是在moveToState办法中，此刻两个参数：一个是Fragment实例，另一个是即将更新的Fragment的生命周期状况。
void moveToState(@NonNull Fragment f, int newState) {
FragmentStateManager fragmentStateManager = mFragmentStore.getFragmentStateManager(f.mWho);
//......
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;
}
}
其实这个办法看着长，可是很简单，便是将newState与当时Fragment的状况做一次比较，假如传入的状况（newState）比当时要大，例如：
f.mState：CREATED -> 1
newState：VIEW_CREATED -> 2
fragmentStateManager.createView();
此刻就会调用fragmentStateManager的createView办法，终究会调用Fragment的onCreateView办法，进行View的创立。
反之，假如传入的状况（newState）比当时要小，例如：
f.mState：RESUMED -> 7
newState：STARTED -> 5
fragmentStateManager.pause();
此刻Fragment就进入了onPuse的状况，所以Google工程师在Androidx之后，将状况就约束到RESUMED，然后经过同步比较状况的这种办法，进行生命周期状况的回调。
假如看过LifeCycle的源码，关于生命周期状况的同步应该也会比较了解，感兴趣的同伴能够看下这篇文章： Android进阶宝典 — Jetpack篇（最新LiveData LifeCycle源码分析）
所以Activity是经过什么手法去影响Fragment生命周期的呢？便是经过FragmentController调用dispatchCreate、dispatchResume……，其实内部是经过FragmentManager来办理，经过生命周期同步的办法来主动调用Fragment的生命周期办法。
1.2 Fragment的事务办理
假如人为办理Fragment，一般都是经过Transaction进行事务办理，
//事务办理
val beginTransaction = supportFragmentManager.beginTransaction()
beginTransaction.add(R.id.fl_fg,Fragment01())
beginTransaction.replace(R.id.fl_fg,Fragment01())
beginTransaction.hide(Fragment01())
beginTransaction.show(Fragment01())
beginTransaction.commit()
大概分为4种操作：add、replace、hide、show；其间在运用的时分，一般是add、replace是一挂，hide和show是一挂，具体的不同咱们稍后再说，咱们先看下Transaction是何许人也。
@NonNull
public FragmentTransaction beginTransaction() {
return new BackStackRecord(this);
}
在调用beginTransaction办法的时分，其实是创立了一个BackStackRecord实例，从字面意思上看是回退栈记载类，用来记载每个Fragment的回退栈的。
那么在调用add、replace、hide、show的时分，其实便是调用BackStackRecord的办法，咱们看下这几个办法的完结。
@NonNull
public FragmentTransaction add(@IdRes int containerViewId, @NonNull Fragment fragment) {
doAddOp(containerViewId, fragment, null, OP_ADD);
return this;
}
在调用add的时分，内部调用了doAddOp办法。
void doAddOp(int containerViewId, Fragment fragment, @Nullable String tag, int opcmd) {
final Class<?> fragmentClass = fragment.getClass();
final int modifiers = fragmentClass.getModifiers();
if (fragmentClass.isAnonymousClass() || !Modifier.isPublic(modifiers)
|| (fragmentClass.isMemberClass() && !Modifier.isStatic(modifiers))) {
throw new IllegalStateException("Fragment " + fragmentClass.getCanonicalName()
+ " must be a public static class to be properly recreated from"
+ " instance state.");
}
if (tag != null) {
if (fragment.mTag != null && !tag.equals(fragment.mTag)) {
throw new IllegalStateException("Can't change tag of fragment "
+ fragment + ": was " + fragment.mTag
+ " now " + tag);
}
fragment.mTag = tag;
}
if (containerViewId != 0) {
if (containerViewId == View.NO_ID) {
throw new IllegalArgumentException("Can't add fragment "
+ fragment + " with tag " + tag + " to container view with no id");
}
if (fragment.mFragmentId != 0 && fragment.mFragmentId != containerViewId) {
throw new IllegalStateException("Can't change container ID of fragment "
+ fragment + ": was " + fragment.mFragmentId
+ " now " + containerViewId);
}
fragment.mContainerId = fragment.mFragmentId = containerViewId;
}
addOp(new Op(opcmd, fragment));
}
doAddOp办法前面是做了一些判别，有几个参数我要说一下：
（1）tag：这个参数能够在咱们调用add的时分自定义传入，假如咱们想要获取add参加的这个Fragment，能够经过findFragmentByTag办法来获取；
（2）containerViewId：这个是装载Fragment的容器，一般需求咱们自行设置一个FrameLayout，取FrameLayout的id。
最后调用addOp办法，创立一个Op对象，其间Op对象中有两个参数比较重要：opcmd代表要履行的操作，例如OP_ADD（add操作）、fragment代表创立的Fragment的实例。
void addOp(Op op) {
mOps.add(op);
op.mEnterAnim = mEnterAnim;
op.mExitAnim = mExitAnim;
op.mPopEnterAnim = mPopEnterAnim;
op.mPopExitAnim = mPopExitAnim;
}
创立完结之后，存放在mOps数组中。
@NonNull
public FragmentTransaction replace(@IdRes int containerViewId, @NonNull Fragment fragment,
@Nullable String tag) {
if (containerViewId == 0) {
throw new IllegalArgumentException("Must use non-zero containerViewId");
}
doAddOp(containerViewId, fragment, tag, OP_REPLACE);
return this;
}
@NonNull
public FragmentTransaction hide(@NonNull Fragment fragment) {
addOp(new Op(OP_HIDE, fragment));
return this;
}
@NonNull
public FragmentTransaction show(@NonNull Fragment fragment) {
addOp(new Op(OP_SHOW, fragment));
return this;
}
除此之外，咱们看下replace、hide、show的逻辑，其实都是创立一个Op对象，然后存放在mOps数组中，当所有的事务准备好之后，终究需求调用commit来履行。
beginTransaction.commit()
beginTransaction.commitAllowingStateLoss()
beginTransaction.commitNow()
beginTransaction.commitNowAllowingStateLoss()
commit履行有以上四种办法，这4种办法有什么差异呢？咱们从源码视点来看一下。
commit和commitAllowingStateLoss的差异
@Override
public int commit() {
return commitInternal(false);
}
咱们看到，在commit办法履行的时分，其实是调用了commitInternal办法，传入了一个false参数，代表是否答应状况丢掉。
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;
}
其实看到这儿，咱们能够猜到commitAllowingStateLoss办法调用的时分，commitInternal办法传入的必定是true，答应状况丢掉。
@Override
public int commitAllowingStateLoss() {
return commitInternal(true);
}
在commitInternal办法中，调用了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);
// 核心代码 - 2
scheduleCommit();
}
}
在一开端就判别allowStateLoss是否为false，假如为false，也便是经过commit办法提交，那么会进入代码块，调用checkStateLoss办法。
private void checkStateLoss() {
if (isStateSaved()) {
throw new IllegalStateException(
"Can not perform this action after onSaveInstanceState");
}
}
public boolean isStateSaved() {
// See saveAllState() for the explanation of this. We do this for
// all platform versions, to keep our behavior more consistent between
// them.
return mStateSaved || mStopped;
}
在这个办法中，会判别当时Fragment的状况，有两个值mStateSaved 或者 mStopped有一个为true，那么就会抛反常。
我说一个场景：当用户退出后台的瞬间，调用commit事务提交，此刻mStopped = true，运用就会溃散。其实这种场景仍是比较常见的，在开发中或许很少碰到，可是假如上线后从bugly中或许会看到这种溃散，可是用户其实是无感知的，所以这种情况下主张运用commitAllowingStateLoss。
所以当Activity状况产生变化的时分，例如退出后台、屏幕旋转等，运用commitAllowingStateLoss不会抛反常。
commitNow和commitNowAllowingStateLoss的差异
这两种提交办法，咱们运用的如同比较少，咱们看下他俩和前面的有啥差异。
@Override
public void commitNow() {
disallowAddToBackStack();
mManager.execSingleAction(this, false);
}
@Override
public void commitNowAllowingStateLoss() {
disallowAddToBackStack();
mManager.execSingleAction(this, true);
}
首要从源码中咱们看到，这种提交办法是不答应将Fragment参加到回退栈的，在这个办法中，会将mAllowAddToBackStack设置为false。
@NonNull
public FragmentTransaction disallowAddToBackStack() {
if (mAddToBackStack) {
throw new IllegalStateException(
"This transaction is already being added to the back stack");
}
mAllowAddToBackStack = false;
return this;
}
那么这个时分，假如调用addToBackStack办法，由于mAllowAddToBackStack = false，此刻就直接抛出反常。
@NonNull
public FragmentTransaction addToBackStack(@Nullable String name) {
if (!mAllowAddToBackStack) {
throw new IllegalStateException(
"This FragmentTransaction is not allowed to be added to the back stack.");
}
mAddToBackStack = true;
mName = name;
return this;
}
并且调用commitNow办法的时分，假如当时Fragment现已被参加到回退栈了，也会抛出反常。
核心代码 – 2
这是一个差异，接下来咱们关注一下commit提交和commitNow提交的另一个差异。假如经过commit提交，那么终究调用这个办法scheduleCommit，咱们看到是经过Handler来发送一个音讯来异步履行事务的提交；
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();
}
}
}
那么commitNow在履行事务提交的时分，咱们看下execSingleAction办法，发现是同步完结的，所以两者的另一个差异便是履行事务时，commit是异步操作，而commitNow是同步的。
void execSingleAction(@NonNull OpGenerator action, boolean allowStateLoss) {
if (allowStateLoss && (mHost == null || mDestroyed)) {
// This FragmentManager isn't attached, so drop the entire transaction.
return;
}
ensureExecReady(allowStateLoss);
if (action.generateOps(mTmpRecords, mTmpIsPop)) {
mExecutingActions = true;
try {
removeRedundantOperationsAndExecute(mTmpRecords, mTmpIsPop);
} finally {
cleanupExec();
}
}
updateOnBackPressedCallbackEnabled();
doPendingDeferredStart();
mFragmentStore.burpActive();
}
所以这个会解决什么问题呢？了解的Handler的同伴们应该知道，所有Handler发送的音讯都会存在MessageQueue中，Looper经过loop办法从MessageQueue中取出事情并履行，所以当咱们经过commit去提交增加一个Fragment的时分，假如还没有履行到这个事情，就经过findFragmentByTag or findFragmentById去查找这个Fragment就会找不到，有没有同伴们碰到过这个问题？
所以假如咱们事务场景中必须要确保要拿到这个Fragment，那么主张运用commitNow这个提交办法，可是需求留意回退栈的问题，咱们能够经过反射的办法，将mAllowAddToBackStack设置为true，防止抛出反常。可是这种办法也需求根据场景酌情运用，由于频繁地运用commitNow或许会导致卡顿。
1.3 Fragment状况保存
当咱们的运用产生反常，或者Activity的状况产生变化时，咱们想保存Fragment的状况，以便后续的展示，那么咱们先看下 Activity # onSaveInstanceState办法是怎么完结的。
protected void onSaveInstanceState(@NonNull Bundle outState) {
outState.putBundle(WINDOW_HIERARCHY_TAG, mWindow.saveHierarchyState());
outState.putInt(LAST_AUTOFILL_ID, mLastAutofillId);
// 1
Parcelable p = mFragments.saveAllState();
if (p != null) {
outState.putParcelable(FRAGMENTS_TAG, p);
}
if (mAutoFillResetNeeded) {
outState.putBoolean(AUTOFILL_RESET_NEEDED, true);
getAutofillManager().onSaveInstanceState(outState);
}
dispatchActivitySaveInstanceState(outState);
}
首要，咱们看调用了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(true);
mStateSaved = true;
mNonConfig.setIsStateSaved(true);
// First collect all active fragments.
ArrayList<FragmentState> active = mFragmentStore.saveActiveFragments();
if (active.isEmpty()) {
if (isLoggingEnabled(Log.VERBOSE)) Log.v(TAG, "saveAllState: no fragments!");
return null;
}
// Build list of currently added fragments.
ArrayList<String> added = mFragmentStore.saveAddedFragments();
// Now save back stack.
BackStackState[] backStack = null;
if (mBackStack != null) {
int size = mBackStack.size();
if (size > 0) {
backStack = new BackStackState[size];
for (int i = 0; i < size; i++) {
backStack[i] = new BackStackState(mBackStack.get(i));
if (isLoggingEnabled(Log.VERBOSE)) {
Log.v(TAG, "saveAllState: adding back stack #" + i
+ ": " + mBackStack.get(i));
}
}
}
}
FragmentManagerState fms = new FragmentManagerState();
fms.mActive = active;
fms.mAdded = added;
fms.mBackStack = backStack;
fms.mBackStackIndex = mBackStackIndex.get();
if (mPrimaryNav != null) {
fms.mPrimaryNavActiveWho = mPrimaryNav.mWho;
}
fms.mResultKeys.addAll(mResults.keySet());
fms.mResults.addAll(mResults.values());
fms.mLaunchedFragments = new ArrayList<>(mLaunchedFragments);
return fms;
}
首要拿到当时页面展示的Fragment，并将其封装为FragmentState，回来的是一个列表；然后拿到经过事务增加进来的悉数Fragment的UUID集合，终究创立一个FragmentManagerState类，然后将悉数的Fragment的状况存储到FragmentManagerState中，终究回来的序列化数据便是FragmentManagerState。
那么康复数据，其实便是一个反序列化的进程，经过拿到FragmentManagerState数据之后，康复所有Fragment在毁掉之前的状况。
这儿需求留意一点，当体系康复Fragment的时分，是选用反射的办法进行Fragment的创立，此刻是经过newInstance()的办法完结的，所以Fragment必定要有一个空参构造办法，否则直接抛反常。
1.4 Fragment回退栈办理
假如阅读过Navigation源码，咱们会发现，当履行commit之前，都会将Fragment参加回退栈，那么将Fragment增加到回退栈和不增加到回退栈，有什么差异呢？
咱们看下面这个场景，当创立Fragment01之后，点击按钮跳转到Fragment02，此刻咱们看当Fragment02展示之后，Fragment01直接走了毁掉的流程，并且现已调用了onDestroy办法。
2023-02-11 18:35:56.070 30604-30604/com.lay.learn.asm E/TAG: Fragment01 onAttach
2023-02-11 18:35:56.071 30604-30604/com.lay.learn.asm E/TAG: Fragment01 onCreate
2023-02-11 18:35:56.072 30604-30604/com.lay.learn.asm E/TAG: Fragment01 onCreateView
2023-02-11 18:35:56.085 30604-30604/com.lay.learn.asm E/TAG: Fragment01 onViewCreated
2023-02-11 18:35:56.095 30604-30604/com.lay.learn.asm E/TAG: Fragment01 onResume
2023-02-11 18:36:45.065 30604-30604/com.lay.learn.asm E/TAG: Fragment01 onPause
2023-02-11 18:36:45.068 30604-30604/com.lay.learn.asm E/TAG: Fragment01 onStop
2023-02-11 18:36:45.072 30604-30604/com.lay.learn.asm E/TAG: Fragment02 onAttach
2023-02-11 18:36:45.075 30604-30604/com.lay.learn.asm E/TAG: Fragment02 onCreate
2023-02-11 18:36:45.079 30604-30604/com.lay.learn.asm E/TAG: Fragment02 onCreateView
2023-02-11 18:36:45.118 30604-30604/com.lay.learn.asm E/TAG: Fragment02 onViewCreated
2023-02-11 18:36:45.138 30604-30604/com.lay.learn.asm E/TAG: Fragment01 onDestroyView
2023-02-11 18:36:45.162 30604-30604/com.lay.learn.asm E/TAG: Fragment01 onDestroy
2023-02-11 18:36:45.165 30604-30604/com.lay.learn.asm E/TAG: Fragment02 onResume
当咱们将Fragment01参加到回退栈之后，咱们发现，Fragment01如同并没有调用onDestory办法，仅仅是将View毁掉了
2023-02-11 18:41:05.538 30912-30912/com.lay.learn.asm E/TAG: Fragment01 onAttach
2023-02-11 18:41:05.540 30912-30912/com.lay.learn.asm E/TAG: Fragment01 onCreate
2023-02-11 18:41:05.542 30912-30912/com.lay.learn.asm E/TAG: Fragment01 onCreateView
2023-02-11 18:41:05.560 30912-30912/com.lay.learn.asm E/TAG: Fragment01 onViewCreated
2023-02-11 18:41:05.576 30912-30912/com.lay.learn.asm E/TAG: Fragment01 onResume
2023-02-11 18:41:09.784 30912-30912/com.lay.learn.asm E/TAG: Fragment01 onPause
2023-02-11 18:41:09.787 30912-30912/com.lay.learn.asm E/TAG: Fragment01 onStop
2023-02-11 18:41:09.788 30912-30912/com.lay.learn.asm E/TAG: Fragment02 onAttach
2023-02-11 18:41:09.790 30912-30912/com.lay.learn.asm E/TAG: Fragment02 onCreate
2023-02-11 18:41:09.796 30912-30912/com.lay.learn.asm E/TAG: Fragment02 onCreateView
2023-02-11 18:41:09.811 30912-30912/com.lay.learn.asm E/TAG: Fragment02 onViewCreated
2023-02-11 18:41:09.819 30912-30912/com.lay.learn.asm E/TAG: Fragment01 onDestroyView
2023-02-11 18:41:09.837 30912-30912/com.lay.learn.asm E/TAG: Fragment02 onResume
那么此刻，咱们点击回来按钮，这个时分咱们发现Fragment01生命周期是从头重新履行了吗？并没有，而是直接从onCreateView开端，没有履行onCreate。
2023-02-11 19:04:42.886 25027-25027/com.lay.learn.asm E/TAG: Fragment01 onAttach
2023-02-11 19:04:42.887 25027-25027/com.lay.learn.asm E/TAG: Fragment01 onCreate
2023-02-11 19:04:42.888 25027-25027/com.lay.learn.asm E/TAG: Fragment01 onCreateView
2023-02-11 19:04:42.897 25027-25027/com.lay.learn.asm E/TAG: Fragment01 onViewCreated
2023-02-11 19:04:42.908 25027-25027/com.lay.learn.asm E/TAG: Fragment01 onResume
2023-02-11 19:04:45.572 25027-25027/com.lay.learn.asm E/TAG: Fragment01 onPause
2023-02-11 19:04:45.572 25027-25027/com.lay.learn.asm E/TAG: Fragment01 onStop
2023-02-11 19:04:45.573 25027-25027/com.lay.learn.asm E/TAG: Fragment02 onAttach
2023-02-11 19:04:45.574 25027-25027/com.lay.learn.asm E/TAG: Fragment02 onCreate
2023-02-11 19:04:45.574 25027-25027/com.lay.learn.asm E/TAG: Fragment02 onCreateView
2023-02-11 19:04:45.582 25027-25027/com.lay.learn.asm E/TAG: Fragment02 onViewCreated
2023-02-11 19:04:45.585 25027-25027/com.lay.learn.asm E/TAG: Fragment01 onDestroyView
2023-02-11 19:04:45.588 25027-25027/com.lay.learn.asm E/TAG: Fragment02 onResume
2023-02-11 19:04:46.874 25027-25027/com.lay.learn.asm E/TAG: Fragment02 onPause
2023-02-11 19:04:46.875 25027-25027/com.lay.learn.asm E/TAG: Fragment02 onStop
2023-02-11 19:04:46.875 25027-25027/com.lay.learn.asm E/TAG: Fragment01 onCreateView
2023-02-11 19:04:46.881 25027-25027/com.lay.learn.asm E/TAG: Fragment01 onViewCreated
2023-02-11 19:04:46.883 25027-25027/com.lay.learn.asm E/TAG: Fragment02 onDestroyView
2023-02-11 19:04:46.884 25027-25027/com.lay.learn.asm E/TAG: Fragment02 onDestroy
2023-02-11 19:04:46.885 25027-25027/com.lay.learn.asm E/TAG: Fragment01 onResume
所以参加回退栈的效果，我给同伴们总结一下：
（1）经过replace的办法履行页面之间的切换，参加回退栈能够防止数据丢掉（onDestory时ViewModel数据会被铲除），防止页面被直接毁掉；
（2）参加回退栈更符合用户行为逻辑，从哪个页面来回来就回来哪个页面，并且不会重复调用onCreate办法，因而能够放网络恳求的逻辑，防止屡次接口恳求。
咱们这儿带一下Navigation的回退栈办理
private fun navigate(
entry: NavBackStackEntry,
navOptions: NavOptions?,
navigatorExtras: Navigator.Extras?
) {
val initialNavigation = state.backStack.value.isEmpty()
val restoreState = (
navOptions != null && !initialNavigation &&
navOptions.shouldRestoreState() &&
savedIds.remove(entry.id)
)
if (restoreState) {
// Restore back stack does all the work to restore the entry
fragmentManager.restoreBackStack(entry.id)
state.push(entry)
return
}
val ft = createFragmentTransaction(entry, navOptions)
if (!initialNavigation) {
ft.addToBackStack(entry.id)
}
if (navigatorExtras is Extras) {
for ((key, value) in navigatorExtras.sharedElements) {
ft.addSharedElement(key, value)
}
}
ft.commit()
// The commit succeeded, update our view of the world
state.push(entry)
}
这儿有个变量需求留意一下：initialNavigation，它是一个boolean类型，判别当时回退栈是否为空，假如是第一次运用，那么就为空，此刻不会给当时页面增加回退栈。这儿其实很好了解，假如把起点参加回退栈，那么在回来的时分，起点其实现已没有上级页面了，就不知道要往哪跳，所以体系会生成一个空白页面，这儿大家能够运用一下。
当然有些问题仍是防止不了，由于假如参加回退栈，那么Fragment的onCreateView或许会被屡次履行，会导致页面的状况产生变化，无法保留前次页面跳转时状况，页面会被刷新，因而能够考虑运用hide show的办法来进行页面状况办理。
2 Fragment常见问题解决
这个模块我主要介绍一下咱们在日常开发中经常会遇到的问题
2.1 Can not perform this action after onSaveInstanceState
在调用commit办法的时分，由于allowStateloss为false，所以需求查看状况。
private void checkStateLoss() {
if (isStateSaved()) {
throw new IllegalStateException(
"Can not perform this action after onSaveInstanceState");
}
}
public boolean isStateSaved() {
// See saveAllState() for the explanation of this. We do this for
// all platform versions, to keep our behavior more consistent between
// them.
return mStateSaved || mStopped;
}
假如在当时页面发起网络恳求，比及恳求结果之前或许会有耗时，然后此刻跳转到了下一个页面，咱们知道这个页面的生命周期会走到onDestoryView，此刻会触发onSaveInstance办法，mStateSaved会设置为true，那么此刻假如在拿到结果之后又进行了一次commit，就直接回抛出反常。
所以关于commit提交来说，不主张在子线程中进行；假如确实需求这种操作，那么就主张运用commitAllowingStateLoss。
或许很多同伴也会猎奇，在实际开发中这种问题很难碰到，一翻bugly就会看到好多线上用户报这个问题。这个便是用户场景咱们无法cover全掩盖，用户或许用2G、3G网络就会呈现网络加载缓慢的问题。
2.2 Fragment的堆叠问题
这种问题其实假如了解体系的康复机制，应该仍是很好防止。为什么会呈现Fragment堆叠的问题呢？首要咱们做的时分是在Activity # onCreate办法中进行add操作。
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_my_fragment_actvity)
fl_fg = findViewById(R.id.fl_fg)
btn_jump = findViewById(R.id.btn_jump)
btn_jump.setOnClickListener {
val transient = supportFragmentManager.beginTransaction()
transient.replace(R.id.fl_fg,Fragment02())
transient.addToBackStack(null)
transient.commit()
}
//事务办理
val beginTransaction = supportFragmentManager.beginTransaction()
beginTransaction.add(R.id.fl_fg, Fragment01())
beginTransaction.addToBackStack("Fragment01")
beginTransaction.commit()
}
假如此刻屏幕进行旋转，前提是在没有任何配置的情况下，Activity会被毁掉重建，此刻按照咱们在1.3小节中关于Fragment状况保存的了解，此刻会将Fragment的状况保存为FragmentManagerState并将其序列化，在Activity重建之后，onCreate中会获取FragmentManagerState并重建Fragment，此刻其实体系现已帮咱们重建了Fragment，可是咱们在onCreate中再次进行了add操作，此刻就会造成Fragment叠加。
其实咱们了解这个机制之后就很好解决了，首要第一种计划：在onSaveInstanceState办法中，不去保存Fragment的状况，可是这种计划或许会有危险，由于一刀切或许会影响其他的功能。
另一种便是调用add的机遇，当savedInstanceState为空的时分，一般便是首次进来的时分，这个时分就能够履行add；可是假如是重建状况下，savedInstanceState不为空，就不需求自行add，运用体系帮咱们康复的那一份就行。
if (savedInstanceState == null) {
//事务办理
val beginTransaction = supportFragmentManager.beginTransaction()
beginTransaction.add(R.id.fl_fg, Fragment01())
beginTransaction.addToBackStack("Fragment01")
beginTransaction.commit()
}
除此之外，之前在运用Navigation的时分，由于官方的那种办法是选用replace的办法会导致View的状况丢掉，因而自定义了一个FragmentNavigator，可是落实到项目中的时分，发现一个堆叠的问题。 Android进阶宝典 — JetPack Navigation的高级用法（解决路由跳转新建Fragment页面问题）
val ft = fragmentManager.beginTransaction()
val currentFragment = fragmentManager.primaryNavigationFragment
KLog.d(TAG,"currentFragment $currentFragment")
//将当时Fragment躲藏
if (currentFragment != null) {
ft.hide(currentFragment)
}
//获取目的地Fragment
val destinationId = destination.id.toString()
var nextFragment = fragmentManager.findFragmentByTag(destinationId)
if (nextFragment != null) {
ft.show(nextFragment)
} else {
//阐明当时Fragment没有被创立过
nextFragment =
fragmentManager.fragmentFactory.instantiate(context.classLoader, className)
nextFragment.arguments = args
ft.add(containerId, nextFragment, destinationId)
}
由于官方提交事务都是commit，所以自定义Navigator的时分，事务提交也是选用的commit；所以从1.2小节中咱们关于commit的原理的认知，这是一个异步的进程，看下图：
首要Fragment1为起点，在加载路由表的时分，先将Fragment add到NavHostFragment中；由于commit是一个异步的进程或许有推迟，此刻调用navigate从Fragment1跳转到Fragment2，按照上面代码中的逻辑，首要会调用primaryNavigationFragment获取当时页面实例（Fragment1），此刻由于commit推迟导致没有获取到，此刻currentFragment = null，躲藏失利！
那么当加载完结Fragment2的时分，Fragment1也加载完结，此刻两个页面就产生了堆叠；所以这种情况下，就需求考虑运用commitNow做同步处理，可是需求留意运用commitNow就不答应参加回退栈，这儿还需求考虑运用反射将标志位取反。
目前我在事务场景中做的处理是在Fragment1调用onAttach的时分，此刻Fragment现已创立，然后调用navigate进行跳转。
当然还有一种Fragment堆叠的问题，便是屡次调用add往同一个containerId中增加，此刻Fragment就会悉数堆叠到一同，可是这种情况下，不会影响恣意一个Fragment的生命周期，即便是下面的Fragment现已不行见了；而replace则是会将当时容器中Fragment毁掉，然后再增加新的Fragment，这便是add和replace的差异。
这一篇文章原理性的东西比较多，可是运用上很少介绍，信任大部分的同伴们应该都了解运用办法，可是在运用的时分或许都会遇到一些问题，假如了解了其间的原理，定位问题也会比较迅速，并且在运用api的时分也会更加谨慎。
