写在前面 ： 关于Room 我放在下一篇写 按照官方推荐路线学习 可能会容易点~
简介：
无论我们是不是注重UI ，UI一直是用户体验最关键的部分 对于用户来讲 无论是横竖屏切换 还是重启 或者 系统强制停止运行 当界面回复的时候 用户都希望之前的操作状态能够被保留
我们通常的做法是通过onSaveInstanceState(也不知道是不是拼对了) 来实现 简单数据的恢复，通过前面几篇文章的学习 我们还可以通过ViewModel 恢复数据 有人说我们还可以用持久化存储 ok 你说的都对 那么我们来简单了解下 这些做法的意义
简单数据管理 --onSaveInstanceState（）
onSaveInstanceState（）回调的摸底只是为了存储少量数据 当短暂停止而后重新运行时，能够及时重新加载UI控制器（activity或者Fragment ）的状态 具体情况如下：
1.当应用退到后台 此时由于内存限制 系统会杀死当前进程
2. 当系统配置出现 比如语言 屏幕切换等
再这两种情况下 我们activity虽然destory 但是并没有完成时 onSaveInstanceState将会被调用
再比如 当用户用过只够 再之后的几个小时没有使用该app 那么系统会调用onSaveInstanceState的默认实现 去（通过对应ID）保存每一个UI管理器状态 然后系统会自动从当前内存中释放相关进程 当用户重新使用App的时候 根据之前保存的 再恢复UI状态
PS ： 这种恢复只限于我们没有主动调用finish 的时候
关于onSaveInstanceState 的默认实现 已经帮助我们完成了大量UI的恢复 我们也可以自己再重写 在里面保存一些数据 但是不要忘记调用super.onSaveInstanceState（） 除非你自己完成了大量UI的重建
上面我们说了半天 其实只说了onSaveInstanceState能够帮助我们恢复大量UI 和我们可以保存少量数据 为什么是少量数据呢 比如bitmap这样的数据为什么不可以呢 ？ 因为onSaveInstanceState的存储恢复 都是在主线程上完成的 如果大量数据存储h 恢复，那么需要很长时间完成序列化和反序列化 那样我们肯定知道 会造成啥情况 ---ANR
那我们接下来看下
复杂数据的管理--分而治之
当我们activity finish的时候 如果我们有复杂的数据结构去存储，我们能通过几种不同类型的存储机制划分存储工作 完成UI状态的保存和恢复
常见情景 ：
1.用户从最近使用列表中移除当前app 当再启动的时候 用户想要能够从新开始
2.用户直接back 到后台 再打开的时候 用户希望能够保留之前的状态
这些都是比较常见的情况 为了在任何情况下 都能完成复杂数据的存储我们使用 那么下面我们来介绍两种常见的数据保存方式
1.本地持久化存储 ：保存在本地。保存不希望丢失的数据 比如说 歌曲 文件 等等
2.ViewModel：保存在内存中 用来存储内存中的数据 以及相关UI的数据 比如最新的搜索记录 和搜索结果
根据不同的需要选择不通的存储方式 这就是分而治之的思想 其实不说大家也能知道 但是这就是我根据官方文档一点点看的 总结下来
恢复复杂状态：重新组装
关于这个就很简单了
1.关于back到后台 再回到前台的项目 我们只需要使用onSaveInstanceState
2.关于旋转 切换语言等 配置改变 我们需要使用onSaveInstanceState 和ViewMidel共同完成
ok ~ 说了一篇废话 我们继续聊Room~