Android 退出申请是否令人不悦？

Is quitting an application frowned upon?

提问by Ted

Moving on in my attempt to learn Android, I just read the following:

在我尝试学习 Android 的过程中继续前进，我只是阅读了以下内容：

Question: Does the user have a choice to kill the application unless we put a menu option in to kill it? If no such option exists, how does the user terminate the application?

Answer: (Romain Guy): The user doesn't, the system handles this automatically. That's what the activity lifecycle (especially onPause/onStop/onDestroy) is for. No matter what you do, do not put a "quit" or "exit" application button. It is useless with Android's application model. This is also contrary to how core applications work.

问题：用户是否可以选择终止应用程序，除非我们在其中添加一个菜单选项来终止它？如果不存在这样的选项，用户如何终止应用程序？

答：（Romain Guy）：用户没有，系统会自动处理。这就是活动生命周期（尤其是 onPause/onStop/onDestroy）的用途。无论您做什么，都不要放置“退出”或“退出”应用程序按钮。对于 Android 的应用程序模型，它是无用的。这也与核心应用程序的工作方式相反。

Hehe, for every step I take in the Android world I run into some sort of problem =(

呵呵，我在Android世界中每走一步都会遇到一些问题=（

Apparently, you cannot quit an application in Android (but the Android system can very well totally destroy your app whenever it feels like it). What's up with that? I am starting to think that it's impossible to write an app that functions as a "normal app" - that the user can quit the app when he/she decides to do so. That is not something that should be relied upon the OS to do.

显然，您无法退出 Android 中的应用程序（但 Android 系统可以在任何时候完全摧毁您的应用程序）。那是怎么回事？我开始认为编写一个功能为“普通应用程序”的应用程序是不可能的——用户可以在他/她决定退出时退出应用程序。这不是应该依赖操作系统来做的事情。

The application I am trying to create is not an application for the Android Market. It is not an application for "wide use" by the general public, it is a business app that is going to be used in a very narrow business field.

我尝试创建的应用程序不是 Android Market 的应用程序。它不是一般大众“广泛使用”的应用程序，它是一个将在非常狭窄的业务领域中使用的业务应用程序。

I was actually really looking forward to developing for the Android platform, since it addresses a lot of issues that exist in Windows Mobile and .NET. However, the last week has been somewhat of a turnoff for me... I hope I don't have to abandon Android, but it doesn't look very good right now =(

我实际上非常期待为 Android 平台开发，因为它解决了 Windows Mobile 和 .NET 中存在的许多问题。然而，上周对我来说有点令人失望......我希望我不必放弃Android，但现在看起来不太好=（

Is there a way for me to reallyquit the application?

有没有办法让我真正退出应用程序？

回答by CommonsWare

This will eventually get to your question, but I first want to address a number of issues you raise in your various comments to the various answers already given at the time of this writing. I have no intention of changing your mind -- rather, these are here for others who come to read this post in the future.

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

The point is that I cannot allow for Android to determine when my app is going to be terminated. that must be the choice of the user.

关键是我不能让 Android 确定我的应用程序何时终止。这必须是用户的选择。

Millions of people are perfectly happy with the model where the environment closes up the application as needed. Those users simply don't think about "terminating" the Android app, any more than they think about "terminating" a Web page or "terminating" a thermostat.

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

iPhone users are much the same way, in that pressing the iPhone button does not necessarily "feel" like the app was terminated, since many iPhone apps pick up where the user left off, even if the app really was shut down (since iPhone only allows one third-party app at a time, at present).

iPhone 用户的情况大致相同，因为按下 iPhone 按钮不一定“感觉”像应用程序被终止了，因为许多 iPhone 应用程序从用户离开的地方开始，即使应用程序真的被关闭了（因为只有 iPhone目前一次允许一个第三方应用程序）。

As I said above, there is a lot of things going on in my app (data being PUSHed to the device, lists with tasks that always should be there, etc.).

正如我上面所说的，我的应用程序中有很多事情正在发生（数据被推送到设备，列出应该始终存在的任务等）。

I don't know what "lists with tasks that always should be there" means, but the "data being PUSHed to the device" is a pleasant fiction and should not be done by an activity in any case. Use a scheduled task (via AlarmManager) to update your data for maximum reliability.

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

Our users log in and can't be doing that every time they get a phone call and Android decides to kill the app.

我们的用户每次接到电话时都无法登录，而 Android 决定终止该应用程序。

There are many iPhone and Android applications that deal with this. Usually, it is because they hold onto logon credentials, rather than forcing users to log in every time manually.

有许多 iPhone 和 Android 应用程序可以解决这个问题。通常，这是因为他们持有登录凭据，而不是每次都强制用户手动登录。

For example, we want to check updates when exiting the application

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

That is a mistake on any operating system. For all you know, the reason your application is being "exited" is because the OS is shutting down, and then your update process will fail mid-stream. Generally, that's not a good thing. Either check updates on start or check updates totally asynchronously (e.g., via a scheduled task), never on exit.

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

Some comments suggest that hitting the back button does not kill the app at all (see link in my question above).

一些评论表明点击后退按钮根本不会杀死应用程序（请参阅上面我的问题中的链接）。

Pressing the BACK button does not "kill the app". It finishes the activity that was on-screen when the user pressed the BACK button.

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

It should only terminate when the users wants to terminate it - never ever any other way. If you can't write apps that behave like that in Android, then I think that Android can't be used for writing real apps =(

它应该只在用户想要终止它时终止 - 绝不会以任何其他方式终止。如果你不能写出像 Android 那样的应用程序，那么我认为 Android 不能用于编写真正的应用程序 =(

Then neither can Web applications. Or WebOS, if I understand their model correctly (haven't had a chance to play with one yet). In all of those, users don't "terminate" anything -- they just leave. iPhone is a bit different, in that it only presently allows one thing to run at a time (with a few exceptions), and so the act of leaving implies a fairly immediate termination of the app.

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

Is there a way for me to really quit the application?

有没有办法让我真正退出应用程序？

As everybody else told you, users (via BACK) or your code (via finish()) can close up your currently-running activity. Users generally don't need anything else, for properly-written applications, any more than they need a "quit" option for using Web applications.

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

---

---

No two application environments are the same, by definition. This means that you can see trends in environments as new ones arise and others get buried.

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

For example, there is a growing movement to try to eliminate the notion of the "file". Most Web applications don't force users to think of files. iPhone apps typically don't force users to think of files. Android apps generally don't force users to think of files. And so on.

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

Similarly, there is a growing movement to try to eliminate the notion of "terminating" an app. Most Web applications don't force the user to log out, but rather implicitly log the user out after a period of inactivity. Same thing with Android, and to a lesser extent, iPhone (and possibly WebOS).

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

This requires more emphasis on application design, focusing on business goals and not sticking with an implementation model tied to a previous application environment. Developers who lack the time or inclination to do this will get frustrated with newer environments that break their existing mental model. This is not the fault of either environment, any more than it is the fault of a mountain for storms flowing around it rather than through it.

这需要更加重视应用程序设计，专注于业务目标，而不是坚持与以前的应用程序环境相关的实现模型。没有时间或不愿意这样做的开发人员会对打破他们现有思维模型的新环境感到沮丧。这不是任何一种环境的错，更不是暴风雨在山上流动而不是通过它的山的错。

For example, some development environments, like Hypercardand Smalltalk, had the application and the development tools co-mingled in one setup. This concept did not catch on much, outside of language extensions to apps (e.g., VBAin Excel, Lisp in AutoCAD). Developers who came up with mental models that presumed the existence of development tools in the app itself, therefore, either had to change their model or limit themselves to environments where their model would hold true.

例如，一些开发环境，如Hypercard和 Smalltalk，将应用程序和开发工具混合在一个设置中。这个概念没赶上了，到应用程序语言扩展的外部（例如，VBA在Excel中，Lisp语言在AutoCAD）。因此，提出假设应用程序本身存在开发工具的心智模型的开发人员要么不得不改变他们的模型，要么将自己限制在他们的模型适用的环境中。

So, when you write:

所以，当你写：

Along with other messy things I discovered, I think that developing our app for Android is not going to happen.

连同我发现的其他混乱的事情，我认为为 Android 开发我们的应用程序是不会发生的。

That would appear to be for the best, for you, for right now. Similarly, I would counsel you against attempting to port your application to the Web, since some of the same problems you have reported with Android you will find in Web applications as well (e.g., no "termination"). Or, conversely, someday if you doport your app to the Web, you may find that the Web application's flow may be a better match for Android, and you can revisit an Android port at that time.

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

回答by Neil Traft

I'd just like to add a correction here for the future readers of this thread. This particular nuance has escaped my understanding for a long time so I want to make sure none of you make the same mistakes:

我只想在这里为该线程的未来读者添加更正。很长一段时间以来，我一直无法理解这种特殊的细微差别，所以我想确保你们中没有人犯同样的错误：

System.exit()does not kill your app if you have more than one activity on the stack.What actually happens is that the process is killed and immediately restartedwith one fewer activity on the stack. This is also what happens when your app is killed by the Force Close dialog, or even when you try to kill the process from DDMS. This is a fact that is entirely undocumented, to my knowledge.

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

The short answer is, if you want to exit your application, you've got to keep track of all activities in your stack and finish()ALL of them when the user wants to exit (and no, there is no way to iterate through the Activity stack, so you have to manage all of this yourself). Even this does not actually kill the process or any dangling references you may have. It simply finishes the activities. Also, I'm not sure whether Process.killProcess(Process.myPid())works any better; I haven't tested it.

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

If, on the other hand, it is okay for you to have activities remaining in your stack, there is another method which makes things super easy for you: Activity.moveTaskToBack(true)will simply background your process and show the home screen.

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

The long answer involves explanation of the philosophy behind this behavior. The philosophy is born out of a number of assumptions:

长答案涉及对这种行为背后的哲学的解释。该哲学源于许多假设：

1. First of all, this only happens when your app is in the foreground. If it is in the background the process will terminate just fine. However, if it is in the foreground, the OS assumes that the user wants to keep doing whatever he/she was doing. (If you are trying to kill the process from DDMS, you should hit the home button first, and then kill it)
2. It also assumes that each activity is independent of all the other activities. This is often true, for example in the case that your app launches the Browser Activity, which is entirely separate and was not written by you. The Browser Activity may or may not be created on the same Task, depending on its manifest attributes.
3. It assumes that each of your activities is completely self-reliant and can be killed/restored in a moment's notice. (I rather dislike this particular assumption, since my app has many activities which rely on a large amount of cached data, too large to be efficiently serialized during onSaveInstanceState, but whaddya gonna do?) For most well-written Android apps this should be true, since you never know when your app is going to be killed off in the background.
4. The final factor is not so much an assumption, but rather a limitation of the OS: killing the app explicitly is the same as the app crashing, and also the same as Android killing the app to reclaim memory.This culminates in our coup de grace: since Android can't tell if the app exited or crashed or was killed in the background, it assumes the user wants to return where they left off, and so the ActivityManager restarts the process.

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

When you think about it, this is appropriate for the platform. First, this is exactly what happens when the process is killed in the background and the user comes back to it, so it needs to be restarted where it left off. Second, this is what happens when the app crashes and presents the dreaded Force Close dialog.

仔细想想，这对平台来说是合适的。首先，这正是当进程在后台被杀死并且用户返回它时发生的情况，因此需要从它停止的地方重新启动。其次，这是当应用程序崩溃并显示可怕的强制关闭对话框时发生的情况。

Say I want my users to be able to take a picture and upload it. I launch the Camera Activity from my activity, and ask it to return an image. The Camera is pushed onto the top of my current Task (rather than being created in its own Task). If the Camera has an error and it crashes, should that result in the whole app crashing? From the standpoint of the user, only the Camera failed, and they should be returned to their previous activity. So it just restarts the process with all the same Activities in the stack, minus the Camera. Since your Activities shouldbe designed so that they can be killed and restored at the drop of a hat, this shouldn't be a problem. Unfortunately, not all apps can be designed that way, so it isa problem for many of us, no matter what Romain Guy or anyone else tells you. So, we need to use workarounds.

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

So, my closing advice:

所以，我的结束建议：

• Don't try to kill the process. Either call finish()on all activities or call moveTaskToBack(true).
• If your process crashes or gets killed, and if, like me, you need the data that was in memory which is now lost, you'll need to return to the root activity. To do this, you should call startActivity()with an Intent that contains the Intent.FLAG_ACTIVITY_CLEAR_TOPflag.
• If you want to kill your app from the Eclipse DDMS perspective, it had better not be in the foreground, or it will restart itself. You should press the Home button first, and thenkill the process.

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

回答by androidworkz

All of my applications have quit buttons... and I quite frequently get positive comments from users because of it. I don't care if the platform was designed in a fashion that applications shouldn't need them. Saying "don't put them there" is kind of ridiculous. If the user wants to quit... I provide them the access to do exactly that. I don't think it reduces how Android operates at all and seems like a good practice. I understand the life cycle... and my observation has been that Android doesn't do a good job at handling it.... and that is a basic fact.

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

回答by Eric

Stop thinking of your application as a monolithic application. It is a set of UI screens that the user can interact with your "application", and "functions" provided via Android services.

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

Not knowing what your mysterious app "does" is not really important. Let's assume it tunnels into some super secure corporate intranet, performing some monitoring or interaction and stays logged in until the user "quits the application". Because your IT department commands it, users must be very conscious of when they are IN or OUT of the intranet. Hence your mindset of it being important for users to "quit".

不知道你的神秘应用“做什么”并不重要。让我们假设它通过隧道进入一些超级安全的企业内部网，执行一些监控或交互并保持登录状态，直到用户“退出应用程序”。因为您的 IT 部门命令它，所以用户必须非常注意他们何时进入或离开 Intranet。因此，您认为用户“退出”很重要。

This is simple. Make a service that puts an ongoing notification in the notification bar saying "I'm in the intranet, or I am running". Have that service perform all the functionality that you need for your application. Have activities that bind to that service to allow your users to access the bits of UI they need to interact with your "application". And have an Android Menu -> Quit (or logout, or whatever) button that tells the service to quit, then closes the activity itself.

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

This is, for all intents and purposes exactly what you say you want. Done the Android way. Look at Google Talk or Google Maps Navigation for examples of this "exit" is possible mentality. The only difference is that pressing back button out of your activity might leave your UNIX process lying in wait just in case the user wants to revive your application. This is really no different than a modern operating system that caches recently accessed files in memory. After you quit your windows program, most likely resources that it needed are still in memory, waiting to be replaced by other resources as they are loaded now that they are no longer needed. Android is the same thing.

出于所有意图和目的，这正是您所说的想要的。以安卓方式完成。查看 Google Talk 或 Google Maps Navigation 的示例，了解这种“退出”是可能的心态。唯一的区别是，在您的活动中按下后退按钮可能会使您的 UNIX 进程处于等待状态，以防万一用户想要恢复您的应用程序。这与将最近访问的文件缓存在内存中的现代操作系统没有什么不同。退出 Windows 程序后，它需要的资源很可能仍在内存中，等待被其他资源替换，因为它们现在不再需要被加载。安卓也是一样。

I really don't see your problem.

我真的没有看到你的问题。

回答by Paul

This is an interesting and insightful discussion with so many experts contributing. I feel this post should be looped back from within the Android development main website, because it does revolve around one of the core designs of the Android OS.

这是一次有趣且富有洞察力的讨论，有这么多专家参与其中。我觉得这篇文章应该从 Android 开发主网站内部循环回来，因为它确实围绕着 Android 操作系统的核心设计之一。

I would also like to add my two cents here.

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

So far I have been impressed with Android's way of handling lifecycle events, bringing the concept of a web-like experience to native apps.

到目前为止，Android 处理生命周期事件的方式给我留下了深刻的印象，它将类似网络的体验的概念引入到本机应用程序中。

Having said that I still believe that there should be a Quitbutton. Why? ... not for me or Ted or any of the tech gurus here, but for the sole purpose of meeting an end user demand.

话虽如此，我仍然认为应该有一个Quit按钮。为什么？... 不是为了我、Ted 或这​​里的任何技术专家，而是为了满足最终用户的需求。

Though I am not a big fan of Windows, but long back they introduced a concept that most end users are used to (an X button) ... "I want to quit running a widget when 'I' want to".

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

That does not mean someone (OS, developer?) will take care of that at its/his/her own discretion... it simply means "where is my Red X button that I am used to". My action should be analogous to 'end a call on pressing of a button', 'turn off the device by pressing a button', and so on and so forth ... it's a perception. It brings a satisfaction per se that my action indeed achieve its purpose.

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

Even though a developer can spoof this behavior using suggestions given here, the perception still remains i.e. an application should completely cease to function (now), by an independent, trusted and neutral source (OS) on demand from the end user.

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

回答by Christopher Orr

You canquit, either by pressing the Backbutton or by calling finish()in your Activity. Just call finish()from a MenuItemif you want to explicitly kill it off.

您可以通过按下Back按钮或调用finish()您的Activity. 如果你想明确地杀死它，只需finish()从 a调用MenuItem。

Romain isn't saying it can't be done, just that it's pointless — users don't need to care about quitting or saving their work or whatever, as the way the application lifecycle works encourages you to write smart software that automatically saves and restores its state no matter what happens.

Romain 并不是说​​它不能完成，只是它毫无意义——用户不需要关心退出或保存他们的工作或其他什么，因为应用程序生命周期的工作方式鼓励你编写智能软件，自动保存和保存。无论发生什么都恢复其状态。

回答by Chad Hedgcock

This debate boils down to the age-old question of whether the developers know best or whether the user knows best. Professional designers in all areas of human factors struggle with this every day.

这场辩论归结为一个古老的问题，即是开发人员最了解还是用户最了解。人为因素各个领域的专业设计师每天都在为此而苦苦挣扎。

Ted has made a point in that one of the most downloaded apps on the Market is the 'App Killer'. People get a bit of extra serotonin when they quit applications. They're used to it with a desktop/laptop. It keeps things moving fast. It keeps the processor cool and the fan from turning on. It uses less power.

Ted 指出，市场上下载次数最多的应用程序之一是“应用杀手”。人们在退出应用程序时会获得一些额外的血清素。他们已经习惯了台式机/笔记本电脑。它使事情快速发展。它可以保持处理器冷却和风扇不打开。它使用较少的功率。

When you consider that a mobile device is a much smaller ship, then you can especially appreciate their incentive to 'throw overboard what you no longer need'. Now the developers of Android have reasoned that the OS knows best and that quitting an app is antique. I wholeheartedly support this.

当您认为移动设备是一艘小得多的船时，您会特别欣赏他们“将不再需要的东西扔到海里”的动机。现在，Android 的开发人员已经推断操作系统最了解并且退出应用程序是过时的。我全心全意地支持这一点。

However, I also believe that you should not frustrate the user, even if that frustration is borne out of their own ignorance. Because of that, I conclude that having a 'Quit' option is good design, even if it is mostly a placebo button that does nothing more than close a View.

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

回答by Aaron

Ted, what you are trying to accomplish can be done, perhaps just not how you are thinking of it right now.

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

I suggest you read up on Activities and Services. Stop using the term "app" and start referring to the components, i.e. Activity, Service. I think you just need to learn more about the Android platform; it is a change in mindset from a standard PC app. The fact that none of your posts have had the word "Activity" (short of a FAQ quote, i.e. not your words) in them tells me you need to read some more.

我建议您阅读活动和服务。停止使用术语“应用程序”并开始指代组件，即活动、服务。我认为你只需要了解更多关于 Android 平台的信息；这是对标准 PC 应用程序思维方式的改变。事实上，你的帖子都没有“活动”这个词（缺少常见问题引用，即不是你的话），这告诉我你需要多读一些。

回答by Dheeraj Vepakomma

Blog post When to Include an Exit Button in Android Apps (Hint: Never)explains it far, farbetter than I can. I wish every Android developer has read it already.

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

Excerpts:

摘录：

In my experience what [the users] really want is: An unambiguous way to guarantee that an app will stop consuming resources (battery, CPU cycles, data transfer, etc.).

Many users perceive that an exit button implements this requirement and ask for it to be added. Developers, looking to please their users, obligingly add one. Shortly thereafter they both fail.

• In most cases the exit button simply calls Activity.finish(). This is exactlyequivalent to hitting the back button. Exactly.Services keep running and polling keeps happening. Users may think they've killed the app but they haven't, and soon they'll be even more annoyed.
• Exit behavior is now ambiguous. Should your exit button just close the Activity, or should it also stop all associated Services, Receivers, and Alarms? What should Backdo? What happens if they hit Homeinstead? What happens if your app has a widget? Should the exit button stop that from updating too?

The solution is to make the back button behave as you'd expect the exit button to. Better yet, simply stop consuming resources whenever the app isn't visible.

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

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

• 在大多数情况下，退出按钮只是调用Activity.finish(). 这完全等同于点击后退按钮。 确切地。服务不断运行，轮询不断发生。用户可能认为他们已经杀死了应用程序，但他们并没有，很快他们就会更加恼火。
• 退出行为现在是模棱两可的。您的退出按钮应该只是关闭活动，还是应该停止所有关联的服务、接收器和警报？应该Back怎么办？如果他们击中，会发生什么Home？如果您的应用有小部件会怎样？退出按钮也应该停止更新吗？

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

Go ahead and read the complete article.

继续阅读完整的文章。

回答by Jesse Gordon

Answer: (Romain Guy): The user doesn't, the system handles this automatically. That's what the activity lifecycle (especially onPause/onStop/onDestroy) is for. No matter what you do, do not put a "quit" or "exit" application button. It is useless with Android's application model. This is also contrary to how core applications work.

答：（Romain Guy）：用户没有，系统会自动处理。这就是活动生命周期（尤其是 onPause/onStop/onDestroy）的用途。无论您做什么，都不要放置“退出”或“退出”应用程序按钮。对于 Android 的应用程序模型，它是无用的。这也与核心应用程序的工作方式相反。

1: Totally exiting an application may be generally unmandatory, but it is not useless. What if windows had no exit option? System would be doggy slow as memory was full and the OS had to guess at which programs you were done with. I don't care what Romain Guy or even Larry Page and Sergey Brin say - these are unquestionable facts: Systems run slower when they have to kill tasks to get their memory before a new app can be launched. You just can't tell me that it doesn't take time to kill an app! Even the light from distant stars take time... There issome use in allowing the user to fully close apps.

1：完全退出应用程序通常可能是非强制性的，但并非没有用。如果 Windows 没有退出选项怎么办？由于内存已满，系统会变得很慢，操作系统不得不猜测您完成了哪些程序。我不在乎 Romain Guy 甚至 Larry Page 和 Sergey Brin 怎么说——这些都是毋庸置疑的事实：当系统在启动新应用程序之前必须终止任务以获取内存时，它们的运行速度会变慢。你不能告诉我杀死一个应用程序不需要时间！甚至来自遥远恒星的光需要时间......还有就是在允许用户完全关闭一些应用程序使用。

2: Contrary to how core applications work? What's that supposed to mean? When I'm done running an app for now, it is no longer doing any work...It's just waiting to be killed by the OS when its memory is needed.

2：与核心应用程序的工作方式相反？那是什么意思？当我现在运行完一个应用程序时，它不再做任何工作......它只是在需要它的内存时等待被操作系统杀死。

In summary, there is a distinct difference between minimizing and exiting, and neither pinch hits well for the other. Do we leave a screwdriver in every screw? Or a key in every door? Do we leave all of our appliances on high until the breaker blows and we need to turn on another appliance? Do we leave the dish washer full of dishes, and only take out enough each time to make room for some new dirty ones? Do we leave all the cars running in the driveway until -- oh never mind.

总而言之，最小化和退出之间存在明显区别，并且两者都不适合另一个。我们是否在每个螺丝上都留了一把螺丝刀？还是每扇门都有钥匙？我们是否将所有电器都保持在高电平直到断路器熔断并且我们需要打开另一台电器？我们是否让洗碗机装满了盘子，每次只拿出足够的空间来为一些新的脏盘子腾出空间？我们是否让所有的汽车都在车道上行驶，直到 - 哦，没关系。

If the user wants to minimize an app, then the best thing is to minimize it. If a user wants to exit an app, then by all means it is best to exit.

如果用户想最小化一个应用程序，那么最好的办法就是最小化它。如果用户想退出应用程序，那么无论如何最好退出。

Is it frowned on? That's Android's view - they frown on it. And many many independent rookie Android developers frown on it.

是皱眉了吗？这是 Android 的观点——他们对此不以为然。许多独立的 Android 新手开发者对此不屑一顾。

But when it comes right down to it, there is good coding and bad coding. There is good program flow models and there are bad program flow models.

但归根结底，有好的编码和坏的编码。有好的程序流模型，也有坏的程序流模型。

Leaving programs in memory when the user knows they are done with them simply is not good program flow. It serves absolutely no purpose whatsoever, and it slows things down when launching new apps or when running apps allocate more memory.

当用户知道他们已经完成了程序时，将程序留在内存中并不是好的程序流程。它绝对没有任何用处，并且在启动新应用程序或运行应用程序时分配更多内存时会减慢速度。

It is sort of like your car: There are times when you leave it running, like stopping at a stop light, or perhaps the fast food drive through, or stopping at the ATM. But there are other situations where you do want to shut it off - like when you get to work, or the grocery store or even home.

它有点像你的汽车：有时你让它继续运行，比如在红绿灯处停下，或者快餐车驶过，或者在自动取款机前停下。但是在其他情况下，您确实希望将其关闭 - 例如当您上班、去杂货店甚至回家时。

Similarly, if you're playing a game and the phone rings, yes. Pause the game and keep it running. But if the user is done with the game for a while, then by all means let them exit.

同样，如果您正在玩游戏并且电话响了，是的。暂停游戏并保持运行。但是如果用户玩了一段时间游戏，那么一定要让他们退出。

The exit button on some applications should be more out in front than others. Games, for example, or programs where the user is likely to want to fully exit, should have an obvious exit. Other programs, like, perhaps, email programs, where exiting is an unlikely desire (so that it can keep checking for email) -- these programs should not waste prime control input screen space with an exit option, but for good program flow, it should have an exit option. What if someone decides they don't want their mail program trying to check email when they are in poor coverage area, or maybe in a Skype call or whatever? Let them exit the email program if they want!

某些应用程序上的退出按钮应该比其他应用程序更靠前。例如，游戏或用户可能想要完全退出的程序应该有一个明显的退出。其他程序，例如电子邮件程序，不太可能希望退出（以便它可以继续检查电子邮件）——这些程序不应该浪费带有退出选项的主要控制输入屏幕空间，但是为了良好的程序流程，它应该有退出选项。如果有人决定不希望他们的邮件程序在覆盖范围较差的区域或 Skype 通话中尝试检查电子邮件，该怎么办？如果他们愿意，让他们退出电子邮件程序！

Suspending and exiting are two vital tasks and neither fulfills the role of the other.

暂停和退出是两项至关重要的任务，两者都不能完成另一个任务。