android - 退出应用程序- 不赞成这么做?

  显示原文与译文双语对照的内容

在我试图学习android移动,我只是读以下 :

问题: 用户是否可以选择杀死应用程序,除非我们将菜单选项放入杀死它? 如果不存在这里选项,用户如何终止应用程序?

回答:( Romain Guy ): 用户没有,系统自动处理这里问题。 这就是 Activity 生命周期( 尤其是 onPause/onStop/onDestroy) ) 。 无论你做什么,不要放置"退出"或者"退出"应用程序按钮。 使用android模型是无用的。 这也与核心应用程序如何工作相反。

呵呵,对于我在Android世界中的每一步,我遇到了一些问题= (

显然,你不能退出 Android ( 但是Android系统可以很好地摧毁你的应用,每当它感觉到它) 中的应用程序。 怎么了我开始认为写一个作为"普通应用"的应用程序是不可能的。当用户决定这样做的时候,用户可以退出应用程序。 这不是操作系统要做的事情。

我试图创建的应用程序不是Android市场的应用程序。 它不是"广泛使用"的一个应用程序供大众使用,它是一个在非常狭窄的业务领域使用的商业应用。

我真的很期待为Android平台开发,因为它解决了 Windows Mobile 和. NET 中存在的很多问题。 然而,上周我已经有点turnoff了。 我希望我不必抛弃安卓,但现在它看起来并不很好= (

是否有方法让我真正的退出应用程序

时间:

这最终会解决你的问题,但我首先想解决你在写作时已经给出的各种问题的各种问题。 我无意改变你的想法 --,而这些都是在未来阅读这篇文章的其他人。

关键是我不能让安卓决定我的应用什么时候被终止。 这必须是用户的选择。

数以百万计的人对模型非常满意,因为环境在需要时关闭应用程序。 这些用户根本不认为"正在终止"是 Android 应用,就像他们认为"正在终止"网页或者"正在终止"一样。

iphone用户一样,按iphone按钮不一定"觉得"像应用程序终止,因为许多iphone应用程序,用户离开,即使应用程序确实是( 因为iPhone一次只允许第三方应用,目前) 关闭。

就像我上面所说的,我的应用程序( 被推送到设备的数据,列出总是应该在那里的任务) 有很多事情。

我不知道"列出总是应该在那里的任务"是什么意思,但"正被推送到设备的数据"是一个令人愉快的小说,不应该在任何情况下都由 Activity 来完成。 使用计划任务( 通过 AlarmManager ) 更新数据以获得最大的可靠性。

我们的用户登录并不能做,每次他们打电话时,android决定杀了这个应用程序。

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

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

这是任何操作系统的错误。 你知道,你的应用程序正在"已经退出"的原因是操作系统关闭,然后你的更新过程将mid-stream失败。 一般来说,这不是一件好事。 在启动或者检查更新时检查更新完全异步( e.g,通过计划任务),从不在退出时。

一些评论建议点击back上一步does按钮并不会杀死所有( 查看我上面的问题中的链接) 。

按BACK上一步does按钮不"终止应用"。 当用户按下BACK后退按钮时,它完成了 Activity的on-screen 。

它应该只在用户想要终止它时终止- 永远不会有任何其他方式。 如果你无法在Android中编写这样的应用,那么我认为Android不能用于编写真正的应用= (

然后网络应用都不能。 或者,如果我理解他们的模型正确。 在所有的这些中,用户没有任何"终止"--他们只是离开。 iPhone有点不同,因为它只允许一次运行一次( 有几个例外),所以离开的行为意味着立即终止应用程序。

是否有办法让我真正退出应用程序?

就像其他人告诉你的,用户( 通过背面) 或者你的代码( 通过 finish() ) 可以关闭你的currently-running Activity 。 对于properly-written应用程序来说,用户一般不需要任何其他东西,因为他们需要使用"退出"选项来使用网络应用程序。


根据定义,没有两个应用程序环境是相同的。 这意味着你可以在新的环境中看到趋势,而其他的会被埋没。

例如试图消除"文件"的概念的移动。 大多数网络应用程序都不强迫用户思考文件。 iPhone应用程序通常不会强迫用户考虑文件。 Android应用一般不会强迫用户思考文件。 等等。

类似地,试图消除"正在终止"的概念也有一个不断增长的举措。 大多数网络应用程序不强制用户注销,而是在一段时间不活动后隐式注销用户。 和安卓一样,而且在某种程度上,iPhone ( 可能是 WebOS ) 。

这需要更注重应用程序设计,专注于业务目标,而不是与以前的应用程序环境绑定的实现模型。 缺乏时间或者精力的开发人员会在新的环境破坏现有的心智模型时感到沮丧。 这不是任何一个环境的故障,更多的是围绕着它而不是通过它的风暴的山脉。

例如一些开发环境,比如Hypercard和 Smalltalk,在一个安装程序中拥有应用程序和开发工具 co-mingled 。 这个概念没有得到太多的关注,除了对应用( e.g,Excel中的VBA,AutoCAD中的LISP ) 之外的语言扩展之外。 推定的存在开发工具开发者谁发明的心理模型,并在该应用本身,因此,无论是必须改变它的模型或者泥于环境中,他们的模型将存放在正确的。

所以,当你编写时:

除了我发现的其他凌乱的东西,我认为开发我们的Android应用不会发生。

这似乎是最好的,对于你来说,现在。 在网页应用程式的和( e.g,没有"终止类似地,我就律师你应对试图端口是将应用程序事件信息,因为你有某些相同的问题报告与Android兼容你将张近照 在那个time,或者反过来说,如果你 端口做你将来会应用到站点,你可能会发现该站点的应用程序为Android可能是一个更好的匹配,并且你可以重新访问安卓的port.流

我想在这里为这个线程的未来读者添加一个修正。 这种特殊的细微差别已经超出了我的理解很长时间,所以我想确保大家都不会犯同样的错误:

System.exit() 不杀死你的应用如果你有超过一个 Activity 到栈上。过程实际上是死亡,立即重启与少一个 Activity 堆栈。 这也是当你的应用被强制关闭对话框杀死时,或者你试图杀死来自DDMS的进程时发生的事情。 这是一个完全没有文档的事实,据我所知。

简短的回答是,如果你想退出你的应用程序,你必须跟踪所有活动在你的堆栈和 finish() 他们当用户想退出( 而且,没有办法迭代 Activity 堆栈,所以你必须自己管理所有这些) 。 甚至这并不能真正杀死进程或者任何悬空引用。 它只是完成了这些活动。 我也不确定 Process.killProcess(Process.myPid()) 干得好,我还没有测试过。

另一方面,如果它是好的对你有活动剩下的堆栈中,还有一个方法让事情对你超级简单: Activity.moveTaskToBack(true) 将简单的后台显示你的进程并显示主屏幕。

长的答案包括对这个行为背后的哲学的解释。 哲学源于许多假设:

  1. 首先,只有当你的应用在前台时才会发生。 如果它在后台,进程将会终止。 但是,如果它在前台,操作系统假设用户想要继续做他想做的事情。 ( 如果你想从DDMS中杀死这个进程,你应该先点击home主页button按钮,然后杀死它)
  2. 它还假设每个 Activity 独立于所有其他活动。 这通常是真的,比如你的应用程序启动浏览器 Activity,它是完全独立的,不是由你编写的。 浏览器 Activity 可能在同一任务上创建,也可能不是,具体取决于它的清单属性。
  3. 它假设你的每一个活动都是完全独立的,并且可以在一个时刻通知/恢复。 (我很不喜欢这个特定的假设,因为我的程序有很多活动,依赖于大量的缓存数据,在 onSaveInstanceState 过大,无法有效地序列化,但是whaddya要做什么?)对于大多数well-writtenandroid应用程序这应该是真的,因为你永远不知道当你的应用程序在后台是杀死了。
  4. 最后一个因素不是一个假设,而是操作系统的一个限制: 杀死应用程序与应用崩溃一样,同样也与Android杀死内存的应用一样。 culminates在我们的致命一击: 由于Android无法判断应用程序是退出还是崩溃,或者在后台被杀死,它假设用户想要返回他们离开的地方,所以ActivityManager重新启动进程。

当你想到它的时候,这适合于平台。 首先,这正是在后台杀死进程并返回用户时发生的情况,所以需要重新启动它。 其次,当应用程序崩溃并显示可怕的强制关闭对话框时,会发生这种情况。

假设我想让我的用户能够拍照并上传它。 我从 Activity 启动相机 Activity, 让它返回一个形象。 相机被推到我当前任务的顶部( 而不是在自己的任务中创建) 。 如果相机有错误并且崩溃,那么整个应用会崩溃? 从用户的角度来看,只有摄像机失败,它们应该返回到以前的Activity 。 所以它只是在堆栈中使用所有相同的活动重启进程,减去相机。 因为你活动应设计,这样他们可以死亡,恢复的,这应该不是一个问题。 不幸的是,并不是所有的应用程序都可以这样设计,所以它是个问题对我们许多人来说,无论什么罗曼人或任何人告诉你。 所以,我们需要使用变通方法。

我的结束语是:

  • 不要试图杀死进程。 在所有活动中调用 finish() 或者调用 moveTaskToBack(true)
  • 如果你的进程崩溃或者被杀死,如果像我一样,你需要内存中的数据,那么你需要返回到内存中,你需要返回到根 Activity 。 带有 Intent 包含该 Intent.FLAG_ACTIVITY_CLEAR_TOP flag,要做到这一点,你应该调用
  • 如果你想从 Eclipse DDMS的视角杀死你的应用,它最好不要在前台,或者它会自动重启。 则应首先请按下主屏幕按钮,然后然后 杀死进程。

所有应用程序都已经退出按钮。。 我经常从用户那里得到积极的评论。 我不在乎这个平台是否设计成应用程序不需要它们。 说"不要把它们放在那里"有点荒谬。 如果用户想要退出。。 我为他们提供了访问的权限。 我不认为它能降低安卓的工作方式,看起来很好。 我理解生命周期。。 我的观察是Android在处理它的时候并没有做得好。 这是个基本事实。

停止将你的应用程序看作一个整体应用程序。 它是用户可以与"应用程序"交互的一组用户界面屏幕,通过Android服务提供"函数"。

不知道你的神秘应用"确实"不是什么真正重要的。 让我们假设它进入一些超级安全的企业内部网,执行一些监视或者交互,并保持登录,直到用户"退出应用程序"。 因为你的it部门命令它,用户必须非常清楚他们什么时候进入或者离开内部网。 因此你的想法对用户来说很重要。

这很简单。制作一个在通知栏中进行通知的服务说"我在内部网,或者我正在运行"。 让该服务执行你的应用程序所需的所有功能。 有与该服务绑定的活动,允许你的用户访问他们需要与你的"应用程序"交互的用户界面位。 并有一个Android菜单-> 退出( 或者注销,或者) 按钮告诉服务退出,然后关闭 Activity 本身。

对于所有的意图和目的,这就是你想要的。 完成了Android的方式。查看 Google Talk或者 谷歌地图 导航以了解这个"退出"的示例。 唯一的区别是,按下 Activity的按钮可能会让你的UNIX进程处于等待状态,以防用户想要唤醒你的应用程序。 这与现代操作系统没有什么不同,它把最近访问过的文件缓存在内存中。 在你退出 Windows 程序后,它所需要的大部分资源仍然在内存中,等待被其他资源替代,现在它们不再需要。 安卓是一样的东西。

我真的看不到你的问题。

这是对许多专家贡献的有趣和有见地的讨论。 我觉得这篇文章应该在android开发者主页上循环,因为它围绕着android操作系统的核心设计。

我也想在这里添加我的2美分。

到目前为止,我已经对处理生命周期事件的android感到印象深刻,将网站的概念引入到原生应用中。

说我仍然认为应该有一个退出按钮。 为什么不为我或者ted或者任何技术专家,只是为了满足最终用户需求。

虽然我不是 Windows的一大粉丝,但很久以前他们引入了一个概念,大多数最终用户都习惯于( X 按钮) 。 "当'我'想要"时,我想退出一个小部件。 这并不意味着有人( 操作系统,开发者) 会在 its/his/her 自己的descretion上负责。 它只是意味着"我的红色X 按钮是用来"。 我的动作应该类似于'按按钮结束呼叫','按按钮关闭设备'等等。 它是一种感知,它给我带来了满意的感觉,我的动作确实达到了它的目的。

根据a developer can spoof this inthe父母亲using建议加强同人道 换句话说,观念still出版物应当依照2002( 现在) 细胞钢丝,trusted独立的来源( 操作系统) footprint neutral andend运用得更多的人们。

你辞职,要么按按钮或通过调用 finish()Activity 。 如果你想显式地杀死 finish(),就从 MenuItem 调用它。

Romain并没有说它不能做,只是因为没有意义的—用户不需要关心退出或者保存他们的工作,因为应用程序生命周期的工作鼓励你编写自动保存并恢复它的状态的智能软件。

争论归结为开发人员是否知道最好的问题或者用户是否知道最好的问题。 在人类因素的所有领域中的专业设计师每天都在挣扎。 ted已经取得了一个点,一个大多数'应用杀手'市场上下载应用程序。 当他们退出应用程序时,人们会得到一些额外的serotonin 。 它们是用桌面/笔记本电脑来实现的。 它让事情保持快速。 它使处理器保持凉爽,风扇不打开。 它使用更少的能量。当你考虑到移动设备是一个规模小得多的船,然后你可以'抛弃你不再需要的东西'尤其欣赏他们的动机。 现在安卓的开发人员认为,退出应用程序的操作系统知道什么是最好的,是古董。 我衷心支持。然而,我也相信你不应该阻挠用户,即使挫折是证实自己的无知。 正因为如此,我认为有一个'退出'选择是好的设计,即使它是一个安慰剂按钮,并没有超过近一个视图。

Ted,你想要完成的事情可以完成,也许你现在的想法不是。 我建议你阅读活动和服务。 停止使用术语"应用"并开始引用组件 IE 。 Activity,服务。我想你需要了解更多关于android平台的信息,它是一个从标准的个人电脑应用中的心态变化。 这一事实没有你的帖子有词"Activity"(faq报价, IE 不是你的话)他们告诉我你需要多读一些。

这篇文章解释,比我。 我希望每个Android开发者都已经读过它了。

编辑:链接似乎已经关闭。 是来自返回机器的缓存版本

的摘录:

在我的经验中,[the users] 真正需要的是:
保证应用程序的一个明确的方法将停止( 电池,CPU周期,数据传输等) 消耗资源。

许多用户认为一个退出按钮实现了这个需求并要求它被添加。 开发人员,寻找他们的用户,obligingly添加一个。 很快他们都失败了。

  • 大多数情况下,退出按钮只调用 Activity.finish() 。 这相当于 ,相当于按back上一步button按钮。 精确的 服务持续运行,轮询持续发生。 用户可能认为他们已经杀死了应用,但他们没有,很快他们会更恼火。
  • 退出行为现在不明确。 你的退出按钮应该关闭 Activity,还是应该停止所有相关的服务,接收器和提醒? 回来该怎么办? 如果他们打回家呢? 如果你的应用程序有一个小部件会发生什么? 退出按钮是否停止更新?

解决方案是使back后退button按钮的行为与你预期的退出按钮一样。 更好的是,只要应用不可见就停止消耗资源。

继续阅读完整文章。

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

例如当应用程序不可见时,Google监听继续播放播客。 但是当用户完成操作时,总是会有暂停按钮关闭播客。 如果我记错了,听着,即使在通知栏中也会有一个快捷方式,这样你就可以很快的到达pause暂停button按钮。 另一个例子是像 Twitter 应用这样的应用,它不断地在互联网上轮询一个服务。 这些类型的应用应该允许用户选择轮询服务器的频率,或者在后台线程中轮询。

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

...