这是一个创建于 1991 天前的主题，其中的信息可能已经有所发展或是发生改变。
文章目录一览
- 前言
- 因为心里没底，而不敢用的状态恢复
- 什么是重建？引发重建的场景有哪些？
- 为何要设计出重建的机制？有何好处？
- 状态保存和恢复的具体过程？（ 99% 的网文遗漏的关键细节）
- 状态保存和恢复的的注意事项？
- 如何避免 “配置发生变化” 导致的重建？
- 综上
 |
1
KunMinX OP 阅读完的小伙伴，即使不为本文点赞，也请为自己点个赞！
其实这类进阶基础的硬核文章，就像乘坐杭州地铁一样。 多数人自以为很会买票、而不屑学习和改进、在老式购票机器前排起长长的队。 只有极少数主动思考的人，才会知道：其实根本不用买票，更不用排队，扫码即可进站！ |
 |
2
firefffffffffly 2019-06-17 11:50:22 +08:00
1. Saved instance state 也是基于序列化与反序列化的磁盘访问，与设计良好的自定义持久化缓存性能应该没有区别，自定义持久化性能问题主要来自于持久化方式的设计问题。
2. 自定义持久化的生命周期是比 Saved instance state 要长的，可以做到 activity 反复 finish/start 之后也能共享数据，这个场景是不能被 SavedInstanceState 取代的，不过这个应该不是这篇文章的重点。 3. 由于 SavedInstanceState 的性能问题，android 官方推荐将页面状态拆分，使用 ViewModel 模式内存存储绝大部分状态，小部分关键状态交给 SavedInstanceState 保存。 4. 大部分状态保持问题并非是使用错了方式，而是没有理清页面上所存在的状态，导致状态只有一部分被恢复 /保存，进而把整个页面逻辑导向到不可预测的方向。 5. 推荐其他开发者使用 android:configChanges 时，最好同时告诉他们可能存在的副作用： https://developer.android.com/guide/topics/resources/runtime-changes.html#HandlingTheChange 以上内容均总结于官方文档（ https://developer.android.com/topic/libraries/architecture/saving-states ） |
 |
3
kylix 2019-06-17 12:10:56 +08:00
啊？我有公交卡啊！排啥队？扫啥码？不懂
：） |
 |
4
BigDogWang 2019-06-17 12:21:55 +08:00
老哥你的同事有点菜#滑稽
|
|
5
KunMinX OP @firefffffffffly 感谢你的补充 : )
@BigDogWang 说我同事 “菜” 之前，请务必自检一下下文《 Activity 任务和返回栈》的 11 道深度思考提问，你若答得上 2 个，我就算你过！ #阴险滑稽 https://xiaozhuanlan.com/topic/7812045693 |
Select Language