Fragment 相信基本上每個android developer都用過，但是知曉其原理 用的好的還是不多，今天就從源碼的角度上來帶著大家分析一下Fragment的源碼，對fragment有了更深層次的認識以后相信

寫出來的代碼也會越來越好看。

首先，我們來看第一個流程，fragment是怎么加載到界面上的，借著這個流程分析，能讀完絕大多數fragment的源碼。

一般我們顯示一個fragment的時候 喜歡如下這種做法：

1 blankFragment=new BlankFragment(); 2 fm=getFragmentManager(); 3 FragmentTransaction ft=fm.beginTransaction(); 4 ft.replace(R.id.rootView,blankFragment); 5 ft.commit();

?

這段代碼相信大家都很熟悉了，我們就來一步步跟進去看看 ，2-5 執行結束以后 是怎么把fragment界面顯示到手機屏幕上的。

1 //下面的代碼 來自于activity里面！！！！！！！！！！！！！！！ 2 public FragmentManager getFragmentManager() { 3 //到這里能發現是mFragments返回給我們的FragmentManager 4 return mFragments.getFragmentManager(); 5 } 6 7 //繼續往下跟 就會發現mFragments是由FragmentController的createController函數 構造出來的一個對象， 8 //并且這個函數 需要傳進去一個HostCallBack的對象 9 final FragmentController mFragments = FragmentController.createController(new HostCallbacks()); 10 11 12 13 //下面的代碼就來自于FragmentController 這個類！！！！！ 14 private final FragmentHostCallback<?> mHost; 15 16 //從這個函數就能看出來HostCallbacks 這個類肯定是FragmentHostCallback的子類了 17 public static final FragmentController createController(FragmentHostCallback<?> callbacks) { 18 return new FragmentController(callbacks); 19 } 20 21 private FragmentController(FragmentHostCallback<?> callbacks) { 22 mHost = callbacks; 23 } 24 25 //所以這個getFragmentManager返回的就是FragmentManager這個對象，并且這個對象是mHost的getFragmentManagerImpl函數返回的。 26 //這里結合構造函數一看就明白了，這個mHost就是我們在activity代碼里面，第12行那里傳進去的HostCallbacks這個對象來幫助初始化的 27 public FragmentManager getFragmentManager() { 28 return mHost.getFragmentManagerImpl(); 29 } 30 31 32 //下面的代碼在activity里 33 //這個地方一目了然 果然我們這個HostCallbacks 這個類是繼承自FragmentHostCallback的，并且能看出來，我們這里把activity的引用也傳進去了。 34 //所以能馬上得出一個結論就是一個activity對應著一個HostCallbacks對象 這個對象持有本身這個activity的引用。傳進去以后就代表FragmentController 35 //這個類的成員mHost 也持有了activity的引用 36 class HostCallbacks extends FragmentHostCallback<Activity> { 37 public HostCallbacks() { 38 super(Activity.this /*activity*/); 39 } 40 41 @Override 42 public void onDump(String prefix, FileDescriptor fd, PrintWriter writer, String[] args) { 43 Activity.this.dump(prefix, fd, writer, args); 44 } 45 .................略過余下代碼 46 } 47 48 //下面的代碼來源自 FragmentHostCallback<E> 這個抽象類 49 50 public FragmentHostCallback(Context context, Handler handler, int windowAnimations) { 51 this(null /*activity*/, context, handler, windowAnimations); 52 } 53 54 FragmentHostCallback(Activity activity) { 55 this(activity, activity /*context*/, activity.mHandler, 0 /*windowAnimations*/); 56 } 57 58 //到這里就能看到FragmentHostCallback 持有了acitivty的引用 并且連activity的handler都一并持有！ 59 FragmentHostCallback(Activity activity, Context context, Handler handler, 60 int windowAnimations) { 61 mActivity = activity; 62 mContext = context; 63 mHandler = handler; 64 mWindowAnimations = windowAnimations; 65 }

上面 初步分析了getFragmentManager這個方法的由來。那繼續看這個方法到底是返回的什么？

1 //下面的代碼來源自抽象類FragmentHostCallback 2 FragmentManagerImpl getFragmentManagerImpl() { 3 return mFragmentManager; 4 } 5 //所以就能看出來 我們在activity中調用的getFragmentManger這個方法最終返回的是FragmentManagerImpl 這個類的對象了 6 final FragmentManagerImpl mFragmentManager = new FragmentManagerImpl();

