继续学习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,但它现在看起来不太好=(

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


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

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


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

For example, Google Listen continues to play podcast when the app is not visible. But there is always the pause button to turn the podcast off when the user is done with it. If I remember correctly, Listen, even puts a shortcut in the notification bar so you can always get to the pause button quickly. Another example is an app like a twitter app for instance which constantly polls a service on the internet. These types of apps should really allow the user to choose how often to poll the server, or whether even to poll in a background thread.

如果你需要在退出时运行的代码,你可以根据需要重写onPause(), onStop()或onDestroy()。 http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle


Android上下文中的应用程序只是一堆模糊相关的活动,退出应用程序并没有多大意义。你可以finish()一个Activity, Activity栈中前一个Activity的视图就会被绘制出来。


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

关键是我不能考虑到 Android来确定我的应用程序 将被终止。那一定是 用户的选择。

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

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

正如我上面所说的,有很多 在我的应用程序(数据是 推送到设备,列出任务 它总是应该在那里,等等)。

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

我们的用户登录了,不能做什么 每次他们接到电话 Android决定关闭这款应用。

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

例如,我们希望检查更新 退出应用程序时

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

一些评论建议打 返回按钮不杀死应用程序在 所有(见上面我的问题中的链接)。

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

仅当 用户想要终止它——从来没有 任何其他方式。如果你不会写字 在Android中运行的应用程序, 那么我认为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移植。


泰德,你想要实现的目标是可以实现的,只是可能不是你现在想的那样。

我建议您阅读活动和服务。停止使用术语“应用程序”,开始引用组件,即活动,服务。我认为你只需要更多地了解Android平台;这是一个标准PC应用程序的心态变化。事实上,你的帖子中没有一个词是“活动”(简单的FAQ引用,即不是你的话),我告诉我你需要阅读更多。


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


我会考虑阅读Addison-Wesley出版的“Android Wireless Application Development”。我刚刚完成它,它是非常彻底的。

看来你对Android平台有一些基本的误解。一开始我也对Android应用程序的生命周期感到有点沮丧,但在更深入地了解后,我开始真正享受这种方法。这本书将回答你所有的问题,甚至更多。这确实是我为Android新开发者找到的最好的资源。

Also, I think you need to let go of a line-for-line port of the existing app. In order to port your application to the Android platform, some of the application design is going to change. The application-lifecycle used is necessary as mobile devices have very limited resources relative to desktop systems and allows Android devices to run several applications in an orderly and resource-aware fashion. Do some more in depth study of the platform, and I think you will realize that what you are wanting to do is entirely feasible. Best of luck.

顺便说一下,我与艾迪生-卫斯理或与这本书有关的任何个人或组织都没有任何关系。重读了我的帖子后,我觉得我有点像个迷弟。我真的非常非常喜欢它,而且发现它非常有帮助。:)


嗯……

我认为你只是没有以正确的方式看待Android应用。你可以很容易地做一些你想做的事情:

像开发者生命周期文档中鼓励的那样,执行应用程序活动的保存/恢复状态。 如果在恢复阶段需要一些登录(没有可用的登录/会话信息),那么就这样做。 最终添加一个按钮/菜单/超时,在这种情况下,你将执行finish()而不保存登录和其他会话信息,隐式地结束应用程序会话:因此,如果应用程序再次启动/带到前面,它将开始一个新的会话。

这样你就不关心应用是否真的从内存中删除了。

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


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

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


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方式”,但它似乎不应该被排除。在这里 您可能需要一个真正的应用程序出口(不是 只是活动):

The user might want some control over which app gets killed in the case of low memory. If important app A is running in the background, then you might like to exit app B when you are done with it so that app A doesn't get killed by the operating system. If your application has sensitive data cached in memory, you might like to kill the app so that a virus/worm/rogue app can't get at it. I know the security model is supposed to prevent that, but just in case... If your application uses resources (like network, CPU, sensors, etc.) that could adversely affect the phone, then one way of ensuring that those resources are freed up is to exit the application. I understand that well-behaved apps should free up resources when they are not needed. But again, exiting the application seems like a reasonable way of ensuring that.


不要把您的应用程序看作一个整体应用程序。它是一组UI屏幕,用户可以通过Android服务与你的“应用程序”和“功能”进行交互。

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

这很简单。创建一个服务,在通知栏中放置一个持续通知,说“我在内部网中,或者我正在运行”。让该服务执行应用程序所需的所有功能。拥有绑定到该服务的活动,以允许用户访问与“应用程序”交互所需的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.

