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

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


当前回答

回答:(罗曼盖伊):用户不需要,系统会处理这个问题 自动。这就是活动生命周期(特别是 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!

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

其他回答

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

关键是我不能考虑到 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应用程序生命周期。

这是一个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.

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

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

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

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

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

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

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

作为一个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.

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

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