再進去看看 這個對象的begin方法返回的是什么

1 //源碼來自于抽象類 FragmentManager 2 public FragmentTransaction beginTransaction() { 3 //可以看出來 返回的是BackStackRecord 這個類的對象 4 return new BackStackRecord(this); 5 } 6 //下面的代碼來自于BackStackState這個類 7 //可以看到這個類是一個final類 8 final class BackStackState implements Parcelable { 9 } 10 11 //注意BackStackRecord這個類 和BackStackState 是在同一個文件內的 12 //可以看一下BackStackRecord 是FragmentTransaction的子類 并且實現了 13 //BackStackEntry, Runnable這兩個接口 14 final class BackStackRecord extends FragmentTransaction implements 15 FragmentManager.BackStackEntry, Runnable { 16 static final String TAG = FragmentManagerImpl.TAG; 17 18 final FragmentManagerImpl mManager; 19 } 20 21 //下面的這個class就是在BackStackRecord這個類的源碼里面的，這里Op 22 //實際上就是一個雙向鏈表結構 23 static final class Op { 24 Op next; 25 Op prev; 26 int cmd; 27 Fragment fragment; 28 int enterAnim; 29 int exitAnim; 30 int popEnterAnim; 31 int popExitAnim; 32 ArrayList<Fragment> removed; 33 } 34

你看 所以begintranscation返回的最終就是backstackrecord對象了。

我們繼續看看這個對象的操作

