Java 为什么使用保留片段在配置更改过程中保持状态?

Java 为什么使用保留片段在配置更改过程中保持状态?,java,android,fragment,lifecycle,Java,Android,Fragment,Lifecycle,我读了很多关于活动和片段生命周期、配置更改以及如何在这些过程中保持状态的内容 从我收集的信息来看,官方似乎建议保留片段以保持状态,即使必须保留的数据来自某个活动 我想知道,为什么这种方法比例如将状态保持在由应用程序集中管理的单例中更好? 据我所知,没有应用程序就不可能有任何片段/活动,那么为什么不使用它呢 我知道单身汉是不受欢迎的,但在我看来,这将是一个很好的解决问题的办法,不会仅仅为了保持状态而制造(和滥用?)看不见的片段 为什么这种方法比例如将状态保持在由应用程序集中管理的单例中更好 对于应

我读了很多关于活动和片段生命周期、配置更改以及如何在这些过程中保持状态的内容

从我收集的信息来看,官方似乎建议保留片段以保持状态,即使必须保留的数据来自某个活动

我想知道,为什么这种方法比例如将状态保持在由应用程序集中管理的单例中更好? 据我所知,没有应用程序就不可能有任何片段/活动,那么为什么不使用它呢

我知道单身汉是不受欢迎的,但在我看来,这将是一个很好的解决问题的办法,不会仅仅为了保持状态而制造(和滥用?)看不见的片段

为什么这种方法比例如将状态保持在由应用程序集中管理的单例中更好

对于应用程序范围的状态,单例是可以的。但是,特定的
活动
子类可能有零个、一个或多个实例,这使得单例方法有问题。另外,总的来说,我们尽量不让更多的单例出现,因为它们容易导致内存泄漏

使用形容词“reserved”的原因是,保留的片段基于旧的
onretainonconfigurationinstance()
,这是在配置更改时将任意对象从旧活动传递到新活动的一种方式。保留片段有助于围绕“保留实例”构造实施更好的编码实践


实际上,在可能的情况下,您的状态应该进入保存的实例状态<代码>包,因为这不仅有助于配置更改,而且如果在进程由于内存不足而终止进程后返回到您的任务。

我甚至没有考虑到活动/片段的不止一个实例,这绝对有道理。我认为不可能使用该捆绑包,因为我想持久化我的REST请求等,以便在活动重新启动后可以重用它们。谢谢你的帮助!