放弃申请是不被允许的吗？

你可以退出，要么按下返回按钮，要么在你的Activity中调用finish()。如果你想明确地杀死它，只需从MenuItem中调用finish()。

罗曼并不是说这是不可能的，只是说这是毫无意义的-用户不需要关心退出或保存他们的工作或其他任何事情，因为应用程序生命周期的工作方式鼓励您编写智能软件，无论发生什么都会自动保存和恢复其状态。

我认为关键是没有必要退出应用程序，除非你有错误的软件。当用户不使用它并且设备需要更多内存时，Android会退出应用程序。如果你有一个需要在后台运行服务的应用程序，你可能需要一种方法来关闭服务。

例如，当应用程序不可见时，谷歌收听会继续播放播客。但是当用户用完播客时，总是有暂停按钮可以关闭播客。如果我没记错的话，听，甚至在通知栏中放了一个快捷方式，这样你就可以随时快速到达暂停按钮。另一个例子是像推特应用程序这样的应用程序，它经常在互联网上投票一项服务。这些类型的应用程序应该真正允许用户选择轮询服务器的频率，甚至是否在后台线程中投票。

如果您需要在退出时运行代码，您可以根据需要覆盖onPance（）、onStop（）或onDestroy（）。http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle

由于Android上下文中的应用程序只是一堆模糊相关的活动，退出应用程序并没有太大意义。你可以完成（）一个活动，并将绘制活动堆栈中上一个活动的视图。

这最终会到达你的问题，但我首先想解决你在写这篇文章时已经给出的各种答案的各种评论中提出的一些问题。我无意改变你的想法--相反，这些是为将来阅读这篇文章的人准备的。

问题是我不能允许Android来确定我的应用程序何时将被终止那一定是用户的选择。

数百万人对环境根据需要关闭应用程序的模型非常满意。这些用户根本不考虑“终止”Android应用程序，就像他们不考虑“终止”网页或“终止”恒温器一样。

iPhone用户也是如此，因为按下iPhone按钮并不一定会“感觉”应用程序被终止，因为许多iPhone应用程序会在用户离开的地方继续使用，即使应用程序真的被关闭了（因为iPhone一次只允许一个第三方应用，目前）。

正如我上面所说，有很多我的应用程序中发生的事情（数据是推送到设备，列出任务#36825；，一直都在那里等）。

我不知道“列出应该始终存在的任务”是什么意思，但是“数据被推送到设备”是一个令人愉快的虚构，在任何情况下都不应该通过活动来完成。使用计划任务（通过AlarmManager）更新您的数据以获得最大的可靠性。

我们的用户登录后无法进行操作每次他们接到电话而Android决定杀死这个应用程序。

有许多iPhone和Android应用程序可以处理这个问题。通常，这是因为它们保留了登录凭据，而不是强制用户每次手动登录。

例如，我们要检查更新退出应用程序时

这在任何操作系统上都是一个错误。据你所知，你的应用程序被“退出”的原因是因为操作系统正在关闭，然后你的更新过程将在中途失败。通常，这不是一件好事。要么在启动时检查更新，要么完全异步检查更新（例如，通过计划任务），永远不会退出。

一些评论建议点击后退按钮不会杀死应用程序全部（见上面问题中的链接）。

按下BACK按钮不会“杀死应用程序”。它完成了用户按下BACK按钮时屏幕上的活动。

它应该只在用户想要终止它-永远不会任何其他方式。如果你不能写在Android中表现类似的应用程序，那我觉得安卓不能用了编写真正的应用程序=（

然后Web应用程序也不能。或者WebOS，如果我正确理解他们的模型（还没有机会玩一个）。在所有这些中，用户不会“终止”任何东西——他们只是离开。iPhone有点不同，因为它一次只允许一件事运行（除了少数例外），所以离开的行为意味着应用程序相当立即的终止。

有没有办法让我真正戒掉应用程序？

正如其他人告诉你的那样，用户（通过BACK）或你的代码（通过finish()）可以关闭你当前运行的活动。对于正确编写的应用程序，用户通常不需要其他任何东西，就像他们需要使用Web应用程序的“退出”选项一样。

