我看到不一致的文档和讨论有关Android内存不足时所发生的情况以及操作系统重新声明内存的步骤。更具体地说，Android会以活动/片段或整个过程的粒度杀死吗？
例如，如果活动B在活动A前面启动（并且两个活动都是同一个应用程序/进程的一部分），则活动A可以被操作系统杀死，而活动B位于前台并且用户正在进行交互使用活动B（假设：屏幕保持打开，当前应用程序保留在前台，不会发生方向更改）？
2011年的这个SO answer（来自谷歌Android团队的Dianne Hackborn）表明，Android会以流程的粒度而不是活动为止。
在Recreating an Activity上的Android开发者网页上，它说：
如果活动当前已停止且未长时间使用或前台活动需要更多资源，系统也可能会破坏您的活动，因此系统必须关闭后台进程才能恢复内存。
注意歧义：“系统必须关闭背景 PROCESSES ”。
在onSaveInstanceState的Android开发者页面上，它说：
例如，如果活动B在活动A前面启动，并且在某些时候活动A被杀死以回收资源，活动A将有机会通过此方法保存其用户界面的当前状态
在阅读了这些以及许多其他文档页面和在线讨论后，尚不清楚正确的答案是什么。
我也有关于片段的相同问题：由于内存不足而导致背景片段被杀死，而整个过程没有被杀死？
答案 0 :(得分：5)
内存管理发生在两个不同的级别：通过垃圾收集（回收未引用的对象）和进程级别，如this Android blog post中所述。 没有杀死一个活动的概念（请记住：Android基于Linux而Linux并没有活动或组件的概念，只是流程）。
2011年的答案（来自谷歌Android团队的Dianne Hackborn）表明，Android会以流程的粒度而不是活动为止。
这仍然是正确的。
在重新创建活动的Android开发者页面上，它说......
是的，＆＃39;后台流程＆＃39;它提到的正是上述博客和the documentation中提到的流程类别。这指的是以前存在的活动，但不再是当前前景/可见过程的一部分。
在onSaveInstanceState的Android Developer页面上，它说：
是的，他们正在讨论从另一个进程启动活动的情况（就像您使用implicit intents时那样）。在此期间，您的进程不是前台进程，因此如果前台活动+前台服务的组合太多，肯定会被杀死。
我也有关于片段的相同问题：由于内存不足而导致背景片段被杀死，而整个过程没有被杀死？
不，由于内存不足，碎片无法被杀死。
答案 1 :(得分：0)
我会偏向于Android指南和文档（尽管如果它们在代码文档和SO答案中更清晰，那就太棒了）。来自http://developer.android.com/guide/components/tasks-and-back-stack.html：
当系统停止您的某个活动时（例如当新活动启动或任务移至后台时），如果需要恢复系统内存，系统可能会完全销毁该活动。发生这种情况时，有关活动状态的信息将丢失。如果发生这种情况，系统仍然知道活动在后端堆栈中有一个位置，但是当活动被带到堆栈顶部时，系统必须重新创建它（而不是恢复它）。为了避免丢失用户的工作，您应该通过在活动中实现onSaveInstanceState（）回调方法来主动保留它。
答案 2 :(得分：0)
是“进程”而不是“Android活动”。部分困惑在于“ActivityManager”的命名，它执行内存分析的一部分，并且还管理Android-Activity接口。但是，LMK（低内存杀手）真正负责根据ActivityManager和其他系统接口提供的信息停止进程。
的“oom_adj与上层流程重要性之间的关系”一节中对此进行了简要分析。