我真不明白你有什么问题。


如果你无法理解如何让你的数据/连接(因此你的“应用程序”)持久,那么你将无法用Android做你“需要”做的事情。

那些下载了这些可爱的小应用程序杀手的人通常会发现,它们对电池寿命或内存使用没有帮助,反而阻碍了操作系统有效管理内存的工作……

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


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


如果没有退出函数,应用程序开发人员就可以杀死自己的应用程序,这是非常糟糕的设计。

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


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

我还想在这里发表我的意见。

到目前为止,我对Android处理生命周期事件的方式印象深刻,它将类似web的体验概念引入原生应用。

话虽如此,我仍然认为应该有一个退出按钮。为什么?... 不是为了我,不是为了泰德,也不是为了在座的任何一位技术大师,而是为了满足终端用户的需求。

虽然我不是Windows的忠实粉丝,但很久以前他们引入了一个大多数终端用户都习惯的概念(X按钮)……“我想在‘我’想要的时候停止运行一个小部件”。

这并不意味着有人(操作系统、开发人员?)会根据自己的判断来处理……它仅仅意味着“我习惯的红色X按钮在哪里”。我的行为应该类似于“按下按钮结束通话”,“按下按钮关闭设备”,等等……这是一种感知。它本身带来了一种满足感,我的行动确实达到了目的。

尽管开发人员可以使用这里给出的建议来欺骗这种行为,但仍然存在这样的看法,即应用程序应该完全停止运行(现在),由最终用户要求的独立、可信和中立的来源(OS)。


有一个(相对)简单的设计可以让你绕过“退出”难题。让你的应用程序有一个“基本”状态(活动),这只是一个空白的屏幕。在活动的第一个onCreate,你可以启动另一个活动,你的应用程序的主要功能在其中。“退出”可以通过finish()完成第二个活动并返回到空白屏幕的底部来完成。操作系统可以在内存中保留这个空白屏幕,只要它想要…

本质上,因为你无法退出到操作系统,你只是转化成一个自我创造的虚无。


这场争论可以归结为一个古老的问题:究竟是开发人员最了解,还是用户最了解。所有人为因素领域的专业设计师每天都在与这个问题作斗争。

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

当你认为移动设备是一艘小得多的船时,你就会特别感激他们“抛弃你不再需要的东西”的动机。现在,Android的开发者们认为操作系统才是最清楚的,退出一个应用程序已经过时了。我全心全意地支持这一点。

然而,我也认为你不应该让用户感到沮丧,即使这种沮丧是出于他们自己的无知。因此,我认为有一个“退出”选项是很好的设计,即使它只是一个安慰剂按钮,只是关闭一个视图。


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

这是一个GPS应用程序,轮询积分,并每隔几秒钟通过线程将当前位置发送到web服务…在Ted的情况下,这可能是每5分钟轮询一次更新,然后onStop可以简单地启动Ted所关心的更新活动,如果发现了一个(异步Ted,不要像Windows程序员那样编码,否则您的程序将像Windows程序一样运行……呃,这也没那么难)。

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

...

@Override
public void onStart() {
    super.onStart();
    isRemote = true;
    checkUpdate.resume();

    locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 2000, 0, luh);
}

@Override
public void onPause() {
    isRemote = false;
    checkUpdate.suspend();
    locationManager.removeUpdates(luh);
    super.onStop();
}

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

Voilà, an application that doesn't consume CPU when it's in the background, yet is instantly ready to reopen because it is in RAM (although not holding RAM as is the Android lifecycle) ... an app is always ready, it's a phone, guys/gals. If an app was to use up all the RAM and couldn't be shut down by the OS then the thing might stop ringing =P That's why the OS needs to be able to close your app when it's in the background (if your application isn't a resource hog it won't be closed BTW), so let's just write better applications.


Linux内核有一个称为内存不足杀手的特性(如上所述,这些策略可以在用户空间级别进行配置,而且内核不是最优的,但也不是不必要的)。

它被Android大量使用:

OOM杀手不适合用户空间 Android笔记(OOM杀手信息-你可以在Android上配置OOM功能) Android移植在Real Target

一些用户空间应用程序可以帮助这些杀死应用程序,例如:

自动杀手/配置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上构思一个应用程序时,我是这样看的:

您正在使用您的应用程序 电话响了 你接电话 在通话结束时,您将回到应用程序所在的位置

