我有一个关于 onRestoreInstanceState 和的onSaveInstanceState 的几个问题。

1）在哪里这些方法符合活动的生命周期？我已经读了很多文件，但目前还没有明确的想法，只是一个笼统的陈述，当活动的状态将被保存

2）是否的onCreate 和 onRestoreInstanceState 相互排斥？

3） onRestoreInstanceState 时调用该活动被破坏？这是什么意思？活动总破坏，除了当另一个活动是浮在当前的顶部场景。

4） onRestoreInstanceState 出现被称为仅从仪表果冻豆。这是不再相关的活动的生命周期？

在哪里这些方法符合活动的生命周期？

的onSaveInstanceState被称为权利之前您的活动即将被杀死或重新启动（如B / C的内存pressure或配置更改）。请注意，这是不同于它的onPause被调用时，你的活动失去焦点（例如，你转换到另一个活动）。

通常的onSaveInstanceState会后的onPause不过的onStop之前，但并不总是被调用。例如，如果你preSS回来，那么活性被破坏（比如调用完成（）），并没有必要保存状态，这样的onSaveInstanceState不叫。那么，为什么不只是保存的onPause状态？只是由于活动失去焦点并不意味着它已经被杀死。它仍然是在存储器中。基本上你不希望每次都将暂停，而是当你停下来，即将成为无形的时间保存状态（即从前台到后台）。

那么，你应该在的onPause吗？理想情况下，你应该释放耗尽你的电池，例如网络连接资源，关闭地理或加速度计，暂停播放视频（这一切取决于你的应用程序）。而恢复这些资源onResume，正如你可能已经猜到了，被调用时，你的活动获得焦点。

是的onCreate和onRestoreInstanceState相互排斥？

onRestoreInstanceState是多余的，因为你可以很容易地的onCreate恢复状态。

话说回来，这里是官方的医生说的onRestoreInstanceState：

大多数实现会简单地使用的onCreate（包）来恢复自己的状态，但它有时是方便以后所有的初始化已完成或在这里做的让子类来决定是否使用默认的实施

所以，最佳实践，奠定了在你的onCreate视图层次和恢复onRestoreInstanceState的previous状态。如果你这样做，谁的子类的活动可以选择覆盖您onRestoreInstanceState扩大或代替你的恢复状态的逻辑。这句话的意思很长的路要走 onRestoreInstanceState作为一个模板方法

在onRestoreInstanceState称为活动时被破坏？这是什么意思？

这部分地回答1.是的，OnRestore中被调用时，系统将要摧毁你的活动。该系统将摧毁你的活动时，它是根据内存pressure或用户明确地关闭应用程序（例如扫描，删除在导航栏最近通话），或者有一个配置更改（如解构为纵向）。

为什么Android的设计是这样的（不像桌面应用程序）？由于在移动系统，资源管理是一种急性B / C的电池寿命问题。所以，你要提供挂钩到应用程序生命周期，使应用程序可以清晰保存和恢复关机或失去焦点之间的状态，而在同一时间使其完全TRANSPARANT给用户。

onRestoreInstanceState似乎叫仅从仪表果冻豆。这是不再相关的活动的生命周期？

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

I have a couple of question regarding onRestoreInstanceState and onSaveInstanceState.

1) where do these methods fit the activity lifecycle? I have read a lot of documentation but there is no clear idea, except a broad statement that when the state of the activity is to be saved

2) Are onCreate and onRestoreInstanceState mutually exclusive?

3) is onRestoreInstanceState called when the activity is destroyed? what does this mean? an activity always destroyed except for scenarios when another activity is floating on top of current.

4) onRestoreInstanceState appears to be called only from instrumentation in jelly bean. Is this no longer relevant to activity lifecycle?

where do these methods fit the activity lifecycle?

OnSaveInstanceState is called right before your activity is about to be killed or restarted (e.g b/c of memory pressure or configuration change). Note that this is different from onPause which gets called when your activity loses focus (e.g you transition to another activity).

Usually onSaveInstanceState will be called after onPause but before onStop but not always. E.g if you press back, then the activity is destroyed (like calling finish()) and there is no need to save state so onSaveInstanceState is not called. So why not just save state in onPause? Just because the activity loses focus doesn't mean it has been killed. It is still in memory. Basically you don't want to save state every time you are paused but rather when you are paused and about to become invisible (i.e go from foreground to background).

So what should you do in onPause? Ideally you should release resources that drain your battery e.g network connections, turn off geo or accelerometer, pause a video (all of this depends on your app). And restore these resources in onResume which, as you might have guessed, gets called when your activity gains focus.

Are onCreate and onRestoreInstanceState mutually exclusive?

onRestoreInstanceState is redundant because you can easily restore state in onCreate.

Having said that here is what the official doc says for onRestoreInstanceState:

Most implementations will simply use onCreate(Bundle) to restore their state, but it is sometimes convenient to do it here after all of the initialization has been done or to allow subclasses to decide whether to use your default implementation.

So for best practice, lay out your view hierarchy in onCreate and restore the previous state in onRestoreInstanceState. If you do that, anyone who subclasses your Activity can chose to override your onRestoreInstanceState to augment or replace your restore state logic. This is a long way of saying onRestoreInstanceState serves as a template method.

is onRestoreInstanceState called when the activity is destroyed? what does this mean?

This was partially answered in 1. Yes, onRestore gets called when the system is about to destroy your activity. The system will destroy your activity when it is under memory pressure or the user explicitly closes the application (e.g swipe-delete from recents in nav bar) or there is a configuration change (e.g landspace to portrait).

Why is android designed like this (unlike desktop apps)? Because on mobile systems, resource management is an acute problem b/c of battery life. So you want to provide hooks into app lifecyle so that the app can cleanly save and restore their state between shutdowns or losing focus while at the same time making it totally transparant to the user.

onRestoreInstanceState appears to be called only from instrumentation in jelly bean. Is this no longer relevant to activity lifecycle?

I don't understand this question. Can you rephrase it?