根据定义，没有两个应用程序环境是相同的。这意味着您可以在新环境出现和其他环境被埋没时看到环境的趋势。

例如，越来越多的人试图消除“文件”的概念。大多数Web应用程序不会强迫用户想到文件。iPhone应用程序通常不会强迫用户想到文件。Android应用程序通常不会强迫用户想到文件。等等。

类似地，越来越多的人试图消除“终止”应用程序的概念。大多数Web应用程序不强制用户注销，而是在一段时间不活动后隐式注销用户。Android也是如此，在较小程度上，iPhone（可能还有WebOS）。

这需要更多地强调应用程序设计，专注于业务目标，而不是坚持与以前的应用程序环境相关的实现模型。缺乏时间或意愿这样做的开发人员会对打破他们现有心理模型的新环境感到沮丧。这不是任何一个环境的错，就像暴风雨在它周围流动而不是穿过它一样。

例如，一些开发环境，如HyperCard和Smalltalk，将应用程序和开发工具混合在一个设置中。除了应用程序的语言扩展之外，这个概念并没有流行起来（例如Excel中的VBA，AutoCAD中的Lisp）。因此，想出心智模型假设应用程序本身中存在开发工具的开发人员要么不得不改变他们的模型，要么将自己限制在他们模型成立的环境中。

当你写：

除了那些乱七八糟的东西发现，我认为开发我们的Android应用程序不会发生

目前，这似乎对你来说是最好的。同样，我会建议你不要试图将你的应用程序移植到Web，因为你报告的Android的一些相同问题，你也会在Web应用程序中找到（例如，没有“终止”）。或者，相反，如果有一天你做将你的应用程序移植到Web，你可能会发现Web应用程序的流可能更适合Android，那时你可以重新访问Android端口。

泰德，你想要完成的事情是可以完成的，也许只是不是你现在想的那样。

建议大家多读点活动和服务，不要再用app这个词了，开始用app这两个组件，活动和服务就是其中的组件。大家对于安卓平台的认知跟普通的PC端app是完全不同的，所以需要多读点。从你所有的文章里面没有活动这个词（除了FAQ引用，就是没有你的文字）这个事实，我觉得你还需要多读点。

在任何情况下，如果您想终止您的应用程序，您可以随时调用System.exit(0);。

我会考虑阅读艾迪生-韦斯利出版的《Android无线应用开发》。我刚刚完成它，它非常彻底。

看来你对Android平台有一些根本性的误解。起初我也对Android应用程序的生命周期感到有点沮丧，但在加深理解后，我开始真正喜欢这种方法。这本书将回答你所有的问题等等。这真的是我为Android新手找到的最好的资源。

此外，我认为你需要放弃现有应用程序的逐行移植。为了将你的应用程序移植到Android平台，一些应用程序设计将会发生变化。使用的应用程序生命周期是必要的，因为相对于桌面系统，移动设备的资源非常有限，并且允许Android设备以有序和资源感知的方式运行多个应用程序。对平台做一些更深入的研究，我想你会意识到你想做的是完全可行的。祝你好运。

顺便说一句，我与Addison-Wesley或任何与这本书相关的个人或组织没有任何关系。重新阅读我的帖子后，我觉得我有点狂热。我真的，真的很喜欢它，发现它非常有帮助。：）

嗯…

我认为你只是没有正确看待Android应用程序。你可以轻松地做一些几乎像你想做的事情：

• 应用程序活动保存/恢复状态，就像开发人员生命周期留档中鼓励的那样。

• 如果在还原阶段需要一些登录（没有可用的登录/会话信息），那么就这样做。

• 最终添加一个按钮/菜单/超时，在这种情况下，您将执行finish()而不保存登录名和其他会话信息，从而隐式地结束应用程序会话：因此，如果应用程序再次启动/带到前面，它将开始一个新会话。

这样，您就不会真正关心应用程序是否真的从内存中删除。

如果你真的想从内存中删除它（不鼓励这样做，顺便说一句，目的是什么？）你可以在onDestroy()末尾用java.lang.System.exit(0)（或者restartPackage(..)？）有条件地删除它。当然，只有在你想“真正结束应用程序”的情况下才这样做，因为onDestroy()是活动正常生命周期的一部分，根本不是应用程序结束。