要做到这一点,你只需要手机的后退键或Home键(短按或长按)和通知栏。

当我退出我的应用程序时,我只使用后退按钮,直到我退出它或Home按钮。

我认为这就是大多数应用的构思。但如果我需要某种会话或连接,我会用登录/注销按钮和通知(标题栏或其他任何东西)向用户明确表示。这是一种与纯“退出”样式应用程序相当不同的样式。

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

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


显然,您已经在finish()命令中找到了想要的答案。这不会将你的应用从内存中移除,但Android会在它需要资源的时候这样做,所以你不会显式地这样做没有任何区别。

我只想补充一点,为了达到应用程序退出通常具有的全部效果,您需要将应用程序的状态重置为设备引导后第一次运行时的正常状态,就在对所有活动调用finish()之前。这样,如果用户再次选择你的应用程序,它将显示为“新鲜”运行,在模拟“退出”之前没有任何状态。

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

这种方法可以让你实现“退出”命令的目标,而不违反Android的理念,即将操作系统资源的管理(包括关闭应用程序)交给操作系统。

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

唯一的例外是,当用户按下后退按钮的次数足够多,导致应用程序关闭。在这种情况下,用户不希望状态被保存(如果应用程序中有未保存的状态,那么作为开发人员,你应该有代码处理返回按钮,检测未保存的数据,并提示用户将其保存到SharedPreferences或文件,或其他一些非易失性介质)。

关于system . exit (0):

如果你决定使用system.exit(0)关闭你的应用程序与粗鲁的终结(例如,作为一个最后的后退按钮按下的结果),那么我要警告你,虽然对我来说这是“工作”,在某些情况下,我已经能够关闭一个应用程序没有任何痕迹,有一个小故障发生在果冻豆当你使用这种方法。

具体来说,如果你使用最近的应用程序列表打开你的应用程序,然后使用返回按钮关闭应用程序(通过system.exit(0)实现关闭),最近的应用程序列表将再次可见,因为它永远不会被关闭。如果你在该列表中点击应用程序的条目,从相同的、已经打开的、最近的应用程序列表中再次运行它,将没有响应。

我怀疑造成这种情况的原因是,最近的应用程序列表持有一个对你的应用程序的引用,由于你已经使用system.exit(0)关闭了应用程序,该应用程序已变得无功能。使用finish()更文明地关闭应用程序可能会通知操作系统,允许它刷新其最近应用程序列表,但system.exit(0)显然没有这样做。

This is not a huge problem in and of itself, as very few people will open an app from Recent Apps, then exit it, and then immediately open it again from the same open Recent Apps list. And if they tap the home button and then re-open the Recent Apps list, your app's entry will be there, and it will be fully functional. But I think that it shows that the use of system.exit(0) can interfere with proper communication between your app and the OS, and this suggests that there may be other, more serious, possibly subtle, consequences of using this approach.


首先,永远永远不要使用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();

我在SharedPreferences中保存我想要终止应用的那个,我启动了一个Intent。请看那些旗子;这些将清除我所有的backstack,调用我的DashBoard Activity,这是我的“home”Activity。

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

private void checkIfForceKill() {

    // CHECK IF I NEED TO KILL THE APP

    // Restore preferences
    SharedPreferences settings = getSharedPreferences(
            getString(MXMSettingHolder.PREF_ID), Context.MODE_PRIVATE);
    boolean forceKill = settings.getBoolean(
            MusicSinglePaneActivity.FORCE_EXIT_APPLICATION, false);

    if (forceKill) {

        //CLEAR THE FORCE_EXIT SETTINGS
        SharedPreferences.Editor editor = settings.edit();
        editor.putBoolean(FORCE_EXIT_APPLICATION, false);

        // Commit the edits!
        editor.commit();

        //HERE STOP ALL YOUR SERVICES
        finish();
    }
}

它会运行得很好。

唯一一件我不明白为什么会发生的事情是,当我做最后的完成(我已经检查过:它遵循所有正确的onPause→onStop→onDestroy流程)应用程序仍然在最近的活动(但它是空白的)。

似乎最新的意图(已经启动了DashboardActivity)仍然在系统中。

我还得挖更多才能把它挖出来。


博客文章“何时在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.

继续阅读完整的文章。


几乎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上使用任务杀手)。


这很简单。只要遵循我要告诉你的这些指示:

比如你有多个活动,从一个活动到另一个活动。你可能会像这样使用intent:

