【问题标题】:Are onCreate and onRestoreInstanceState mutually exclusive?onCreate 和 onRestoreInstanceState 是互斥的吗?
【发布时间】:2012-09-22 22:08:01
【问题描述】:

我有几个关于onRestoreInstanceStateonSaveInstanceState 的问题。

1) 这些方法在哪里适合活动生命周期?我已经阅读了很多文档,但没有明确的想法,除了一个广泛的声明,即何时保存活动的状态

2) onCreateonRestoreInstanceState 是否互斥?

3) Activity 销毁时是否调用onRestoreInstanceState?这是什么意思?一个活动总是被销毁,除非另一个活动漂浮在当前活动之上。

4) onRestoreInstanceState 似乎只能从果冻豆中的仪器调用。这不再与活动生命周期相关吗?

【问题讨论】:

  • 附加信息:onRestoreInstanceState 在第一次创建活动时不会被调用,正如您可能已经猜到的那样

标签: android


【解决方案1】:

这些方法在哪里适合活动生命周期?

OnSaveInstanceState 在您的活动即将被终止或重新启动之前调用(例如内存压力或配置更改的 b/c)。请注意,这与 onPause 不同,后者在您的活动失去焦点时调用(例如,您转换到另一个活动)。

通常 onSaveInstanceState 将在 onPause 之后但在 onStop 之前调用,但并非总是如此。例如,如果您按回,则活动被破坏(如调用 finish())并且不需要保存状态,因此不会调用 onSaveInstanceState。那么为什么不在 onPause 中保存状态呢?仅仅因为活动失去焦点并不意味着它已被杀死。它仍在记忆中。基本上,您不想在每次暂停时保存状态,而是在您暂停并即将变得不可见时(即从前台转到后台)。

那么在 onPause 中你应该做什么呢?理想情况下,您应该释放消耗电池的资源,例如网络连接、关闭地理或加速度计、暂停视频(所有这些都取决于您的应用程序)。并在 onResume 中恢复这些资源,正如您可能已经猜到的,当您的活动获得焦点时会调用它。

onCreate 和 onRestoreInstanceState 是互斥的吗?

onRestoreInstanceState 是多余的,因为您可以在 onCreate 中轻松恢复状态。

话虽如此,官方文档对 onRestoreInstanceState 的说法如下:

大多数实现将简单地使用 onCreate(Bundle) 来恢复它们的状态,但有时在完成所有初始化之后在这里这样做会很方便,或者 允许子类决定是否使用您的默认实现。

因此,为了获得最佳实践,请在 onCreate 中布置视图层次结构并在 onRestoreInstanceState 中恢复之前的状态。如果你这样做,任何继承你的 Activity 的人都可以选择覆盖你的 onRestoreInstanceState 来增加或替换你的恢复状态逻辑。说onRestoreInstanceState 用作模板方法,这是一个很长的路要走。

Activity 销毁时是否调用 onRestoreInstanceState?这是什么意思?

这在 1 中得到了部分回答。是的,onRestore 在系统即将销毁您的活动时被调用。当系统处于内存压力或用户明确关闭应用程序(例如从导航栏中的最近浏览器中滑动删除)或存在配置更改(例如从陆地空间到纵向)时,系统将销毁您的活动。

为什么 android 是这样设计的(不像桌面应用)?因为在移动系统上,资源管理是电池寿命的一个尖锐问题。因此,您希望在应用程序生命周期中提供挂钩,以便应用程序可以在关闭或失去焦点之间干净地保存和恢复其状态,同时使其对用户完全透明。

onRestoreInstanceState 似乎只能从果冻豆中的仪器调用。这不再与活动生命周期相关吗?

我不明白这个问题。能改一下吗?

【讨论】:

  • 文档说Note that it is important to save persistent data in onPause() instead of onSaveInstanceState(Bundle) because the latter is not part of the lifecycle callbacks, so will not be called in every situation as described in its documentation.
  • @Joseph82 文档中该语句唯一令人讨厌的是,捆绑对象 savedInstanceState 未通过强制应用程序使用其他方式(sharedPrefs、sqliteDB)存储数据