我只是想在这里为这个帖子的未来读者添加一个更正。这个特殊的细微差别很长一段时间没有被我理解，所以我想确保你们都不会犯同样的错误：

如果堆栈上有多个活动，#0不会杀死您的应用程序。实际发生的是进程被终止并立即重新启动堆栈上少了一个活动。当您的应用程序被强制关闭对话框杀死时，甚至当您尝试从DDMS杀死进程时，也会发生这种情况。据我所知，这是一个完全没有记录的事实。

简短的回答是，如果你想退出你的应用程序，你必须跟踪堆栈中的所有活动，并在用户想要退出时finish()所有这些活动（不，没有办法迭代活动堆栈，所以你必须自己管理所有这些）。即使这实际上并没有杀死进程或你可能拥有的任何悬空引用。它只是完成了活动。此外，我不确定Process.killProcess(Process.myPid())是否更好；我还没有测试过。

另一方面，如果您可以在堆栈中保留活动，那么还有另一种方法可以让您变得非常简单：Activity.moveTaskToBack(true)将简单地为您的进程提供背景并显示主屏幕。

长长的答案包括解释这种行为背后的哲学。哲学诞生于许多假设：

1. 首先，这只发生在你的应用程序处于前台时。如果它在后台，进程会很好地终止。但是，如果它在前台，操作系统会假设用户想继续做他/她正在做的事情。（如果你想从DDMS中杀死进程，你应该先点击home按钮，然后杀死它）
2. 它还假设每个活动独立于所有其他活动。这通常是正确的，例如在您的应用程序启动浏览器活动的情况下，它是完全独立的，不是由您编写的。浏览器活动可能会也可能不会在同一个任务上创建，具体取决于它的清单属性。
3. 它假设你的每个活动都是完全自力更生的，可以在一瞬间被杀死/恢复。（我相当不喜欢这个特殊的假设，因为我的应用程序有许多依赖于大量缓存数据的活动，太大了，无法在onSaveInstanceState期间有效地序列化，但是怎么办？）对于大多数编写良好的Android应用程序来说，这应该是真的，因为你永远不知道你的应用程序什么时候会在后台被杀死。
4. 最后一个因素与其说是一个假设，不如说是操作系统的限制：显式杀死应用程序与应用程序崩溃相同，也与Android杀死应用程序以回收内存相同。这最终导致了我们的政变：由于Android无法判断应用程序是否退出、崩溃或在后台被杀死，它假设用户想要返回他们离开的地方，因此ActivityManager重新启动该进程。

当你想到它时，这适用于平台。首先，这正是当进程在后台被杀死并且用户返回到它时会发生的事情，因此需要从它停止的地方重新启动。其次，这是当应用程序崩溃并呈现可怕的强制关闭对话框时会发生的事情。

比方说，我希望我的用户能够拍照并上传它。我从我的活动中启动相机活动，并要求它返回一张图像。相机被推到我当前任务的顶部（而不是在它自己的任务中创建）。如果相机出现错误并崩溃，是否会导致整个应用程序崩溃？从用户的角度来看，只有相机失败了，他们应该返回到他们之前的活动。所以它只是重新启动进程，堆栈中所有相同的活动，减去相机。由于您的活动应该被设计成可以随时杀死和恢复，这应该不是问题。不幸的是，并不是所有的应用程序都可以这样设计，所以对我们许多人来说，这是一个问题，不管Romain Guy或其他任何人告诉你什么。所以，我们需要使用变通方法。

最后，我的建议是：

• 不要试图终止进程。要么在所有活动中调用finish()，要么调用moveTaskToBack(true)。
• 如果你的进程崩溃或被杀死，如果像我一样，你需要内存中现在丢失的数据，你需要返回根活动。为此，你应该使用包含Intent.FLAG_ACTIVITY_CLEAR_TOP标志的Intent调用startActivity()。
• 如果您想从Eclipse DDMS的角度终止您的应用程序，它最好不要在前台，否则它会自行重新启动。您应该先按Home按钮，然后然后终止该进程。