Intent i1 = new Intent(this, AnotherActivity);
startActivity(i1) 

你只需要添加finish();例如,从头到尾在每个活动上启动intent活动后,

Intent i1=new Intent(this, AnotherActivity);
startActivity(i1) 
finish();

所以当你点击退出按钮时使用的是finish()或System.exit(0)必须完全关闭你的应用程序。


每次当你通过意图移动到下一页时,使用:

`YourActivityname.this.finish()`;

例子:

Intent intent = new Intent(getApplicationContext(), SMS.class);

startActivity(intent);
MainActivity.this.finish();

因此,没有活动将在后台运行,当你想退出你的应用程序,使用:

MainActivity.this.finish();
android.os.Process.killProcess(android.os.Process.myPid());
System.exit(0);
getParent().finish();

这种退出对我来说就像一个魅力:)


对于应用程序的第一个(启动)活动,

@Override
public void onBackPressed(){

    // Exit
    moveTaskToBack(true);
}

为我工作。我想在这里关闭应用程序。从其他活动中回来;我用了意图,例如:

@Override
public void onBackPressed(){

    // Going back....
    Intent intent = new Intent(ActivityB.this, ActivityA.class);
    startActivity(intent);
    finish();
}

注意:这段代码适用于开发人员想要从ActivityZ返回ActivityA然后关闭应用程序的场景。


回答:(罗曼盖伊):用户不需要,系统会处理这个问题 自动。这就是活动生命周期(特别是 onPause/onStop/onDestroy)用于。无论你做什么,都不要放不下 “退出”或“退出”应用程序按钮。这在安卓系统中毫无用处 应用程序模型。这也与核心应用程序的方式相反 工作。

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 is some use in allowing the user to fully close apps.

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

总而言之,最小化和退出之间有明显的区别,两者都不适合对方。每个螺丝上都留个螺丝刀吗?还是每扇门都有钥匙?我们是不是把所有的电器都开着,直到断路器爆炸,我们需要打开另一个电器?我们是不是把洗碗机里装满了盘子,每次只拿出足够的空间来放一些新的脏盘子?我们把所有的车都停在车道上,直到——哦,算了。

如果用户想要最小化应用程序,那么最好的方法就是最小化它。如果用户想要退出应用程序,那么无论如何最好是退出。

这会让人皱眉吗?这是Android的观点——他们不赞成。许多独立的Android新手开发者对此表示不满。

但当它落到实处时,有好的编码和坏的编码。有好的程序流模型也有坏的程序流模型。

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

这有点像你的汽车:有时你让它一直开着,比如在红绿灯前停车,或者在快餐店经过时停车,或者在自动取款机前停车。但在其他情况下,你确实想把它关掉——比如当你去工作的时候,或者在杂货店,甚至在家里。

同样地,如果你正在玩游戏,这时手机响了。暂停游戏并继续运行。但如果用户已经玩了一段时间,那就让他们退出游戏吧。

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!

暂停和退出是两项至关重要的任务,两者都不能实现对方的作用。


目前,我在我的应用程序中实现了以下内容。可能这些有助于从应用程序中移动出来,无论你想要的是什么。我从操作栏菜单中调用这个函数。

public static void exitApplication(Context context) {
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
        exitApplicationHC(context);
    }
    else {
        exitApplicationPreHC(context);
    }
}

private static void exitApplicationPreHC(Context context) {
    Intent i = new Intent(context, LoginActivity.class);
    i.putExtra(EXTRA_EXIT, true);
    i.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
    i.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
    context.startActivity(i);
    if (context instanceof Activity) {
        ((Activity) context).finish();
    }
}

@TargetApi(Build.VERSION_CODES.HONEYCOMB)
private static void exitApplicationHC(Context context) {
    Intent i = new Intent(context, LoginActivity.class);
    i.putExtra(EXTRA_EXIT, true);
    i.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
    i.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
    i.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TASK);
    context.startActivity(i);
}

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

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

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


你可以使用Process.killProcess(Process.myPid());杀死你的应用程序,但它可能不安全?我使用这个方法后没有遇到任何问题或崩溃,使用这个方法后,我的应用程序在DDMS列表中的进程消失了。


Android应用程序的生命周期是为手机用户设计的,而不是电脑用户。

应用程序生命周期是将Linux服务器转变为消费者设备所需的极其简单的范例。

