Activity--onSaveInstanceState正确的打开方式

背景

之所以会写这篇文章，是因为之前偶然看见csdn的博客专家写到这个问题，给出的结论实在让人大跌眼镜。于是看了下源码，索性做个记录。

在Android 7.0以前，谷歌一直约束着让它以单窗口的姿态与广大用户见面（当然，除了个别不听话的厂商，早已实现了多窗口）。从开发者的角度来看，Activity（Fragment）通常是我们与用户交互的载体，也就是象征意义的“窗口”。通常我们的应用一般会有多个Activity（Fragment），但是最多只能有一个处在用户可见的状态。在低内存的移动终端上，系统有可能会私自杀死你的Activity来为正在运行的应用提供更多的内存支持。当然按照现代手机的配置，这是个低概率事件。可一旦发生，Android就必须具有恢复现场的能力。这就是onSaveInstanceState的作用场景。

调用时机

onSaveInstanceState是Activity中的一个非生命周期方法。说它非生命周期，却又和生命周期息息相关。如果排算起来，api中的说明是，如果onSaveInstanceState被调用，那它一定调用在onStop之前，但与onPasue的先后顺序不确定。测试的过程中发现它的调用基本是发生在onPause之后的。换句话说，如果onSaveInstanceState被调用，那它们三个的顺序一般是：onPause -> onSaveInstanceState -> onStop，除此之外，三者的调用基本没什么必然的连带关系。

如果从使用场景来看，按照api的意思，它的调用发生在在activity有可能被销毁的时候。这个说法很模糊，具体一点，一般有这几种情况：
（1）锁屏；
（2）横竖屏切换（整个Activity被销毁重建，必须调用）；
（3）从Activity A切换到B，A的onSaveInstanceState会调用（很简单，A即将不可见，有可能会被销毁）；
（4）按home键、长按home键（其实是3的一种）；

如何用

onSaveInstanceState里面默认地通过View的onSaveInstanceState方法，为我们保存了大部分UI状态。所以复写的时候，一定要调用父类的实现。否则，你就要手动保存每一个view的状态了。。需要我们附加保存的，一般都是一些跟用户状态有关的数据，比如变量的值等。

至于如何保存，无非是通过onSaveInstanceState（Bundle arg）的bundle参数，key-value存储，非常方便。通过这种方式存入的Bundle数据，会透传到onCreate（Bundle arg）或者onRestoreInstanceState（Bundle arg），所以可以在这两个地方取出使用，当然一定要做非空判断。

此外，开发的过程中，发现Activity中通过getIntent（）和Fragment中通过getArguments（）获得的数据系统也会自动帮我们保存。

当然，onSaveInstanceState能做的事情，我们通过生命周期和本地存储的方法也能办到，这当然就要看个人的意愿了。