1. FragmentState implements Parcelable, 这个就没啥多说的了，就是就一个Fragment 信息的holder,在 onSave/RestoreInstance时使用(不过可以了解一下整个Fragment体系的state的save/restore流程).
2. 再重申一下Fragment的6个状态(Fragment其实完全就是一个状态机):

• INITIALIZING = 0; (构造出来时的默认初始状态)
• CREATED = 1;
• ACTIVITY_CREATED = 2;
• STOPPED = 3;
• STARTED = 4;
• RESUMED = 5;

3. 捋一遍内部成员变量:其实有很多在上一篇分析FragmentManager的时候已经清楚了:

• mAnimatingAway:注释说的很清楚了,我们要移除Fragment的View，但是呢，这个移除过程有动画,那么显然不能直接就把View释放，这时候就会用这个mAnimatingAway保存View，在动画完了以后，会通过此引用来处置View.
• mStateAfterAnimating: 跟mAnimatingAway绑定的，看FragmentManager的moveToState时就可以看到，在moveToState时，如果有动画或者正在动画，那么其实State是不会move的,而是会把要move的下一个state保存在这个变量中，在动画完了以后会根据这个state来真正的moveToState.
• mSavedFragmentState: instantiated from saved state，使用此state.
• SparseArray mSavedViewState: 一个Fragment的View里一般会有别的childView，那么显然这些View也是需要save/restore state的，这个Parcelable数组就是一个holder.
• mIndex = -1: fragment在FragmentManager中的mActive中的index
• mWho: Internal unique name for this fragment
• Bundle mArguments: 构造时传入的参数，setArguments(…)
• mTarget, target fragment,这个主要用于fragment之间的交互, setTargetFragment(…)的注释: This may be used, for example, if this fragment is being started by another, and when done wants to give a result back to the first. mTargetIndex/mTargetRequestCode配套使用
• mAdded: 是否在FragmentManager的mAdded
• mRemoving:是否正在被从Activity removing
• mResumed:是否在resumed 状态.
• mFromLayout,该Fragment是否是从layout文件中实例化的.
• mInLayout: 感觉和mFromLayout一样?
• mRestored:是否已经从之前save的state中restore了.
• mBackStackNesting;该fragment所在的backStack的backStackEntry的数量.
• mFragmentManager/mActivity/mChildFragmentManager不解释了
• mFragmentId:一个可选的id.
• mContainerId: fragment的View的containerVie的Id.
• mTag:可选的tag. 跟View的tag角色差不多
• mHidden, 在app 请求将这个fragment从用户那里隐藏时是true(注释的语义不是很清晰)
• mDetached: fragment 是否 deactivated.
• mRetainInstance: 在configuration的change时，是否会被retain(冷门的一个选项).
• mHasMenu: 主要是用于fragment切换对ActionMenu的动态改变.
• mCalled: Used to verify that subclasses call through to super class. 多层类结构上的一个Flag.
• mNextAnim,指的就是app自定的Animation,但是从FragmentManager的loadAnimation(…)逻辑看，如果调用者自己在onCreateAnimation(…)返回了别的Animation, mNextAnim就没用了.
• mContainer:从注释(The parent container of the fragment after dynamically added to UI.)看，感觉就是containerView,不过这里是一个ViewGroup引用.
• mView：就是fragment 放在container的view.
• mInnerView:这个和mView的区别在FragmentManager里说过，mView有时候其实是在Fragment create的View外边wrap了一层view，这个View会变为mView,而被包住的View则变为mInnerView
• mDeferStart:标注该fragment是不是应该defer自己的start直到其他的fragment已经start并且loader也就绪了,个人感觉没准可以作为一个delay init的优化手段使用.
• mUserVisibleHint: Hint provided by the app that this fragment is currently visible to the user.
• mLoaderManager/mLoadersStarted/mCheckedForLoaderManager:这几个是为了支持在fragment使用android的loader机制.

4. Fragment():空的Fragment构造函数，很重要,因为需要这个无参的构造函数来在从activity的savedstate中restore构造出fragment实例.并且注释也建议Fragment的子类不要自己做死增加其他的需要参数的构造函数,因为这些构造函数在fragmentre-instantiated是不会被调到的，会悲剧,，建议使用setArguments()/getArguments()来实现同样效果.
5. static Fragment instantiate(Context context, String fname, Bundle args): 用反射的办法构造一个fname(类名)指定的Fragment类,后面的args会在构造完以后设置给fragment实例的mArguments，注意这里反射时调用的是Class的newInstance(),也就是说这货调的也是Fragment类的无参构造函数,便利性工具函数.
6. setIndex(int index, Fragment parent):指定mIndex, 另外顺带把mWho赋值,注意这里的Fragment parent,一个Fragment是可以做另外一个fragment的parent的,如果有parent: mWho = parent.mWho + “:” + mIndex;，否则:mWho = “android:fragment:” + mIndex;.
7. isInBackStack():看一下的当前所在的backStack的entryNum(mBackStackNesting)是不是>0,当前了如果就不在backstack,那么mBackStackNesting应该就是默认的0.
8. getId()->mFragmentId/getTag()->tag
9. setArguments(Bundle args)：一个注意点,如果mIdex已经>=0了，那么就不能set了，会抛异常 注释有说: This can only be called before the fragment has been attached to its activity, 所以应该在构造完fragment以后就立刻set,mArguments的生命周期会贯穿fragment的创建和销毁.
10. getResources(): 便利性封装函数，取得还是所在的Activity的getResources(),如果还没有attach到某个Activity,会抛异常.
11. getText(int resId)/getString(int resId)/…..，和上面一样的便利封装.
12. getFragmentManager():注意在fragment被加入到fragmentTransaction直到被commit和attach到Activity这个期间，有可能是null,fragmentManager的code也可以看出来,是在FragmentManager的moveToState的case Fragment.INITIALIZING下才会设置fragmengt的mFragmentManager.
13. isAdded() -> mActivity != null && mAdded
14. isDetached()->mDetached, FragmentTransaction的detach会导致这个状态.
15. isRemoving(): 跟所在的Actiivty是不是finishing无关，就是指的是fragment现在正在被removing
16. isVisible(): This means it:

• (1) has been added
• (2) has its view attached to the window
• (3) is not hidden.

17. setRetainInstance(boolean retain):注释里解释了，这个fragment的实例使命周期是否可以脱离其所在Activity的销毁和重建的生命周期. 注意在backStack中的fragment不能设置这个flag,设了之后:

• onDestory()不会被调用，但是onDetach还是会被调用.
• onCreate()不会再被调用.
• onAttach(Activity)/onActivityCreated(Bundle)还会被调用.s

18. getLoaderManager():逻辑:

• 如果mLoaderManager本身不是null, return.
• 否则尝试从Activity去取(使用了mWho),mActivity.getLoaderManager(mWho, true, true); mCheckedForLoaderManager也会设为true.

19. startActivity(…)/startActivityForResult(…)/…便利性封装.
20. onActivityResult(…):相对的回调,Activity那里应该做了下发.
21. getLayoutInflater(…):便理性封装.
22. onInflate(…):针对的是在layout文件中声明的fragemnt，注释值得好好看看.
23. onCreate(Bundle savedInstanceState): 在onAttach和onCreateView之后，注意，这个回调的时候，fragment所在的Activity可能还在create中，因此这时候不能假设Activity的content view已经初始化构建完成， onActivityCreated(…)就是为此存在的.
24. void onViewCreated(View view, Bundle savedInstanceState): 注释说在onCreateView之后立即被调用，但是如同之前分析FragmentManager时,两个回调中间还是有间隔的，比如wrap,这给子类提供了一个机会在自己的View已经被create的时候,不过fragment的view这时候还没有被attach到parent上
25. onActivityCreated(Bundle savedInstanceState): 在fragment所在的Activity已经create并且fragemnt的View 结构也已经被初始化了,这个callback告知了fragment已经与Activity对象充分关联了,在onCreateView之后和onViewStateRestored之前调用.
26. onViewStateRestored(Bundle savedInstanceState)，在fragment中的View已经restore state时会被调用.这一步之后才能检测View的一些自己的会被save/restore的state.比如是否checked,这个flag只有在这个时候以后后面才是有效的
27. onStart():fragemnt对user可见时被调用，一般是直接绑定在Activity的onStart()上的. 这一步还会把fragment的LoadManager start(可见在pasue状态下，loadManager是不work的)
28. onSaveInstanceState(Bundle outState): 在被系统回收时，用来保存fragment自己的state信息,以再后面restore重建,和Activity的差不多.
29. onDestroyView():说了一个关键信息:在fragment的view被detachfrom fragment的时候会被调用，下次fragment再展示，就会new一个新的View,在onStop和onDestroy之间,在对FragmentManager的分析中，可以看到，在fragment moveToState的state是早于 Fragment.ACTIVITY_CREATED时，会调用performDestroyView()->onDestroyView()
30. Fragment的所有onXXX函数本身是作为回调的,因此里面不会有多少操作，而performXXX会执行操作，并调用onXXX, performXXX其实做的主要操作是对ChildFragment的动作下发(如果有childFragment的话)
31. performDestroy(): 如果本身自己还有childFragment,那么会调用mChildFragmentManager.dispatchDestroy()将destroy传递下去.
32. registerForContextMenu/unregisterForContextMenu: 为某个View注册一个ContextMenu create的Listener.
33. onContextItemSelected:在context menu的某一个item被选中时的回调.
34. performCreate(Bundle savedInstanceState)，除了调用自己的onCreate(会传入savedInstanceState)以外,主要是将savedInstanceState分发给childFragment(如果有的话).
35. performStart():除了onStart回调和childFragment动作下发外，还会调用mLoaderManager.doReportStart(),而mLoaderManager的start则是在onStart被调用
36. performReallyStop():与performStop()的不同在于对loader的处理,在获取了LoaderManager以后,如果Activity不是Retaining的，那么mLoaderManager.doStop()否则mLoaderManager.doRetain().
37. performDestroyView():mLoaderManager会doReportNextStart()
38. 上面这些分析给我的感觉就是Fragment本身在Fragment这个体系中其实是一个轻量化的角色(当然了，一系列callback会将其填充)，系统本身的Fragment实现一个作用是建立了Fragment这个概念，使其可以被Manage以及save/restore，同时负责了loaderManager的交互与维护以及对所依附的Activity一些操作封装.