1 //以下代碼來源自backstackrecord 源碼 2 public FragmentTransaction replace(int containerViewId, Fragment fragment) { 3 return replace(containerViewId, fragment, null); 4 } 5 6 //你看這里replace操作 你如果沒有傳進去一個有效的id的話 異常就會在這里出現了 7 public FragmentTransaction replace(int containerViewId, Fragment fragment, String tag) { 8 if (containerViewId == 0) { 9 throw new IllegalArgumentException("Must use non-zero containerViewId"); 10 } 11 12 //最終都是調用的doaAdddop這個方法來完成操作的 13 doAddOp(containerViewId, fragment, tag, OP_REPLACE); 14 return this; 15 } 16 17 //這個方法說白了 就是拼裝下這個雙向鏈表 18 private void doAddOp(int containerViewId, Fragment fragment, String tag, int opcmd) { 19 fragment.mFragmentManager = mManager; 20 21 if (tag != null) { 22 if (fragment.mTag != null && !tag.equals(fragment.mTag)) { 23 throw new IllegalStateException("Can't change tag of fragment " 24 + fragment + ": was " + fragment.mTag 25 + " now " + tag); 26 } 27 fragment.mTag = tag; 28 } 29 30 if (containerViewId != 0) { 31 if (fragment.mFragmentId != 0 && fragment.mFragmentId != containerViewId) { 32 throw new IllegalStateException("Can't change container ID of fragment " 33 + fragment + ": was " + fragment.mFragmentId 34 + " now " + containerViewId); 35 } 36 fragment.mContainerId = fragment.mFragmentId = containerViewId; 37 } 38 39 Op op = new Op(); 40 op.cmd = opcmd; 41 op.fragment = fragment; 42 addOp(op); 43 } 44 45 //所以我們看到 replace操作或者是add remove這種操作 就是操作雙向鏈表的 除此之外沒有任何有意義的舉動，最終反應到用戶能感知的層面上全都是要走 46 //commit這個函數的 47 public int commit() { 48 return commitInternal(false); 49 } 50 //構造函數再看一遍 51 52 public BackStackRecord(FragmentManagerImpl manager) { 53 mManager = manager; 54 } 55 int commitInternal(boolean allowStateLoss) { 56 if (mCommitted) { 57 throw new IllegalStateException("commit already called"); 58 } 59 if (FragmentManagerImpl.DEBUG) { 60 Log.v(TAG, "Commit: " + this); 61 LogWriter logw = new LogWriter(Log.VERBOSE, TAG); 62 PrintWriter pw = new FastPrintWriter(logw, false, 1024); 63 dump(" ", null, pw, null); 64 pw.flush(); 65 } 66 mCommitted = true; 67 if (mAddToBackStack) { 68 mIndex = mManager.allocBackStackIndex(this); 69 } else { 70 mIndex = -1; 71 } 72 //這個對象就是 final FragmentManagerImpl mManager; 我們在調用begin函數的時候傳進去一個this指針 就是用來初始化他的 73 mManager.enqueueAction(this, allowStateLoss); 74 return mIndex; 75 } 76 77 //所以下面就是FragmentManagerImpl 的源碼了 final class FragmentManagerImpl extends FragmentManager implements LayoutInflater.Factory2 78 79 //這個函數就很關鍵了，這個mHost 前文介紹過 持有了activity的引用，所以這里你看 就是用activity的handler 去執行了mExecCommit 80 //注意是在activity的主線程去執行的mExecCommit 這個線程 81 public void enqueueAction(Runnable action, boolean allowStateLoss) { 82 if (!allowStateLoss) { 83 checkStateLoss(); 84 } 85 synchronized (this) { 86 if (mDestroyed || mHost == null) { 87 throw new IllegalStateException("Activity has been destroyed"); 88 } 89 if (mPendingActions == null) { 90 mPendingActions = new ArrayList<Runnable>(); 91 } 92 mPendingActions.add(action); 93 if (mPendingActions.size() == 1) { 94 mHost.getHandler().removeCallbacks(mExecCommit); 95 mHost.getHandler().post(mExecCommit); 96 } 97 } 98 } 99 //這個線程執行的execPendingActions 就是這個方法 這個方法也是在FragmentManagerImpl 里的。并不在activity里。所以commit操作就是最終讓activity的主線程去執行了FragmentManagerImpl 100 //execPendingActions方法 101 Runnable mExecCommit = new Runnable() { 102 @Override 103 public void run() { 104 execPendingActions(); 105 } 106 }; 107 108 /** 109 * 所以這個方法是只能在主線程里面做的 110 */ 111 public boolean execPendingActions() { 112 if (mExecutingActions) { 113 throw new IllegalStateException("Recursive entry to executePendingTransactions"); 114 } 115 116 if (Looper.myLooper() != mHost.getHandler().getLooper()) { 117 throw new IllegalStateException("Must be called from main thread of process"); 118 } 119 120 boolean didSomething = false; 121 122 while (true) { 123 int numActions; 124 125 synchronized (this) { 126 if (mPendingActions == null || mPendingActions.size() == 0) { 127 break; 128 } 129 130 numActions = mPendingActions.size(); 131 if (mTmpActions == null || mTmpActions.length < numActions) { 132 mTmpActions = new Runnable[numActions]; 133 } 134 mPendingActions.toArray(mTmpActions); 135 mPendingActions.clear(); 136 mHost.getHandler().removeCallbacks(mExecCommit); 137 } 138 139 mExecutingActions = true; 140 for (int i=0; i<numActions; i++) { 141 //你看這里run方法 回過頭去 我們應該還能想起來backstackrecord這個類是繼承了runnable這個接口的，所以最終我們還是要看看backstackrecord 的run方法里面都做了什么 142 mTmpActions[i].run(); 143 mTmpActions[i] = null; 144 } 145 mExecutingActions = false; 146 didSomething = true; 147 } 148 149 if (mHavePendingDeferredStart) { 150 boolean loadersRunning = false; 151 for (int i=0; i<mActive.size(); i++) { 152 Fragment f = mActive.get(i); 153 if (f != null && f.mLoaderManager != null) { 154 loadersRunning |= f.mLoaderManager.hasRunningLoaders(); 155 } 156 } 157 if (!loadersRunning) { 158 mHavePendingDeferredStart = false; 159 startPendingDeferredFragments(); 160 } 161 } 162 return didSomething; 163 }

一直到這里 我們就知道，commit操作 最終執行的實際上是我們backstackrecord 這個類里的run方法。