Android是基于Linux的Java,一个真正的跨平台服务器操作系统。这就是为什么它传播得这么快。应用程序生命周期封装了操作系统的底层现实。

对于手机用户来说,应用只是安装或不安装。没有奔跑或退出的概念。事实上,应用程序进程应该一直运行到操作系统释放它们以获取所拥有的资源为止。

因为这是Stack Overflow,任何阅读这篇文章的人都是计算机用户,必须关闭他们90%的知识来理解移动应用程序的生命周期。


如果你指定API >= 16, Activity#finishAffinity()可以满足你的需求。


如果你有10个,20个…有多个活动正在运行,你想要完成所有活动并退出系统。

在应用程序类或常量类中创建静态数组。

常量

public class Constants {

public static ArrayList<Activity> activities = new ArrayList<Activity>();

}

在此数组中添加当前活动引用

activity = MainActivity.this; Constants.activities.add(活动);

public class MainActivity extends Activity {

    private ImageView imageButton;
    private Activity activity;


    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        activity = MainActivity.this;
        Constants.activities.add(activity);

        imageButton = (ImageView) findViewById(R.id.camera);
        imageButton.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {

                // existing app.
                if (Constants.activities != null) {
                    for (int i = 0; i < Constants.activities.size(); i++) {
                        Activity s = Constants.activities.get(i);
                        s.finish();
                    }
                }
                //super.finish();
                finish();
                android.os.Process.killProcess(android.os.Process.myPid());
                System.exit(1);
            }
        });
    }
}

另一个选项可以是Android辅助服务,绿色应用程序正在使用强制关闭应用程序来加速内存。有了你的应用程序辅助服务访问,你可以点击按钮,基本上Greenify应用程序点击强制关闭按钮,在应用程序的设置中发现:

在这里你可以学习无障碍服务: https://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html

下面是可访问性服务以编程方式点击的设置按钮:

所以你可以通过以下步骤实现杀死任何应用程序,包括你的:

1)登记无障碍服务申请 2)根据您的要求,如果您想杀死所有应用程序获取列表的所有包 3)导航到他们的设置屏幕并单击强制关闭按钮 这是它。我可以分享一个示例代码,我还创建了一个应用程序,如greenify作为家庭作业。 谢谢你!

更新: “用户不需要,系统会自动处理。” 所以基本上,通过这个解决方案,我们间接地使用了系统强制关闭,但基于用户需求。这样双方都能保持快乐:-)


你可能花了很多年为“合适的”计算机编写“合适的”程序。你说你正在学习用安卓系统编程。这只是你要学会的事情之一。你不可能花几年时间画水彩画,然后假设油画的效果完全相同。这是八年前我编写第一个应用程序时最不新鲜的概念。


作为一个Android开发新手,我开始熟悉生命周期等等。作为一名Android用户,我一直讨厌自己无法删除应用程序。

为什么用户应该信任一个应用程序?我们可能认为把应用放在后台是“安全的”,但用户真的安全吗? 我们可能会爱上“新”做事方式的天才,但并不是所有的应用程序都写得很完美,甚至很好。有些可能是恶意的,并试图保持后台进程一直运行。有些可能是出于好意,但很混乱。

我讨厌打开浏览器或谷歌,从我上次离开的地方开始,不得不向后堆叠几十个缓慢的页面,只是为了感觉我有一个干净的开始。用户应该拥有最终的控制权。有多少次技术支持告诉我们“重启我们的机器”或“关闭程序并重新启动”?用户需要感觉他们是在重新启动应用,而不是恢复一个可能会让他们沮丧或给他们带来问题的状态。

你不能指望人们保留一个复杂的环境模型,只是为了使用一个应用程序来完成一些事情。人们觉得自己可以控制铅笔和纸,因为这体现在他们对铅笔和纸的行为和未来行为的体验中。 软件是魔术,它发生在幕后。它的行为规则就像创建它的开发者一样反复无常。

We should try to design appliances that relate to an underlying, almost physical, model that is robust and reliable and truly intuitive to the user. "Killing" an app is something a user can embrace. It's like throwing out a pile of scratch paper and starting over; closing a book and putting it back on the shelf. Magic has its place for dedicated professionals who can invest themselves in a particular world, such as video editing or animation systems. And these users often contribute to the features themselves and so are comfortable with them. But everyday users deserve at least a few really grounded options they can rely on regardless of sophistication level, in my opinion. I'm for an easy way to exit a process completely even if it is not the target model the system aspires to.