为什么重新创建应用程序但 activity 的 onCreate 仍然有传入的 savedInstanceState

why the application is recreated but the activity's onCreate still has the savedInstanceState passed in

存在与 os kill/restore activity(或应用程序?)相关的错误。

经过一些调试发现如果设置 don't keep activities 并将 Background process limit 设置为 no background process 将导致不同的行为。

看到了this post,但是这里没有回答问题

这是观察到的:

在应用程序中它将启动匕首组件并维护一些应用程序范围的单例对象,并且在 activity A(默认启动 activity)中它将通过用户的操作启动 activity B,它在 B 中创建并 hosts 一个片段。将有一些数据存储在应用程序范围单例对象中以与片段一起使用。

在只有 don't keep activities 设置的情况下,当最小化应用程序时调用活动 onDestroy(),当重新打开应用程序时它恢复最后一个活动 activity(比如用户打开了 activity B,B 将被重新创建,片段通过 savedInstanceState 恢复)。在这种情况下,由 dagger 管理的应用程序范围单例对象仍然存在,因此状态完全恢复到最小化应用程序之前的状态。

但是如果同时设置了don't keep activities并且将Background process limit设置为no background process,那么在最小化应用程序时,activity的onDestroy()不会被调用(仅调用 onStop()).

此时的行为变化是如果重新打开app,会从application onCreate()开始,重新创建匕首的组件。所以最小化应用程序之前的状态不会重新存储。

但是os好像还记得最后一个activity是B和B的

onCreate(savedInstanceState: Bundle?) 

调用 savedInstanceState 在最小化应用程序时保存数据,B 的片段也是如此。

它一团糟,它有来自 savedInstanceState 的数据,但是应用程序范围单例对象是新的,没有数据可以与来自 savedInstanceState 的对象一起工作。

任何人都知道在这种情况下 savedInstance 保存在哪里,以及为什么虽然应用程序似乎已重新创建但仍然是最后一个 activity(不是启动 activity)被重新存储?

savedInstanceState 包明确旨在按照您的描述进行操作。无论后台 activity 是否被销毁以节省内存(例如 "don't keep activities" 已打开)或整个应用程序进程是否被终止以节省内存(例如 "background process limit" 为零),框架将为您的应用程序提供将状态信息保存到 savedInstanceState 包中的能力,并随后 return 在将来调用 onCreate().

时向您提供该状态信息

savedInstanceStatenull 的情况是您的 activity 第一次启动。您的应用进程是否被终止并不重要;如果您的 activity 恢复了,您将收到一个 non-null savedInstanceState 捆绑包。