1 //以下代碼就是backstackrecord里面的代碼了 2 //這個run方法 其實就是取op這個雙向鏈表然后分析op.cmd的值 然后根據 3 //這些不同的值 去調用FragmentManager里各種轉換fragment 4 public void run() { 5 if (FragmentManagerImpl.DEBUG) { 6 Log.v(TAG, "Run: " + this); 7 } 8 9 if (mAddToBackStack) { 10 if (mIndex < 0) { 11 throw new IllegalStateException("addToBackStack() called after commit()"); 12 } 13 } 14 15 bumpBackStackNesting(1); 16 17 SparseArray<Fragment> firstOutFragments = new SparseArray<Fragment>(); 18 SparseArray<Fragment> lastInFragments = new SparseArray<Fragment>(); 19 calculateFragments(firstOutFragments, lastInFragments); 20 beginTransition(firstOutFragments, lastInFragments, false); 21 22 Op op = mHead; 23 while (op != null) { 24 switch (op.cmd) { 25 case OP_ADD: { 26 Fragment f = op.fragment; 27 f.mNextAnim = op.enterAnim; 28 mManager.addFragment(f, false); 29 } 30 break; 31 case OP_REPLACE: { 32 Fragment f = op.fragment; 33 int containerId = f.mContainerId; 34 if (mManager.mAdded != null) { 35 for (int i = 0; i < mManager.mAdded.size(); i++) { 36 Fragment old = mManager.mAdded.get(i); 37 if (FragmentManagerImpl.DEBUG) { 38 Log.v(TAG, 39 "OP_REPLACE: adding=" + f + " old=" + old); 40 } 41 if (old.mContainerId == containerId) { 42 if (old == f) { 43 op.fragment = f = null; 44 } else { 45 if (op.removed == null) { 46 op.removed = new ArrayList<Fragment>(); 47 } 48 op.removed.add(old); 49 old.mNextAnim = op.exitAnim; 50 if (mAddToBackStack) { 51 old.mBackStackNesting += 1; 52 if (FragmentManagerImpl.DEBUG) { 53 Log.v(TAG, "Bump nesting of " 54 + old + " to " + old.mBackStackNesting); 55 } 56 } 57 mManager.removeFragment(old, mTransition, mTransitionStyle); 58 } 59 } 60 } 61 } 62 if (f != null) { 63 f.mNextAnim = op.enterAnim; 64 mManager.addFragment(f, false); 65 } 66 } 67 break; 68 case OP_REMOVE: { 69 Fragment f = op.fragment; 70 f.mNextAnim = op.exitAnim; 71 mManager.removeFragment(f, mTransition, mTransitionStyle); 72 } 73 break; 74 case OP_HIDE: { 75 Fragment f = op.fragment; 76 f.mNextAnim = op.exitAnim; 77 mManager.hideFragment(f, mTransition, mTransitionStyle); 78 } 79 break; 80 case OP_SHOW: { 81 Fragment f = op.fragment; 82 f.mNextAnim = op.enterAnim; 83 mManager.showFragment(f, mTransition, mTransitionStyle); 84 } 85 break; 86 case OP_DETACH: { 87 Fragment f = op.fragment; 88 f.mNextAnim = op.exitAnim; 89 mManager.detachFragment(f, mTransition, mTransitionStyle); 90 } 91 break; 92 case OP_ATTACH: { 93 Fragment f = op.fragment; 94 f.mNextAnim = op.enterAnim; 95 mManager.attachFragment(f, mTransition, mTransitionStyle); 96 } 97 break; 98 default: { 99 throw new IllegalArgumentException("Unknown cmd: " + op.cmd); 100 } 101 } 102 103 op = op.next; 104 } 105 //我們也很容易就能看出來 最終都是走的 mManager.moveToState 這個方法 106 //同時moveToState 也是fragment狀態分發最重要的方法了 107 108 mManager.moveToState(mManager.mCurState, mTransition, 109 mTransitionStyle, true); 110 111 if (mAddToBackStack) { 112 mManager.addBackStackState(this); 113 } 114 }

到這里應該就差不多了，最終的線索就是 只要搞明白moveToState這個函數就可以了。