我所有的应用程序都有退出按钮……因此，我经常从用户那里得到积极的评论。我不在乎这个平台是否设计得很时尚，应用程序不应该需要它们。说“不要把它们放在那里”有点荒谬。如果用户想退出……我会为他们提供访问权限，让他们完全这样做。我不认为这会降低Android的运行方式，似乎是一个很好的做法。我理解生命周期……我的观察是，Android在处理它方面做得不好……这是一个基本事实。

我同意Ted的观点。我明白退出应用程序不是“Android方式”，但它似乎不应该被排除在外。在这里您可能需要真正退出应用程序的三个原因（不是只是活动）：

1. 用户可能想要控制哪个应用程序在内存不足的情况。如果重要的应用程序A在后台运行，那么您可能希望在完成后退出应用程序B，因此应用程序A不会被操作系统杀死。

2. 如果您的应用程序在内存中缓存了敏感数据，您可能会喜欢杀死应用程序，以便病毒/蠕虫/流氓应用程序无法获取它。我知道安全模型应该防止这种情况，但以防万一…

3. 如果您的应用程序使用资源（如网络、CPU、传感器等）可能会对手机产生不利影响，那么确保-这些资源被释放出来是为了退出应用程序-我明白行为良好的应用程序应该在不需要时释放资源。但同样，退出应用程序似乎是确保这一点的合理方法。

不要将您的应用程序视为一个单一的应用程序。它是一组UI屏幕，用户可以与您的“应用程序”和通过Android服务提供的“功能”进行交互。

不知道你的神秘应用“做了什么”并不重要。假设它通过隧道进入某个超级安全的公司内联网，执行一些监控或交互，并保持登录状态，直到用户“退出应用程序”。因为你的IT部门命令它，用户必须非常清楚他们何时进入或离开内联网。因此你认为用户“退出”很重要的心态。

这很简单。制作一个服务，在通知栏中放置一个正在进行的通知，说“我在Intranet中，或者我正在运行”。让该服务执行您的应用程序所需的所有功能。有绑定到该服务的活动，允许您的用户访问与您的“应用程序”交互所需的UI部分。还有一个Android菜单->退出（或注销，或其他什么）按钮，告诉服务退出，然后关闭活动本身。

从所有的意图和目的来看，这正是你所说的。以Android的方式完成。看看谷歌谈话或谷歌地图导航的例子，这种“退出”是可能的心态。唯一的区别是，在你的活动中按下后退按钮可能会让你的UNIX进程处于等待状态，以防用户想要恢复你的应用程序。这与将最近访问的文件缓存在内存中的现代操作系统没有什么不同。退出Windows程序后，它需要的最有可能的资源仍在内存中，等待被其他资源替换，因为它们现在不再需要了。Android是一回事。

我真的看不出你的问题。

如果您无法理解如何使您的数据/连接（以及您的“应用程序”）持久化，那么您将无法使用Android做您“需要”做的事情。

那些下载这些可爱的小应用程序杀手的人通常会发现它们无助于电池寿命或内存使用，但会阻碍操作系统有效地管理内存……

http://android-developers.blogspot.com/2010/04/multitasking-android-way.html

我希望事情会随着时间的推移而改变。如果应用程序进程被操作系统正确沙盒化，用户应该能够杀死应用程序或进程。有一种观点认为应用程序应该编写得完美，否则用户将只使用遵循所有SDK建议的应用程序。我认为这是一个很高的要求。

没有退出功能的应用程序开发人员杀死自己的应用程序是非常糟糕的设计。

我的应用程序需要允许用户在运行时动态更改数据，用户需要重新启动我的应用程序才能产生更改效果，但Android不允许我的应用程序自行重新启动。Android操作系统有一个非常糟糕的设计应用程序生命周期。

这是一个有趣而有见地的讨论，有这么多专家贡献。我觉得这篇文章应该从Android开发主网站中循环回来，因为它确实围绕Android操作系统的核心设计之一。

我也想在这里加上我的两分钱。

到目前为止，我对Android处理生命周期事件的方式印象深刻，将类似Web的体验概念引入本机应用程序。

话虽如此，我仍然认为应该有一个退出按钮。为什么？…不是为了我或Ted或这里的任何技术大师，而是为了满足最终用户的需求。

