Android内存管理粒度 – 活动还是流程?

我看到不一致的文档和讨论有关Android内存不足时所发生的事情以及操作系统重新声明内存的步骤。 更具体地说,Android会以活动/片段或整个过程的粒度杀死吗?

例如,如果在活动A前面启动了活动B(并且两个活动都是同一个应用程序/进程的一部分),则活动A可以被操作系统杀死,而活动B位于前台,用户正在与活动B交互(假设:屏幕保持打开,当前应用程序保留在前台,没有发生方向更改)?

2011年的答案 (由Dianne Hackborn在谷歌的Android团队中)表明,Android会以流程的粒度而不是活动来杀死。

在重新创建活动的Android开发者页面上,它说:

如果系统当前已停止且未长时间使用或前台活动需要更多资源,系统也可能会破坏您的活动,因此系统必须关闭后台进程才能恢复内存。

注意歧义:“系统必须关闭后台进程 ”。

在OnSaveInstanceState的Android Developer页面上,它说:

例如,如果活动B在活动A前面启动,并且在某些时候活动A被杀死以回收资源,活动A将有机会通过此方法保存其用户界面的当前状态

在阅读了这些以及许多其他文档页面和在线讨论之后,目前尚不清楚正确的答案是什么。

我也有关于片段的相同问题:由于内存不足而导致背景片段被杀死,而整个过程是否被杀死?

内存管理发生在两个不同的级别:通过垃圾收集(回收未引用的对象)和进程级别,如本Android博客文章中所述 。 没有杀死一个活动的概念 (记住:Android基于Linux而Linux没有活动或组件的概念,只有流程)。

2011年的答案(由Dianne Hackborn在谷歌的Android团队中)表明,Android会以流程的粒度而不是活动来杀死。

这仍然是正确的。

在重新创建活动的Android开发者页面上,它说……

是的,它提到的“后台流程”正是上述博客和文档中提到的流程类别。 这指的是以前存在的活动,但不再是当前前景/可见过程的一部分。

在OnSaveInstanceState的Android Developer页面上,它说:

是的,他们正在讨论从另一个进程启动一个Activity的情况(就像你使用隐式意图时那样 )。 在此期间,您的进程不是前台进程,因此如果前台活动+前台服务的组合太多,肯定可能会被杀死。

我也有关于片段的相同问题:由于内存不足而导致背景片段被杀死,而整个过程是否被杀死?

不,由于内存不足,碎片不能被杀死。

我会在Android指南和文档方面犯错(尽管如果它们在代码文档和SO答案中更清晰,那将会很棒)。 来自http://developer.android.com/guide/components/tasks-and-back-stack.html :

当系统停止您的某个活动时(例如,当新活动启动或任务移至后台时),如果需要恢复系统内存,系统可能会完全销毁该活动。 发生这种情况时,有关活动状态的信息将丢失。 如果发生这种情况,系统仍然知道活动在后端堆栈中有一个位置,但是当活动被带到堆栈顶部时,系统必须重新创建它(而不是恢复它)。 为了避免丢失用户的工作,您应该通过在活动中实现onSaveInstanceState()回调方法来主动保留它。

它是“进程”而不是“Android活动”。 部分困惑在于“ActivityManager”的命名,它执行内存分析的一部分,并且还管理Android-Activity接口。 但是,LMK(低内存杀手)确实负责根据ActivityManager和其他系统接口提供的信息停止进程。

我在http://www.programering.com/a/MjNzADMwATE.html的 “oom_adj和上层流程重要性之间的关系”部分find了对此的简要分析。