1 //下面的代碼來自于fragmentmanager 2 //我們首先來看一下movetostate這個函數總共有一個 3 void moveToState(Fragment f) 4 void moveToState(int newState, boolean always) 5 void moveToState(int newState, int transit, int transitStyle, boolean always) 6 void moveToState(Fragment f, int newState, int transit, int transitionStyle, 7 boolean keepActive) 8 9 //可以看到movetoState總共4種。 10 //在詳細介紹movetostate函數之前，我們先去看看這個函數的參數之一new state是什么 11 12 //下面代碼來自于fragment 13 //其實new state 就是代表新的狀態，總共他的值有7種 就全在這里了 預先都是定義好的 14 static final int INVALID_STATE = -1; // Invalid state used as a null value. 15 static final int INITIALIZING = 0; // Not yet created. 16 static final int CREATED = 1; // Created. 17 static final int ACTIVITY_CREATED = 2; // The activity has finished its creation. 這個狀態其實很好理解， 18 //就是fragement在oncreate函數結束的時候會調用dispatchActivityCreated 就是通知fragment 跟你綁定的宿主activity已經走完onCreate了 19 static final int STOPPED = 3; // Fully created, not started. 20 static final int STARTED = 4; // Created and started, not resumed. 21 static final int RESUMED = 5; // Created started and resumed. 22 23 24 //下面我們可以模擬一個流程 幫助大家理解這個狀態到底是干嘛的 有什么用。 25 //比如 我們先看看 fragmentactivity的源碼， 26 //首先我們假設 我們想看看activity 發生onResumne事件的時候 對fragment有什么影響 27 protected void onResume() { 28 super.onResume(); 29 mHandler.sendEmptyMessage(MSG_RESUME_PENDING); 30 mResumed = true; 31 mFragments.execPendingActions(); 32 } 33 //繼續追蹤代碼 發現最后是調用的onResumeFragments 這個方法 34 final Handler mHandler = new Handler() { 35 @Override 36 public void handleMessage(Message msg) { 37 switch (msg.what) { 38 case MSG_REALLY_STOPPED: 39 if (mStopped) { 40 doReallyStop(false); 41 } 42 break; 43 case MSG_RESUME_PENDING: 44 onResumeFragments(); 45 mFragments.execPendingActions(); 46 break; 47 default: 48 super.handleMessage(msg); 49 } 50 } 51 52 }; 53 //原來當activity走onresume流程的時候 最終都是走到這里 54 55 protected void onResumeFragments() { 56 mFragments.dispatchResume(); 57 } 58 //前面已經分析過mFragements就是FragmentController的對象 59 //所以下面的代碼 來自于FragmentController 60 public void dispatchResume() { 61 //前面的源碼也分析過了mHost.mFragmentManager 就是 final FragmentManagerImpl mFragmentManager = new FragmentManagerImpl(); 62 mHost.mFragmentManager.dispatchResume(); 63 } 64 65 //下面的代碼來自fragmentmanager 66 //一直追蹤到這里就能明白 activity的聲明周期 與fragment聲明周期關聯的時候 就是通過moveToState 這個函數來完成的 67 public void dispatchResume() { 68 mStateSaved = false; 69 moveToState(Fragment.RESUMED, false); 70 } 71 72 //movetostate這個函數前面已經說過總共有4種 不一樣的聲明 但是最終起效果的只有這一個 73 //這個函數非常的長 我就簡單挑幾個注意的點進行注釋 代碼我就不全部復制粘貼進來了。太長了 74 //有興趣的同學可以自己跟進去看看 其實邏輯挺簡單的 75 void moveToState(Fragment f, int newState, int transit, int transitionStyle, 76 boolean keepActive) { 77 ...... 78 if (f.mState < newState) { 79 // For fragments that are created from a layout, when restoring from 80 // state we don't want to allow them to be created until they are 81 // being reloaded from the layout. 82 if (f.mFromLayout && !f.mInLayout) { 83 return; 84 } 85 if (f.mAnimatingAway != null) { 86 // The fragment is currently being animated... but! Now we 87 // want to move our state back up. Give up on waiting for the 88 // animation, move to whatever the final state should be once 89 // the animation is done, and then we can proceed from there. 90 f.mAnimatingAway = null; 91 moveToState(f, f.mStateAfterAnimating, 0, 0, true); 92 } 93 switch (f.mState) { 94 case Fragment.INITIALIZING: 95 ......................................... 96 } 97 } 98 f.mHost = mHost; 99 f.mParentFragment = mParent; 100 f.mFragmentManager = mParent != null 101 ? mParent.mChildFragmentManager : mHost.getFragmentManagerImpl(); 102 f.mCalled = false; 103 //這個地方相信很多人一看就明白了，這行代碼就說明了在onAttach的時候 就能使用和fragment關聯的activity了，這也是為什么 104 //fragment與activity通信時，我們喜歡定義接口來完成，并且在onAttach的時候綁定接口 的原因 105 f.onAttach(mHost.getContext()); 106 if (!f.mCalled) { 107 throw new SuperNotCalledException("Fragment " + f 108 + " did not call through to super.onAttach()"); 109 } 110 if (f.mParentFragment == null) { 111 mHost.onAttachFragment(f); 112 } 113 114 if (!f.mRetaining) { 115 f.performCreate(f.mSavedFragmentState); 116 } 117 f.mRetaining = false; 118 if (f.mFromLayout) { 119 // For fragments that are part of the content view 120 // layout, we need to instantiate the view immediately 121 // and the inflater will take care of adding it. 122 f.mView = f.performCreateView(f.getLayoutInflater( 123 f.mSavedFragmentState), null, f.mSavedFragmentState); 124 if (f.mView != null) { 125 f.mInnerView = f.mView; 126 if (Build.VERSION.SDK_INT >= 11) { 127 ViewCompat.setSaveFromParentEnabled(f.mView, false); 128 } else { 129 f.mView = NoSaveStateFrameLayout.wrap(f.mView); 130 } 131 if (f.mHidden) f.mView.setVisibility(View.GONE); 132 f.onViewCreated(f.mView, f.mSavedFragmentState); 133 } else { 134 f.mInnerView = null; 135 } 136 } 137 case Fragment.CREATED: 138 ...................... 139 }

