在安卓开发中，由于旋转设备会造成配置改变进而导致Activity实例被摧毁（当然也包括Activity托管的Fragment）。Activity或Fragment实例被摧毁自然也就让Model被摧毁，数据也就没有了。这是我们不想看到的。因此有了重写Activity或者Fragment的onSavedInstanceState(Bundle)方法来保存Model。
通过上述的这种方法的确可以解决一部分数据被摧毁的问题，但是有些数据我们需要一直保持，而非摧毁->重建。比如听音乐听得好好的，我旋转设备，程序员通过onSavedInstanceState(Bundle)方法把音乐保存了，然后onCreate(Bundle)再来将刚刚摧毁的音乐放出来，这可以么?当然不行，你说你吃着火锅唱着歌，就旋转个屏幕，音乐突然就没了，然后嘿又好了，你不骂这个app开发者傻逼我都看不下去！因此有了一个新需求，在设备旋转等配置改变的情况下我们要让model一直在，而不是摧毁->重建。这个想想好像无从下手，其实不难。我们可以跳出保存Model的思路，而是直接让存放Model的Fragment就不会死，那不就行了。
讲完了为何，再来说如何保存Fragment实例。
我们只需要重写Fragment.onCreate()方法,加上setRetainInstance(true)就行了
知其然须知其所以然，我们应该对系统是如何保存了fragment实例的工作原理也要了解。
如果不写setRetainInstance(true)这句话会发生什么呢?
如上图所示，由于旋转完屏幕，设置被改变，FragmentManager会首先销毁队列中fragment的视图，为什么要销毁它们的原因也很简单，新的配置可能对应新的资源，当有更适合的新资源匹配时，需要更换成新视图。然后FragmentManager会依次检查fragment实例的retainInstance值，如果为false立即销毁fragment实例。然后众所周知，会有一个新的Activity创建一个新的FragmentManager来创建新的Fragment实例及其视图。
但是如果fragment实例的retainInstance值为true，就不会被销毁。当新的Activity创建新的FragmentManager时，会找到这个被保存的fragment实例，并重新创建它的视图。
这个"不会死"的fragment，在activity被摧毁时处于被保留状态，此时没有任何activity托管它(因为托管它的activity被摧毁了)。
再来看看fragment的生命周期，加深理解。
从上面大段的讲述，我们可以总结出fragment需要有如下两个条件才能进入被托管状态。
1.它的retainInstance值为true
2.托管它的activity正在被摧毁
等到activity重建，fragment被纳入麾下，被保留状态也就结束了。
再来比较一下onSaveInstance方法和保留fragment实例方法
先看图:
由图可得出，在进程关闭时(通常可能发生在用户暂时离开当前应用以及系统需要回收内存从而销毁了activity以及被保留的fragment实例时)，fragment依然会被摧毁。
因此在需要将数据保存时间和activity记录一样长时，并且无需连贯保持(至少表面看不出来是断掉的)的情况时，最好采用onSaveInstance方法。
太阳照常升起，人生寂寞如雪。