你真的了解Fragment的生命周期吗？
Android Framwork开发人员中的传奇人物Dianne Hackborn在2010年将Fragment引入了Android，也就是在android3.0之后引入Fragment，他在提交信息中写道：
“将单一的Activity拆分成多个独立的部件”的想法非常好。 然而，从今天Fragment的的实际使用效果来看，这一API的实现和演变并不理想。
虽然在项目中我们经常使用Fragment，但Fragment也有局限性和缺点，让我们来看下面这个流程图：
幸运的是，您在应用中使用Fragment的时候无需了解整个生命周期的转换过程，本文将介绍一些处理Fragment生命周期的方法，它隐藏了大部分的复杂细节。
Make Take On Fragment Lifecycle
处理Fragment生命周期的方法旨在实现两个目标：
1、使Fragment的生命周期处理逻辑尽可能类似于Activity的处理逻辑。
2、使Fragment的生命周期处理逻辑独立于Activity的生命周期。
使用类似于处理Activity的生命周期的方法来处理Fragment的生命周期，能大幅降低应用程序的整体复杂性；这意味着开发过程中的工作量会减少，维护会更容易，新团队成员熟悉项目的速度会更快，某种程度上，还可以减少bug产生的风险。
OnCreat(Bundle)
当Activity被强制销毁，之后又被自动恢复的时候，Android系统会在这一过程中销毁并重新创建Fragment。 重新创建的机制是通过使用反射的方法来调用Fragment的无参构造函数来实现的。 因此，如果您是使用带参数的构造函数来实例化Fragment，并在其中将依赖的对象传递给它，那么在保存和恢复后，所有这些依赖的对象都将被设置为null。
就像Activity一样，需要使用onCreate（Bundle）方法作为构造函数的替代者。 Fragment中依赖对象的注入和初始化就发生在这里；
与Activity的onCreate（Bundle）方法不同的是， 不得在Fragment的onCreate（Bundle）方法中执行任何与Android View相关的操作， onCreate（Bundle）方法在Fragment被Attach到Activity后仅被调用一次，它无法支持Fragment的View hierarchy的动态化；
将Activity转换为listener也发生在onCreate（Bundle）中，这将比在onAttach（Context）中抛出一个通用的ClassCastException要有意义的多；
View onCreatView(LayoutInflater，ViewGroup，Bundle)
这个方法是Fragment独有的，这是它与Activity生命周期最显着的区别。
Activity在生命周期的转换过程中都只有同一个View hierarchy。 你在Activity的onCreate（Bundle）中初始化这个View hierarchy，然后它就会一直存在于Activity的整个生命周期，直到Activity被垃圾收集器回收为止；
然而，在Fragment在其生命周期中可以存在有多个View hierarchy，由Android系统决定何时进行替换；
每次需要创建新的View hierarchy的时候，Android系统都会调用onCreateView(LayoutInflater, ViewGroup, Bundle)方法；
重写这个方法的主要原则是：Fragment中所有持有与View hierarchy相关的对象的引用的成员变量，必须在View onCreateView（LayoutInflater，ViewGroup，Bundle）中进行初始化，如果Fragment的成员变量持有View或者相关对象的引用，须确保在此方法中初始化这些成员变量；
方法的基本的处理逻辑如下：
Fragment里每个与View hierarchy相关的成员变量都必须在此方法中初始化， 这包括列表适配器，用户交互事件的监听器等。保持Fragment里的代码可维护性的唯一方法是确保此方法在重新创建整个View hierarchy的时候会重新初始化Fragment里与之相关的成员变量，这也是为了减小内存泄漏的风险。
onStart()
Fragment的这个方法与Activity的onStart（）方法具有完全相同的职责和指导原则，方法的基本的处理逻辑如下：
@Override
public void onStart() {
super.onStart();
mSomeView.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
handleOnSomeViewClick();
}
});
mFirstDependency.registerListener(this);
switch (mSecondDependency.getState()) {
case SecondDependency.State.STATE_1:
updateUiAccordingToState1();
break;
case SecondDependency.State.STATE_2:
updateUiAccordingToState2();
break;
case SecondDependency.State.STATE_3:
updateUiAccordingToState3();
break;
}
if (mWelcomeDialogHasAlreadyBeenShown) {
mFirstDependency.intiateAsyncFunctionalFlowAndNotify();
} else {
showWelcomeDialog();
mWelcomeDialogHasAlreadyBeenShown = true;
}
}
这个方法里包含了Fragment的大部分功能逻辑。 保持onStart（）方法在Activity和Fragment里的一致性具有很多好处。
onResume()
这个方法的处理逻辑与Activity的onResume（）方法相同。
onPause()
这个方法的处理逻辑与Activity的onResume（）方法相同。
onStop()
这个方法的处理逻辑同样与Activity的onStop（）方法相同，在此方法中，我们可以注销点击事件的监听器，不是必须的，但是也可以减少bug的风险。
onDestroyView()
之前说必须在onCreateView（LayoutInflater，ViewGroup，Bundle）里初始化Fragment里所有持有View或者相关对象的引用的成员变量。这个要求源自于这样一个事实：Fragment的View hierarchy可以被重新创建，所以所有未在该方法中被初始化的持有View的引用对象都将被置为null；
如果这样做了，Fragment将一直持有对这些View的强引用，直到下一次调用View onCreateView（LayoutInflater，ViewGroup，Bundle）方法或者整个Fragment被销毁；
有很多建议是应该在onDestroyView（）方法里将所有前面提到的成员变量设置为Null。 目的是尽快释放这些引用以允许垃圾收集器在onDestroyView（）返回后立即回收它们，这样就能更快地释放与这些View相关的内存空间，但这是过早优化的经典案例，在绝大多数情况下，你并不需要这种优化，所有，我们不需要重写onDestroyView（）方法。
onDestroy()
像Activity一样，您不需要在Fragment中重写此方法。
onSaveInstanceState(Bundle)
这个方法的基本的处理逻辑如下:
这个方法对应于Activity的onSaveInstanceState（Bundle）方法，所以对Activity的onSaveInstanceState（Bundle）的大多数讨论也适用于此。但请注意：此方法可能在onDestroy（）之前的任何时候被调用；在许多情况下，Fragment可能会被销毁。
根据官方文件：这个方法可能在onDestroy（）之前的任何时候调用。 这里有两个主要问题：
1、与Fragment相关联的View hierarchy可以被销毁而不实际保存其状态。 因此，如果您想在View onCreateView（LayoutInflater，ViewGroup，Bundle）中恢复Fragment的状态，这会加大程序崩溃的几率；
2、如果在onDestroy（）之前的任何时候都可以调用onSaveInstanceState（Bundle），那么就无法保证何时才能安全地更改Fragment的状态（例如替换嵌套的Fragment）。
setRetainInstance(boolean)
Fragment具有属性retainInstance，默认值为false。
当设备旋转时，fragment会随托管activity一起销毁并重建。
调用setRetainInstance(true)方法可保留fragment，代码如下：
已保留的fragment不会随着activity一起被销毁；
相反，它会一直保留(进程不消亡的前提下)，并在需要时原封不动地传递给新的Activity。
但是此方法建议不使用，因为此方法改变了Fragment的生命周期。
为什么Fragment如此复杂？
也许引入这种机制是为了优化内存的消耗。当Fragment不可见的时候，销毁Fragment的View hierarchy允许释放一些内存。 但另一个问题是：Fragment实现了对状态保存和恢复流程的支持；
在FragmentStatePagerAdapter并不是采用这种机制去保存和恢复Fragments的状态。
借用原作者的话：整个机制可能是一种过早的优化，它没有任何用处，反而会使得Fragment使用更复杂。
结语
虽然Fragment，整个机制复杂，但是与“一个界面一个Activity”的方法相比，Fragment可以提供更好的用户体验；
但是我们在使用Fragment的时候，建议在处理Fragment的生命周期时让它类似于Activity的生命周期并且独立于它，这使得Fragment的复杂性是可以管理的。
小伙伴们，你的支持是我前进的动力，动动手指，扫面二维码关注我们吧，如果您有任何补充或者想要指出本文中的任何缺陷，请给小编留言哦。