一直分析到這里，相信大家就對fragment的源碼基礎知識有一個不錯的理解了，在這里 就簡單總結一下 上面的分析：

1.FragmentActivity 是具有支持fragment功能的最底層的activity。其他什么AppCompatActivity都是他的子類！

2.FragmentActivity主要負責就是生命周期的轉發，比如onCreate onResume onDestroy等等，這就是為什么activity和fragment狀態能統一的原因了！

當然了，分發的原因就是因為fragmentactivity源碼里面持有一個fragmentController的實例！

3.其實將白了，fragmentController就是因為他自己有一個fragmenthostcallback，然后這個hostback還持有了fragmentmanger 所以這個controller 能分發activity的事件！

4.fragementhostcallback持有了activity的很多資源，context handler 是最主要的2個。fragmentmanger就是因為拿到了activty的這2個資源，所以才能和activty互相通信的！

5.fragmentmangerimple就是fragmentmanger的具體實現類。movetostate方法就是在這個里面實現的?

6.FragmentTransition 也是個抽象類，他主要就是提供對外的接口函數的 add replace move 這種。BackStackRecord 就是它的具體實現類。還額外實現了runnable接口。

所以BackStackRecord 里面會有個run方法 這個run方法就是根據不同的操作(所謂操作就是OP.CMD的那個值) 來分發不同的事件，從而調用fragmentmanger的各種轉換fragment生命周期的方法！

?

最后在說一下 fragment的 緩存和恢復機制吧。

1 //保存fragment狀態的 主要是靠FragmentState 這個類來完成的 2 final class FragmentState implements Parcelable 3 //可以看一下這個類的構造函數 4 public FragmentState(Fragment frag) { 5 mClassName = frag.getClass().getName(); 6 mIndex = frag.mIndex; 7 mFromLayout = frag.mFromLayout; 8 mFragmentId = frag.mFragmentId; 9 mContainerId = frag.mContainerId; 10 mTag = frag.mTag; 11 mRetainInstance = frag.mRetainInstance; 12 mDetached = frag.mDetached; 13 mArguments = frag.mArguments; 14 } 15 16 //再看一下這個類： 這里保存了3個數組 并且這3個數組元素都實現了Parcelable 接口 17 //這意味著他們都可以被序列化 18 final class FragmentManagerState implements Parcelable { 19 FragmentState[] mActive; 20 int[] mAdded; 21 BackStackState[] mBackStack; 22 23 public FragmentManagerState() { 24 } 25 26 public FragmentManagerState(Parcel in) { 27 mActive = in.createTypedArray(FragmentState.CREATOR); 28 mAdded = in.createIntArray(); 29 mBackStack = in.createTypedArray(BackStackState.CREATOR); 30 } 31 32 public int describeContents() { 33 return 0; 34 } 35 36 public void writeToParcel(Parcel dest, int flags) { 37 dest.writeTypedArray(mActive, flags); 38 dest.writeIntArray(mAdded); 39 dest.writeTypedArray(mBackStack, flags); 40 } 41 42 public static final Parcelable.Creator<FragmentManagerState> CREATOR 43 = new Parcelable.Creator<FragmentManagerState>() { 44 public FragmentManagerState createFromParcel(Parcel in) { 45 return new FragmentManagerState(in); 46 } 47 48 public FragmentManagerState[] newArray(int size) { 49 return new FragmentManagerState[size]; 50 } 51 }; 52 } 53 54 //上面那個類的3個屬性 實際上對應保存著是fragemntmanager里的 三個成員 55 ArrayList<Fragment> mActive;//他還保存了mBackStack所有相關的fragment 所以mAdder是mActive的子集 56 ArrayList<Fragment> mAdded; 57 ArrayList<BackStackRecord> mBackStack;//這個就是保存調用了addToBackStack方法的FragementTransaction，你看就是這個東西記錄了 58 //你commit的操作 所以當你調用了addToBackStack 以后再按返回鍵 就可以回到上一個fragment了

