28

我指的是为什么使用 Fragment#setRetainInstance(boolean)？

我这么问的原因是为了Activity处理轮换，官方活动文档鼓励我们在轮换期间让Activity关机和重启。

android:configChanges 列出活动将自行处理的配置更改。当运行时发生配置更改时，默认情况下会关闭并重新启动 Activity，但使用此属性声明配置会阻止 Activity 重新启动。相反，活动保持运行并调用其 onConfigurationChanged() 方法。注意：应避免使用此属性，并且仅将其用作最后的手段。有关如何正确处理由于配置更改而重新启动的更多信息，请阅读处理运行时更改。

任何更改此 Activity 默认行为的尝试似乎都是不好的做法。为了避免Activity在重启过程中重新加载耗时的数据结构，我们使用了onRetainNonConfigurationInstanceand getLastNonConfigurationInstance。-官方处理运行时更改

但是，当谈到在 Fragment 中处理轮换时，Google 是否给了我们不同的建议？他们不希望我们关闭并重新启动 Fragment 吗？

公共对象 onRetainNonConfigurationInstance ()

此方法在 API 级别 13 中已弃用。请改用新的 Fragment API setRetainInstance(boolean)；这也可以通过 Android 兼容包在旧平台上使用。

  1. 为什么 Google 鼓励我们在轮换期间关闭并重启 Activity，而鼓励我们在轮换期间保留 Fragment？
  2. 如果setRetainInstance(true)擅长处理轮换，为什么 Google 不将其作为 Fragment 的默认行为？
4

2 回答 2

33

  • 配置更改：当屏幕突然变得更宽且高度更小（典型的风景）时，视觉组件倾向于更新其显示并更智能地使用可用的屏幕。配置更改的另一个示例是用户滑动硬件键盘、更改设备语言等。为什么要重新开始：

    • Android 组件偏爱声明式布局，您可以加载一堆 XML 布局，然后从那里开始工作。查找每个视图并实时重新排列/更新它会很麻烦，更不用说重新连接所有事件处理程序和其他自定义视图代码了。它更容易重新加载另一组布局文件。

    • 此外，在 Android 中，Activity 有点受系统支配，因此很自然地，Activity 生命周期的设计（和推荐）使其能够随时按需重新创建自己，就像以前一样被摧毁。此模式适用于所有重新启动，以及由于配置更改而导致的重新启动。如果您使您的活动和片段能够维持一个永恒的状态，那么配置更改将不是那么大的问题。

    • 保留状态数据（模型），而不是显示它的东西（UI 和视图）。

  • setRetainInstance(true)：建议仅与不包含任何引用的片段一起使用，这些片段将在旋转时重新创建。这意味着您不应该在任何包含上下文、视图等的片段上使用它。典型的视觉片段可以。但它对于保存对象的片段非常有用，如运行线程、异步任务、数据集合、加载的资产、获取的结果等。此方法有助于将非可视片段用作可拆卸的持有者，用于 Activity 的非上下文相关对象.

于 2013-02-25T11:59:40.943 回答
4

因为你误解了它的用途。setRetainInstance(true)只能用于类似于单独元素/模块的片段。处理套接字等的片段没有 GUI 真正受益于保留。带有 GUI 的片段可能不应该使用setRetainInstance(true). 此外，任何进入后台堆栈的片段都不应该使用setRetainIstance(true).

您可以将其推广到任何只处理数据/连接等的片段应该使用setRetainInstance(true). 但是有许多不同的方法可以使用 Fragments，这不会从setRetainInstance(true).

于 2013-02-25T11:54:29.660 回答