关于在权威里面一直强调的设备旋转与对象保存

《Android探险》

在Java世界中要保存对象，要么放进Bundle中，要么实现Serializable,Parcelable接口。

1.首先明确什么是可保存对象

其实也应该很简单的理解，就是没有办法进行记录的对象。或者说没有办法记录的东西根本就没有办法生成对象。比如音乐播放暂停。倘若没有一个记录来记载上一次播放停止的位置，下一次播放就找不到位置了。从这里得到启发就是我们要想办法将不可保存对象转变成可保存对象。

2.保留fragment

知道设备旋转的时候系统会销毁Activity进行重建。整个过程就是ActivityManager销毁Activity,FragmentManager销毁该Activty托管的Fragment。当然说好的视图分离。。。就是说销毁Fragment还要大致分两个动作，销毁Fragment视图和Fragment实例。。至于先后，。我也不清楚。

就在这时，一个方法横空出世，

//这是Fragment中的方法
saveRetainInstance(boolean)
默认为false.表示默认不保留fragment实例
要选择保留fragment实例的话，就手动调用setRetainInstance(true);

也就是说在旋转的时候，我允许你销毁该Fragment被托管的Activity,销毁我的Fragment的视图，。，但是我Fragment的实例，你不能动，这个实例不被销毁，那么实例当时的各种状态属性就被保留了下来。因此你重建Activity和Fragment视图后，直接把该Fragment的实例套上去。。。over

为什么要有保留Fragment的选择？因为有些对象实在是没办法进行记录，比如asset音频资源，只有个播放方法，。没办法对播放的过程进行监控。话又说回来，本来SoundPool就是用于短，快的播放，监听过程似乎没有任何意义。但是偏偏又情况是你在播放的时候要旋转一下手机。要是直接把我的Fragment销毁了，我的SoundPool也会被释放。还没播放结束就被提前结束了

3.onSaveInstanceState(Bundle)

既然fragment可以被保留，但是为什么我们还要使用保存对象的方式？

因为保留fragment貌似只能在旋转或者设备配置改变的情况下使用。要是用户离开该应用，该Activity进入停止状态时。操作系统为了回收内存，卡擦。把该Activity解决了，这种情况下保留fragment的操作是不会执行的。

所以为了应对activity不小心被回收的情况，这个方法依旧适用。

也就是说，就算托管的Activity被系统回收了，bundle中的数据还是依然能够保存。