然后我們看一下 當我們的activity onstop以后 會給fragment帶來什么？

1 //下面代碼來自于fragmentactivity 2 @Override 3 protected void onStop() { 4 super.onStop(); 5 6 mStopped = true; 7 mHandler.sendEmptyMessage(MSG_REALLY_STOPPED); 8 9 mFragments.dispatchStop(); 10 } 11 12 //來自于fragmentcontroller 13 public void dispatchStop() { 14 mHost.mFragmentManager.dispatchStop(); 15 } 16 17 //來自于fragemntmanager 18 public void dispatchStop() { 19 // See saveAllState() for the explanation of this. We do this for 20 // all platform versions, to keep our behavior more consistent between 21 // them. 22 mStateSaved = true; 23 //你看這里就是轉換了一下狀態 24 moveToState(Fragment.STOPPED, false); 25 } 26 27 //所以對應的你也能猜到了 當activity onresume的時候 這里也無非就是把fragement的狀態 從stopped 變成resumed了。 fragement是實例并沒有銷毀 還在 28 public void dispatchResume() { 29 mStateSaved = false; 30 moveToState(Fragment.RESUMED, false); 31 }

我們再考慮一下另外一個場景：

比如說 我們旋轉了屏幕。并且

setRetainInstance 為true的時候

看看fragment是怎么處理的（為false的情況 就是fragment和activity一樣了 activity怎么做fragment就怎么做 沒什么好講的必要。。）

?

