现代版本的 Android 是否会自动清除任务？答案

【问题标题】：Does automatic task clearing occur in modern versions of Android?现代版本的 Android 是否会自动清除任务？
【发布时间】：2013-09-17 10:26:49
【问题描述】：

根据 Android 文档，系统将清除它认为已被用户放弃的任务（完成启动该任务的所有活动）：

https://developer.android.com/guide/components/tasks-and-back-stack.html#Clearing

如果用户长时间离开一个任务，系统会清除该任务除根Activity之外的所有Activity。当用户再次返回任务时，仅恢复根活动。系统的行为方式是这样的，因为在很长一段时间后，用户可能已经放弃了他们之前正在做的事情并返回到任务中开始新的事情。

https://developer.android.com/guide/topics/manifest/activity-element.html#always

通常，当用户从主屏幕重新选择该任务时，系统会在某些情况下清除任务（从根活动上方的堆栈中删除所有活动）。通常，如果用户在一定时间内（例如 30 分钟）没有访问任务，则会执行此操作。

这种行为很容易在运行 Gingerbread 及更早版本的设备上重现。启动一个应用程序并创建一些回溯历史，然后点击主页按钮并等待半小时。从主屏幕再次启动应用程序，状态已被清除，就好像它正在开始一项新任务一样。完美。

但是，在运行 ICS 及更高版本的设备上，我似乎根本无法重现此行为，即使任务在数小时或数天后处于非活动状态也是如此。当从主屏幕重新启动应用程序时，任务始终处于我离开时的状态。

假设文档正确，现代版本的 Android（API 14+）在什么情况下会自动清除任务？

如果行为已更改且文档已过时，<activity/> 的 alwaysRetainTaskState 属性的用途是什么？默认值是否已更改为 "true" 或者该属性现在已弃用？

注意：我不是在谈论 Android 的进程生命周期管理，这将取决于设备资源。无论如何，终止进程对用户应该是透明的，并且不会影响任务状态。

【问题讨论】：

您确定在 GB 上您没有看到由于后台任务需要而被系统杀死的应用程序吗？
也许任务存活的时间取决于内存量。尝试打开大量占用大量内存的应用程序，然后再打开您的应用程序。现在看看是否会发生同样的事情。另一个有趣的事情是拿一个旧设备，比如 Nexus S，闪存 GB ROM 并模拟场景。之后 - 对库存 ICS ROM 执行相同操作，看看会发生什么。
如果这是由系统进程管理引起的，那么我预计任务堆栈中最顶层的 Activity 已根据进程和 Activity 生命周期从 Bundle 状态重新创建和恢复。如文档中所述，当我在空闲期后返回应用程序时在 Gingerbread 上看到的是根 Activity 和已清除的任务。
感谢测试非常耗时，但想知道您已经尝试过什么？您是否尝试过将alwaysRetainTaskState 显式设置为"false"？等待更长的时间怎么办？例如一夜之间！
只是为了澄清，您是否使用任何其他会改变行为的清单标签？我在我的 JB 设备上得到了同样的结果（即使是一夜之间，有几场耗费大量内存的游戏），但我目前没有 GB 的设备可以看到差异。

标签： android

【解决方案1】：

很好的问题，经过一番深入研究后，答案肯定让我感到惊讶！

快速浏览一下 Android 资源似乎可以提供答案。让我们从ActivityManagerService.java 回顾Android 2.2 开始。请注意在第 186 行附近定义了一个名为 ACTIVITY_INACTIVE_RESET_TIME 的常量，它恰好设置为 30 分钟。

// How long until we reset a task when the user returns to it.  Currently
// 30 minutes.
static final long ACTIVITY_INACTIVE_RESET_TIME = 1000*60*30;

进一步查看第 7021 行周围的 resetTaskIfNeededLocked() 方法，您将看到检查此值以确定是否应在启动之前重置任务。

快进到 Android 4.3 源代码，代码已移至从 ActivityManagerService 调用的ActivityStack.java，但基本结构相同。这一次，常量是在第 125 行定义的：

// How long until we reset a task when the user returns to it.  Currently
// disabled.
static final long ACTIVITY_INACTIVE_RESET_TIME = 0;

相同的resetTaskIfNeededLocked() 方法出现在第 1973 行附近，您可以看到现在它会检查值是否大于零，然后再应用相同的超时检查来清除任务状态。但请注意，此方法仍会检查 FLAG_ALWAYS_RETAIN_TASK_STATE，因此此标志仍可用于保护状态清除，但似乎禁用外部检查后，此代码将永远不会执行。

总体而言，这似乎是一个非常有说服力的证据，表明该功能已在 AOSP 中有效地为更高版本的 Android 禁用。我没有看到外部方法（通过系统属性等）可以为每个设备重新启用此值，除非制造商要重建代码并在此处添加值……但这并不常见。大多数 ODM 坚持在 XML 中配置属性或他们可以通过覆盖控制的系统属性。

因此，虽然从技术上讲，该功能尚未“删除”，但在我看来，文档在延迟后自动触发方面不再正确。

【讨论】：