【解决方案2】:

1) 这些方法在哪里适合活动生命周期?

来自开发者文档。

onSaveInstanceState(捆绑输出状态)

这个方法在一个activity可能被杀死之前被调用,这样当它在未来某个时间回来时它可以恢复它的状态。例如,如果活动 B 在活动 A 之前启动,并且在某个时刻活动 A 被杀死以回收资源,活动 A 将有机会通过此方法保存其用户界面的当前状态,以便当用户返回时对于activity A,可以通过onCreate(Bundle)或者onRestoreInstanceState(Bundle)来恢复用户界面的状态。

onSaveInstanceState() 的默认实现负责保存与每个具有 id 的每个视图相关的数据。

如果被调用,这个方法会在onStop()之前发生。不保证它会在onPause()之前还是之后发生。

onRestoreInstanceState (Bundle savedInstanceState)

该方法在 onStart() 之后调用,当 Activity 从之前保存的状态重新初始化时

3) Activity 销毁时是否调用 onRestoreInstanceState? 这是什么意思?一个活动总是被破坏,除了场景 当另一个活动漂浮在当前活动之上时。

该方法在 onStart() 之后调用,此时 Activity 从之前保存的状态重新初始化,此处在 savedInstanceState 中给出 (这是一个包含保存在 onSaveInstanceState(Bundle) 中的数据的包对象)。

大多数实现将简单地使用 onCreate(Bundle) 来恢复它们的状态,但有时在完成所有初始化后在此处执行此操作或允许子类决定是否使用您的默认实现会很方便。该方法的默认实现会恢复之前被 onSaveInstanceState(Bundle) 冻结的任何视图状态。

4) onRestoreInstanceState 似乎只能从 果冻豆中的仪器。这是否不再与活动相关 生命周期?

没有。 onRestoreInstanceState 从 API 级别 1 开始就存在。它仍然是新 Jelly Bean API 的一部分。

【讨论】:

  • 我自己可以从文档中访问所有这些信息。我看到的是,在某些情况下,如果 onCreate/onRestoreInstance 互斥,我会看到一些 NPE。因此,我会尝试找到一个可以最终确定何时回调这些方法的地方
  • 绝对不是互斥的。 onCreate 在 Activity 创建期间总是被调用。仅当有要恢复的实例时才会调用 onRestoreInstance。 (某些退出应用的方式不会创建实例)
【解决方案3】:
  1. 如果您的 Activity 被终止,例如您启动了另一个 Activity,但系统的资源不足需要终止您的 Activity,您可以使用 onSaveInstanceState 保存状态然后恢复它。

  2. 不一定。 onCreate 是在 onStart 之前调用,但 onRestoreInstanceState 是在 onStart 之后调用,所以这取决于您要实现的目标

  3. 您的意思是 onSaveInstanceState。那么它会在活动被杀死时调用,如上面第 1 点所示

  4. 抱歉...我不知道,我没有在 Jellybean 上尝试过

【讨论】:

  • 会一直调用 onCreate 吗?因为对我来说 onRestoreInstanceState 似乎在各个方面都是多余的
  • 没有。 onCreate 在您的应用停止或冷启动时调用。它们不是多余的,它们被调用的顺序是不同的,这非常重要,具体取决于您要执行的操作(即恢复应用程序的状态)。
  • “onCreate 在 onStart 之前调用,但 onRestoreInstanceState 在之后调用” - 感谢您指出这一点。顺便说一句,我发现 onCreate 和 onResume 的组合很有用,因为无论是否有捆绑软件,它们都会运行。我在 onCreate 中做出所有决定,如果存在,则使用来自 bundle 的信息,或者来自我保存在其他地方的其他持久性存储,或者如果首次运行,则使用默认值。然后 onResume 会执行任何在 onCreate 中无法完成的最后步骤。 onResume 中没有捆绑访问权限,因此依赖 onCreate 来准备本地字段。
猜你喜欢
  • 2011-09-22
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-07-24
  • 2016-02-13
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多