继续学习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.

呵呵,我在Android世界里每走一步都会遇到一些问题=(

显然,你不能在Android中退出应用程序(但Android系统可以随时完全销毁你的应用程序)。这是怎么回事?我开始认为这是不可能写一个应用程序的功能作为“正常的应用程序”-用户可以退出应用程序时,他/她决定这么做。这不应该依靠操作系统来完成。

我正在尝试创建的应用程序不是Android市场的应用程序。它不是一个被大众“广泛使用”的应用程序,它是一个将在非常狭窄的商业领域使用的商业应用程序。

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

有办法让我真的退出应用程序吗?


当前回答

我只是想在这里为这篇文章的未来读者补充一个更正。这个细微的差别我已经不理解很长一段时间了,所以我想确保你们没有人会犯同样的错误:

如果栈上有多个activity, 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.

另一方面,如果你可以将活动保留在堆栈中,还有另一个方法可以让事情变得超级简单:Activity.moveTaskToBack(true)将简单地将你的进程作为背景并显示主屏幕。

长的答案包括对这种行为背后的哲学的解释。这一理论是基于以下几个假设:

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) 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. 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. 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.

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

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 should be 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 is a problem for many of us, no matter what Romain Guy or anyone else tells you. So, we need to use workarounds.

所以,我最后的建议是:

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_TOP flag. 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 then kill the process.

其他回答

博客文章“何时在Android应用程序中包含退出按钮”(提示:永远不要)解释得比我好得多。我希望每个Android开发者都读过这本书。

摘录:

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 exactly equivalent 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 Back do? What happens if they hit Home instead? 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.

继续阅读完整的文章。

使用以下代码:

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

几乎99%的情况下,Android应用程序不需要接管自己的生命周期。大多数情况下,这归结于更好的计划或更聪明的应用程序设计。例如,构建一个内部服务(不导出)来处理下载等,或者围绕用户工作流设计动作和任务。

但话虽如此,有志者事竟成。Android通过Android .os. process类提供了一个比Java更好的API来控制底层进程。与Java不同的是,它不会把开发人员当成傻瓜,把所有问题都隐藏在一个简单的Java .lang. system .exit()调用之后。

那么如何让你的应用在Android中自杀呢?诀窍很简单:

通过继承标准Android .app. application类来创建自己的Android应用程序类(记得在AndroidManifest.xml文件中声明它)。

重写onCreate()方法,并存储启动应用程序的进程ID:

this.pid = android.os.Process.myPid(); // Save for later use.

现在要杀死你的应用程序,提供一个kill()方法:

android.os.Process.sendSignal(pid, android.os.Process.SIGNAL_KILL);

现在,无论何时你需要你的应用自杀,只要输入转换应用上下文,并调用你的kill方法!

((MySuicidalApp) context.getApplicationContext()).kill()

请记住,由于Android中的进程管理策略,特别是与服务相关的策略,Android可能只是选择重新启动你的服务(参见你不应该在Android上使用任务杀手)。

您可以通过按Back按钮或在Activity中调用finish()来退出。如果您想显式地终止它,只需从MenuItem调用finish()。

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

有退出按钮的一个重要原因是“退出”广告。在出口,可以显示一些产生收入的广告。像所有的广告一样,它还是有点烦人,但也许比那些占用宝贵屏幕空间的广告更烦人。一些广告网络提供这种广告方式。但是,真的,你不能只是放一个退出按钮,在显示广告后什么都不做!

因此,在某些情况下需要一种或另一种方式来终止程序,而“永远不应该被需要”可能不是最全面的答案。

可能会使用Activity.finish()或System.exit(0)。