虽然我不是Windows的忠实粉丝，但很久以前他们引入了一个大多数最终用户都习惯的概念（一个X按钮）……“我想在'我'想要的时候退出运行小部件”。

这并不意味着有人（操作系统、开发人员？）会自行决定……它只是意味着“我习惯的Red X按钮在哪里”。我的动作应该类似于“按下按钮结束呼叫”、“按下按钮关闭设备”等等……这是一种感知。它本身带来了一种满意度，我的动作确实达到了目的。

即使开发人员可以使用此处给出的建议来欺骗这种行为，但感知仍然存在，即应用程序应该完全停止运行（现在），由最终用户根据需要提供独立，可信和中立的源（OS）。

有一个（相对）简单的设计可以让你绕过“退出”难题。让你的应用程序有一个只是一个空白屏幕的“基本”状态（活动）。在活动的第一个onCreate上，你可以启动应用程序主要功能所在的另一个活动。然后，“退出”可以通过完成[]执行第二个活动并返回到空白屏幕的底部来完成。操作系统可以随时将这个空白屏幕保留在内存中…

本质上，因为你不能退出操作系统，你只是变成了一个自我创造的虚无。

这场辩论归结为一个古老的问题，即开发人员是否最了解还是用户是否最了解。所有人为因素领域的专业设计师每天都在与此斗争。

泰德指出，市场上下载最多的应用程序之一是“应用程序杀手”。当人们退出应用程序时，他们会获得一些额外的血清素。他们习惯了台式机/笔记本电脑。它让事情快速发展。它让处理器保持凉爽，风扇不打开。它消耗更少的能量。

当你认为移动设备是一艘小得多的船时，那么你就会特别欣赏他们“扔掉你不再需要的东西”的动机。现在Android的开发人员认为操作系统最清楚，退出应用程序是过时的。我全心全意地支持这一点。

然而，我也相信你不应该让用户感到沮丧，即使这种沮丧是出于他们自己的无知。正因为如此，我得出结论，拥有“退出”选项是一个好的设计，即使它主要是一个安慰剂按钮，只不过是关闭一个视图。

我花了更长的时间来阅读这个问答，而不是实际实现一个半合适的Android应用程序生命周期。

这是一个GPS应用程序，可以轮询点，并使用线程每隔几秒钟将当前位置发送到网络服务……在Ted的情况下，这可能是每5分钟轮询一次更新，然后onStop可以简单地启动Ted所关心的更新活动，如果找到一个（异步Ted，不要像Windows程序员那样编码，否则你的程序将像Windows程序一样运行…呃，这并不难）。

我在onCreate中做了一些初始代码来设置活动生命周期，包括checkUpdate.start();：

…

@Overridepublic void onStart() {super.onStart();isRemote = true;checkUpdate.resume();
locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 2000, 0, luh);}
@Overridepublic void onPause() {isRemote = false;checkUpdate.suspend();locationManager.removeUpdates(luh);super.onStop();}

这段代码可能完全错误，但它有效。这是我的第一个Android应用程序之一。

瞧，一个在后台时不消耗CPU的应用程序，但可以立即重新打开，因为它在RAM中（尽管不像Android生命周期那样持有RAM）……一个应用程序总是准备好的，它是一部手机，伙计们/女孩们。如果一个应用程序要耗尽所有的RAM并且不能被操作系统关闭，那么它可能会停止响铃=P这就是为什么操作系统需要能够在后台关闭你的应用程序（如果你的应用程序不是资源占用者，它不会被关闭），所以让我们编写更好的应用程序。

Linux内核有一个名为内存不足的杀手的特性（如上所述，策略在用户空间级别是可配置的，内核不是最佳的，但绝不是不必要的）。

它被Android大量使用：

• OOM杀手不适合用户空间

• Android Notes（OOM杀手信息-在那里你可以在Android上配置OOM功能）

• Android移植到真实目标

一些用户空间应用程序可用于协助这些杀死应用程序，例如：

• 自动杀手/配置Android的内部任务杀手

要在任何时候关闭应用程序，请在Intent中使用FLAG_ACTIVITY_CLEAR_TOP标志，然后使用system.exit();

