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

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


当前回答

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.

其他回答

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

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

`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();

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

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

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

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

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

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

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

嗯……

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

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

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

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

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

关键是我不能考虑到 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移植。