关于保存和恢复 View 层次结构，系统的工作流程是这样的

首先 Activity 被意外终止时， Activity 会调用 onSaveInstanceState 去保存数据，然后
Activity 会委托 Window 去保存数据，接着 Window 在委托它上面的顶级容器去保存数
据。顶级容器是一个 ViewGroup，一般来说它很可能是 DecorView。最后顶层容器再去
一一通知它的子元素来保存数据，这样整个数据保存过程就完成了。可以发现，这是一个
典型的委托思想，上层委托下层，父容器去委托子元素去处理一件事情，这种思想在
Android 中有很多应用，比如： View 的绘制过程，事件分发等都是采用类似的思想。至
于数据恢复过程也是类似的，这样就不再重复介绍了。
情况 2：资源内存不足导致低优先级的 Activity 被杀死。
首先， Activity 有优先级？你肯定怀疑，代码中都没设置过啊！优先级从何而来，其实这
里的 Activity 的优先级是指一个 Activity 对于用户的重要程度，比如：正在与用户进行交
互的 Activity 那肯定是最重要的。我们可以按照重要程度将 Activity 分为以下等级：
优先级最高： 与用户正在进行交互的 Activity，即前台 Activity。
优先级中等：可见但非前台的 Activity,比如：一个弹出对话框的 Activity,可见但是非前台
运行。
优先级最低：完全存在与后台的 Activity,比如：执行了 onStop。
当内存严重不足时，系统就会按照上述优先级去 kill 掉目前 Activity 所在的进程，并在后
续通过 onSaveInstanceState 和 onRestoreInstanceState 来存储和恢复数据。如果一个
进程中没有四大组件的执行，那么这个进程将很快被系统杀死，因此，一些后台工作不适
合脱离四大组件独立运行在后台中，这样进程更容易被杀死。比较好的方法就是将后台工
作放入 Service 中从而保证进程有一定的优先级，这样就不会轻易地被系统杀死。
总结：
上面分析了系统的数据存储和恢复机制，我们知道，当系统配置发生改变之后， Activity
会被重新创建，那么有没有办法不重新创建呢？答案是有的，接下来我们就来分析这个问
题。系统配置中有很多内容，如果某项内容发生了该变后，我们不想系统重新创建
Activity 可以给 Activity 指定 configChanges 属性。比如我们不想让 Actiivty 在屏幕旋转
的时候重新创建，就可以给 configChanges 属性添加一些值，请继续往下看