或者也有类似的方式，但是没有system.exit()的时候要退出调用这个方法：

public void exit() {startActivity(new Intent(this, HomeActivity.class).setFlags(Intent.FLAG_ACTIVITY_NEW_TASK | IntentCompat.FLAG_ACTIVITY_CLEAR_TASK).putExtra(EXIT_FLAG, true));}

在您的HomeActivity.onCreate()中添加以下代码

protected void onCreate(Bundle savedInstanceState) {if (getIntent().getBooleanExtra(EXIT_FLAG, false)) {if ((getIntent().getFlags() & Intent.FLAG_ACTIVITY_LAUNCHED_FROM_HISTORY) == 0) {finish();}}......................

这将在不破坏Android生命周期的情况下工作。

使用此代码：

Intent i = new Intent();i.setAction(Intent.ACTION_MAIN);i.addCategory(Intent.CATEGORY_HOME);ListActivity.this.startActivity(i);finish();

当我在Android中构思一个应用程序时，我是这样看待的：

• 您正在使用您的应用程序
• 电话响了
• 你接电话
• 在通话结束时，你回到你的应用程序在同一个地方

为此，您只需要手机的返回按钮或首页按钮（短按或长按）和通知栏。

当我退出我的应用程序时，我只使用返回按钮，直到我退出它或首页按钮。

我认为大多数应用程序都是这样构思的。但是如果我需要某种会话或连接，我用登录/注销按钮和通知（标题栏或其他任何东西）向用户明确表示。这是一种与纯粹的“退出”风格应用程序截然不同的风格。

在PC上，你有一个多GUI桌面，在Android上，你显然有多个任务，但你一次只显示一个应用程序（我这里不考虑小部件^^）。在手机上，任何时候，你都可以收到比你正在做的事情更重要的通知。

因此，应用程序的整个概念依赖于不同的“进入应用程序-工作-退出应用程序”。

你显然已经在完成（）命令中找到了你想要的答案。这不会从内存中删除你的应用程序，但Android会在需要资源时这样做，所以你不会明确这样做没有任何区别。

我只想补充一点，为了获得应用程序退出通常具有的全部效果，你需要将应用程序的状态重置为它在设备启动后第一次运行时的正常状态，就在你所有的活动调用完（）之前。这样，如果用户再次选择你的应用程序，它将看起来是“新鲜”运行的，没有从模拟“退出”之前的点留下任何状态。

如果有一些特殊操作应该只在“退出”时发生，例如保存用户的工作或其他什么，您也可以在上述例程的重新初始化部分之前执行它们。

这种方法允许您实现拥有“退出”命令的目标，而不违反Android的理念，即将操作系统资源的管理（包括关闭应用程序）交给操作系统。

就我个人而言，我不会使用这种方法，因为Android用户希望应用在他们重新访问时能保持其连续性，所以他们不习惯“退出”应用的方式。我会支持一个“清除”函数，用户可以调用该函数将应用重置为默认的初始状态，而无需在此过程中“离开”它。

一个例外是当用户点击后退按钮足够次数以导致应用程序关闭时。在这种情况下，用户不期望该状态已被保存（如果应用程序中存在未保存的状态，那么你，作为开发人员，应该有代码处理后退按钮，该按钮检测未保存的数据，并提示用户将其保存到SharedPre的设置或文件，或其他一些非易失性介质）。

关于system.exit（0）：

如果你决定使用system.exit（0）以粗鲁的结局关闭你的应用程序（例如，由于最终的后退按钮按下），那么我会警告你，虽然对我来说这“有效”，在某些情况下，这是我能够关闭应用程序而不留下任何痕迹的唯一方法，当你使用这种方法时，Jelly Bean中会出现一个小故障。

具体来说，如果你使用最近的应用列表打开你的应用，然后使用后退按钮关闭应用（通过system.exit（0）实现关闭），最近的应用列表将再次变得可见，因为它永远不会被关闭。如果你然后点击该列表中的应用条目，从同一个已经打开的最近的应用列表中运行它第二次，则不会有响应。

我怀疑造成这种情况的原因是最近的应用程序列表保留了对您的应用程序的引用，由于您使用system.exit（0）关闭了应用程序，该应用程序已变得不起作用。

这本身不是一个大问题，因为很少有人会从最近的应用程序打开一个应用程序，然后退出它，然后立即从同一个打开的最近的应用程序列表中再次打开它。如果他们点击home按钮，然后重新开放最近的应用程序列表，你的应用程序的条目将在那里，它将是完全正常的。但是我认为这表明使用system.exit（0）会干扰你的应用程序和操作系统之间的正常通信，这表明使用这种方法可能会有其他更严重，可能更微妙的后果。

首先，从不从不使用System.exit（0）。这就像让一个人睡觉，打他的头！

第二：我面临这个问题。在分享我的解决方案之前，我想分享我的想法。

我认为“退出按钮”是愚蠢的。真的非常非常愚蠢。我认为要求为您的应用程序设置退出按钮的用户（消费者）也很愚蠢。他们不了解操作系统是如何工作的以及如何管理资源（它做得很好）。

我认为，如果你写了一段好的代码，在正确的时间和条件下做正确的事情（更新、保存和推送），并使用正确的东西（服务和接收器），它会工作得很好，没有人会抱怨。

但要做到这一点，你必须学习和学习Android上的工作原理。无论如何，这是我为用户提供“退出按钮”的解决方案。

我创建了一个选项菜单，在每个活动中始终可见（我有一个超级活动可以做到这一点）。

当用户点击该按钮时，会发生以下情况：

Intent intent = new Intent(this, DashBoardActivity.class);intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
SharedPreferences settings = getSharedPreferences(getString(PREF_ID), Context.MODE_PRIVATE);SharedPreferences.Editor editor = settings.edit();editor.putBoolean(FORCE_EXIT_APPLICATION, true);
// Commit the edits!editor.commit();startActivity(intent);finish();

所以我保存了我想杀死我的应用程序的共享偏好，然后我启动了一个Intent。请查看这些标志；这些将清除我所有的后栈调用我的仪表板活动，这是我的“家”活动。

所以在我的仪表板活动中，我在onResume中运行这个方法：

private void checkIfForceKill() {
// CHECK IF I NEED TO KILL THE APP
// Restore preferencesSharedPreferences settings = getSharedPreferences(getString(MXMSettingHolder.PREF_ID), Context.MODE_PRIVATE);boolean forceKill = settings.getBoolean(MusicSinglePaneActivity.FORCE_EXIT_APPLICATION, false);
if (forceKill) {
//CLEAR THE FORCE_EXIT SETTINGSSharedPreferences.Editor editor = settings.edit();editor.putBoolean(FORCE_EXIT_APPLICATION, false);
// Commit the edits!editor.commit();
//HERE STOP ALL YOUR SERVICESfinish();}}

它会工作得很好。

我唯一不明白为什么会发生这种情况的是，当我完成最后一次操作时（我已经检查过了：它遵循了onP暂停→onStop→onDestroy的所有正确流程），应用程序仍然在最近的活动上（但它是空白的）。

看起来最新的意图（已经启动了Dashboard活动）仍在系统中。

我必须挖掘更多，以便也删除它。

博客文章何时在Android应用中包含退出按钮（提示：从不）解释得比我好得多，远。我希望每个Android开发人员都已经阅读过它。

摘录：

根据我的经验，[用户]真正想要的是：一种明确的方式来保证应用程序将停止消耗资源（电池，CPU周期，数据搬迁等）。

许多用户认为退出按钮实现了这一要求并要求添加它。开发人员，希望取悦他们的用户，#36825；加一个，不久之后，两个都失败了。

• 在大多数情况下，退出按钮只是调用Activity.finish()。这相当于完全点击后退按钮。完全正确。服务继续运行，轮询继续发生。用户可能认为他们已经杀死了应用程序，但他们没有，而且很快他们会更生气。
• 退出行为现在是模棱两可的。你的退出按钮应该关闭活动，还是也应该停止所有关联的服务、接收器和警报？返回应该怎么做？如果他们击中首页会发生什么？如果你的应用程序有小部件会发生什么？退出按钮是否也应该停止更新？

解决方案是使后退按钮的行为符合您的期望更好的是，只要停止消耗资源该应用程序不可见。