1 //下面代碼來自于fragmentmanager 2 //如果Fragment設置了fragment.setRetainInstance(true) 最終ams 會一步步調用到這個函數的 3 //所以你看 這里就是返回了mActive 數組的拷貝呀！ 4 ArrayList<Fragment> retainNonConfig() { 5 ArrayList<Fragment> fragments = null; 6 if (mActive != null) { 7 for (int i=0; i<mActive.size(); i++) { 8 Fragment f = mActive.get(i); 9 if (f != null && f.mRetainInstance) { 10 if (fragments == null) { 11 fragments = new ArrayList<Fragment>(); 12 } 13 fragments.add(f); 14 f.mRetaining = true; 15 f.mTargetIndex = f.mTarget != null ? f.mTarget.mIndex : -1; 16 if (DEBUG) Log.v(TAG, "retainNonConfig: keeping retained " + f); 17 } 18 } 19 } 20 return fragments; 21 } 22 23 //上面說了保存fragment實例 下面肯定要說如何存儲fragemnt的實例的 24 //下面代碼來自于activity 25 26 NonConfigurationInstances retainNonConfigurationInstances() { 27 Object activity = onRetainNonConfigurationInstance(); 28 HashMap<String, Object> children = onRetainNonConfigurationChildInstances(); 29 List<Fragment> fragments = mFragments.retainNonConfig(); 30 ArrayMap<String, LoaderManager> loaders = mFragments.retainLoaderNonConfig(); 31 if (activity == null && children == null && fragments == null && loaders == null 32 && mVoiceInteractor == null) { 33 return null; 34 } 35 //這里nci你看就知道了 看下類的源碼你看他保存的東西 并沒有做什么序列化反序列化的操作， 36 //所以他可以保存任何東西！當然了，這個nci 是最終保存在activitythread對象里的， 37 //activitytheread對象里有個鍵值對叫mActivies。他有個數據結構叫activityclientrecord 38 //有興趣的人可以去看下activitytheread的源碼 這里不深入展開了。 39 NonConfigurationInstances nci = new NonConfigurationInstances(); 40 //注意 nci.activity這個地方 可不是activity，他是activity源碼中onRetainNonConfigurationInstance方法返回的對象咯，看63行就知道了 41 nci.activity = activity; 42 nci.children = children; 43 nci.fragments = fragments; 44 nci.loaders = loaders; 45 if (mVoiceInteractor != null) { 46 mVoiceInteractor.retainInstance(); 47 nci.voiceInteractor = mVoiceInteractor; 48 } 49 return nci; 50 }. 51 52 //所以看到這里就應該明白，如果你的setRetainInstance設置了true的話，當activity重新recreate的時候，雖然activity生成了一個全新的，fragmentmanger也是一個全新的， 53 //但是你的fragment實際上還是舊的，生命周期會有一些不同的，不會有oncreate和ondestroy了。他會走85行那里的restoreAllState方法了 54 static final class NonConfigurationInstances { 55 Object activity; 56 HashMap<String, Object> children; 57 List<Fragment> fragments; 58 ArrayMap<String, LoaderManager> loaders; 59 VoiceInteractor voiceInteractor; 60 } 61 62 63 //下面這個方法在fragemntactitivy源碼里 64 public final Object onRetainNonConfigurationInstance() { 65 if (mStopped) { 66 doReallyStop(true); 67 } 68 69 Object custom = onRetainCustomNonConfigurationInstance(); 70 71 List<Fragment> fragments = mFragments.retainNonConfig(); 72 SimpleArrayMap<String, LoaderManager> loaders = mFragments.retainLoaderNonConfig(); 73 74 if (fragments == null && loaders == null && custom == null) { 75 return null; 76 } 77 78 NonConfigurationInstances nci = new NonConfigurationInstances(); 79 nci.custom = custom; 80 nci.fragments = fragments; 81 nci.loaders = loaders; 82 return nci; 83 } 84 85 //以下代碼來自于fragmentmanger restoreAllState這個方法就是恢復保存的fragment實例的 86 void restoreAllState(Parcelable state, List<Fragment> nonConfig) { 87 // If there is no saved state at all, then there can not be 88 // any nonConfig fragments either, so that is that. 89 if (state == null) return; 90 FragmentManagerState fms = (FragmentManagerState)state; 91 if (fms.mActive == null) return; 92 93 // First re-attach any non-config instances we are retaining back 94 // to their saved state, so we don't try to instantiate them again. 95 if (nonConfig != null) { 96 for (int i=0; i<nonConfig.size(); i++) { 97 Fragment f = nonConfig.get(i); 98 if (DEBUG) Log.v(TAG, "restoreAllState: re-attaching retained " + f); 99 FragmentState fs = fms.mActive[f.mIndex]; 100 fs.mInstance = f; 101 f.mSavedViewState = null; 102 f.mBackStackNesting = 0; 103 f.mInLayout = false; 104 f.mAdded = false; 105 f.mTarget = null; 106 if (fs.mSavedFragmentState != null) { 107 fs.mSavedFragmentState.setClassLoader(mHost.getContext().getClassLoader()); 108 f.mSavedViewState = fs.mSavedFragmentState.getSparseParcelableArray( 109 FragmentManagerImpl.VIEW_STATE_TAG); 110 f.mSavedFragmentState = fs.mSavedFragmentState; 111 } 112 } 113 } 114 115 ................................. 116 }

最后再考慮一種場景，假設我們的宿主activity 在后臺掛起的時候，因為內存不足 被系統殺掉了。fragment會發生什么？

其實也很簡單啊，源碼就不貼了，大家自己看，我說下簡單的流程：

1.首先要明確 activity的onSaveInstanceState的方法，是在onPause以后 onStop以前調用的。

2.activty放到后臺的時候會調用onstop方法，但是onSaveInstanceState是在這之前被調用的

3.所以實際上FragmentManager保存的那3個數組mActive、mAdded、mBackStack都被提前保存到FragmentManagerState里面了

4.等到activity重新回到前臺 走oncreate的時候，會獲得savedInstanceState這個實例，通過他去創建新的FragmentManager實例和新的fragment對象。

5.此時不管fragment是否setRetainInstance(true)，Fragment實例都會重新被創建，原因如下：

retainNonConfig是在Activity在onDestroy被保存的，有人會說，你上面被系統回收了不是也要最終走ondestroy嗎，但是要注意的是：

只有被relaunch的activity在destroy時才會在ActivityThread代碼中被調用retainNonConfig去通知Activity返回需要保存實例，其他的destroy不會。

所謂relaunch是指 比如我們手動調用了activity的recreate方法，或者更改了系統語言 屏幕方向等造成的activity重新創建。而系統資源不足回收造成的activity重新創建

是不屬于relaunch這一行為的。

原文地址：https://developer.android.com/guide/components/fragments.html

總結

以上是生活随笔為你收集整理的Android fragment源码全解析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。