Est-ce que quitter une application est mal vu?

je voudrais juste ajouter une correction, pour les futurs lecteurs de ce fil. Cette nuance particulière a échappé à mon entendement pendant longtemps donc je veux m'assurer qu'aucun de vous ne fasse les mêmes erreurs:

System.exit() ne pas tuer votre application si vous avez plus d'une activité sur la pile. ce qui se passe réellement est que le processus est tué et immédiatement redémarré avec une activité de moins sur pile. C'est aussi ce qui se produit lorsque votre application est désactivée par la boîte de dialogue Force Close, ou même lorsque vous tentez de désactiver le processus à partir du DDMS. C'est un fait totalement non documenté, à ma connaissance.

la réponse courte est, si vous voulez sortir de votre application, vous devez garder une trace de toutes les activités dans votre pile et finish() tous quand l'utilisateur veut sortir (et non, il n'y a aucun moyen d'itérer à travers la pile D'activité, donc vous devez gérer tous de ce vous-même). Même cela ne tue pas réellement le processus ou toutes les références pendantes que vous pouvez avoir. Il termine simplement les activités. En outre, Je ne suis pas sûr si Process.killProcess(Process.myPid()) fonctionne mieux; Je ne l'ai pas testé.

si, d'un autre côté, vous êtes d'accord pour que les activités restent dans votre pile, il y a une autre méthode qui rend les choses super faciles pour vous: Activity.moveTaskToBack(true) sera simplement background votre processus et afficher l'écran d'accueil.

la longue réponse implique l'explication de la philosophie derrière ce comportement. La philosophie est née d'un certain nombre d'hypothèses:

1. tout d'Abord, cela se produit uniquement lorsque votre application est au premier plan. S'il est à l'arrière-plan, le processus se terminera très bien. Cependant, s'il est au premier plan, L'OS suppose que l'utilisateur veut continuer à faire ce qu'il/elle faisait. (Si vous tentez de mettre fin au processus du DSAD, vous devriez: frapper le bouton de la maison d'abord, puis de le tuer)
2. Il suppose également que chaque activité est indépendante de toutes les autres activités. Cela est souvent vrai, par exemple dans le cas où votre application lance l'activité du navigateur, qui est entièrement séparée et n'a pas été écrite par vous. L'activité du navigateur peut ou non être créée sur la même tâche, selon ses attributs manifestes.
3. Il suppose que chacune de vos activités est complètement autonomes et peut être tué / restauré dans un délai de préavis. (Je n'aime pas cette hypothèse particulière, puisque mon application a de nombreuses activités qui dépendent d'une grande quantité de données cachées, trop grande pour être efficacement sérialisé pendant onSaveInstanceState , mais que faire?) Pour la plupart des applications Android bien écrites, cela devrait être vrai, car vous ne savez jamais quand votre application va être désactivé en arrière-plan.
4. Le dernier facteur n'est pas tellement une hypothèse, mais plutôt une limitation de Le OS: tuer l'application explicitement est le même que l'application s'écraser, et aussi le même que Android tuer l'application pour récupérer la mémoire. cela culmine dans notre coup de grâce: depuis Android ne peut pas dire si l'application est sorti ou s'est écrasé ou a été tué en arrière-plan, il suppose que l'utilisateur veut retourner là où ils se sont arrêtés, et donc L'ActivityManager redémarre le processus.

quand on y pense, c'est approprié pour la plateforme. Tout d'abord, c'est exactement ce qui se produit lorsque le processus est tué à l'arrière-plan et que l'utilisateur y revient, de sorte qu'il doit être redémarré là où il s'est arrêté. Deuxièmement, c'est ce qui se produit lorsque l'application plante et présente le redoutable dialogue Force Close.

dis que je veux que mes utilisateurs puissent prendre une photo et la télécharger. Je lance L'activité Caméra de mon activité, et je lui demande de retourner une image. La caméra est poussée sur le dessus de ma tâche actuelle (plutôt que d'être créé dans sa propre Tâche). Si la caméra a une erreur et qu'elle s'écrase, est-ce que toute l'application devrait s'écraser? Du point de vue de l'utilisateur, seule la caméra a échoué, et ils devraient retourner à leur activité précédente. Donc, il redémarre le processus avec toutes les mêmes activités dans la pile, moins la caméra. Puisque vos activités devraient être conçues de sorte qu'elles puissent être tuées et restaurées à la baisse d'un chapeau, cela ne devrait pas être un problème. Malheureusement, toutes les applications ne peuvent pas être conçues de cette façon, donc il est un problème pour beaucoup d'entre nous, peu importe ce que Romain Guy ou quelqu'un d'autre vous dit. Donc, nous devons utiliser des solutions de rechange.

alors, mon dernier conseil:

• N'essayez pas de tuer le processus. Pour toutes les activités, appelez finish() ou moveTaskToBack(true) .
• si votre processus tombe en panne ou se fait tuer, et si, comme moi, vous avez besoin des données c'était dans la mémoire qui est maintenant perdu, vous aurez besoin de revenir à la racine de l'activité. Pour ce faire, vous devez appeler startActivity() avec une Intention qui contient le Intent.FLAG_ACTIVITY_CLEAR_TOP pavillon.
• si vous voulez désactiver votre application du point de vue DDMS Eclipse, il vaut mieux qu'elle ne soit pas au premier plan, ou elle va se redémarrer. Vous devez appuyer sur le bouton Accueil d'abord, et puis tuer le processus.

toutes mes applications ont des boutons d'arrêt... et je reçois très souvent des commentaires positifs de la part des utilisateurs à cause de cela. Je me fiche que la plateforme ait été conçue d'une manière dont les applications ne devraient pas en avoir besoin. Dire "ne les mettez pas là" est un peu ridicule. Si l'utilisateur veut quitter... Je leur donne l'accès pour faire exactement cela. Je ne pense pas qu'il réduit la façon dont fonctionne Android du tout et semble comme une bonne pratique. Je comprends le cycle de vie... et mon observation a été que Android ne fait pas un bon travail lors de la manipulation.... et c'est un fait.

arrêtez de penser à votre application comme une application monolithique. Il s'agit d'un ensemble d'écrans UI que l'utilisateur peut interagir avec votre "application", et "fonctions" fournis via les services Android.

ne pas savoir ce que votre application mystérieuse "fait" n'est pas vraiment important. Supposons qu'il s'infiltre dans un intranet d'entreprise super sécurisé, effectuant une certaine surveillance ou interaction et reste connecté jusqu'à ce que l'utilisateur "quitte l'application". Parce que ton département informatique les commandes, les utilisateurs doivent être conscients quand ils sont DANS ou HORS de l'intranet. Par conséquent, votre mentalité de étant important pour les utilisateurs de "quitter".

C'est simple. Faites un service qui place une notification continue dans la barre de notification en disant "je suis dans l'intranet, ou je cours". Demandez à ce service d'exécuter toutes les fonctionnalités dont vous avez besoin pour votre application. Avoir des activités qui se lient à ce service pour permettre à vos utilisateurs d'accéder aux bits D'UI dont ils ont besoin interagir avec votre "application". Et avoir un Menu Android - > quitter (ou déconnexion, ou autre) bouton qui dit au service de quitter, puis ferme l'activité elle-même.

C'est, pour toutes fins utiles, exactement ce que vous dites que vous voulez. Fait à la façon Androïde. Regardez Google Talk ou la Navigation Google Maps pour des exemples de cette" sortie " est mentalité possible. La seule différence est que le fait d'appuyer sur le bouton back hors de votre activité pourrait laisser votre processus UNIX à l'affût dans le cas où l'utilisateur veut relancer votre application. Ce n'est pas vraiment différent d'un système d'exploitation moderne qui cache des fichiers récemment consultés en mémoire. Après que vous ayez quitté votre programme windows, très probablement les ressources dont il avait besoin sont encore dans la mémoire, attendant d'être remplacé par d'autres ressources car ils sont chargés maintenant qu'ils ne sont plus nécessaires. Android est la même chose.

je ne vois vraiment pas votre problème.

il s'agit d'une discussion intéressante et perspicace avec tant d'experts contribuant. Je pense que ce post devrait être retracé de l'intérieur du site principal de développement Android, parce qu'il ne tourne autour de l'un des conceptions de base de L'OS Android.

je voudrais aussi ajouter mes deux cents ici.

Jusqu'à présent, J'ai été impressionné par la façon dont Android gère les événements du cycle de vie, apportant le concept d'une expérience de type web aux applications natives.

ayant dit que je crois toujours qu'il devrait y avoir un bouton quitter . Pourquoi? ... pas pour moi ou Ted ou n'importe lequel des gourous de la technologie ici, mais dans le seul but de répondre à une demande de l'utilisateur final.

bien que je ne suis pas un grand fan de Windows, mais il ya longtemps, ils ont introduit un concept que la plupart des utilisateurs finaux sont habitués à (un bouton X) ... "Je veux arrêter l'exécution d'un widget quand" je "veux".

ça ne veut pas dire quelqu'un (OS, développeur?) prendra en charge qu'à sa/son/sa propre discrétion... cela signifie simplement "où est mon bouton X rouge auquel je suis habitué". Mon action devrait être analogue à "mettre fin à un appel en appuyant sur un bouton", "éteindre l'appareil en appuyant sur un bouton", et ainsi de suite ... c'est une perception. C'est une satisfaction en soi que mon action atteigne effectivement son but.

même si un développeur peut mystifier ce comportement en utilisant les suggestions données ici, la perception encore reste c.-à-d. une application doit cesser complètement de fonctionner (maintenant), par une source indépendante, fiable et neutre (OS) sur demande de l'utilisateur final.

Vous peut cesser de fumer, soit en appuyant sur le Retour ou en appelant finish() dans votre Activity . Appelez simplement finish() à partir d'un MenuItem si vous voulez explicitement le tuer.

Romain ne dit pas que cela ne peut pas être fait, juste que c'est inutile - les utilisateurs n'ont pas besoin de se soucier de quitter ou de sauver leur travail ou quoi que ce soit, car la façon dont le cycle de vie de l'application fonctionne vous encourage à écrire un logiciel intelligent qui sauvegarde et restaure automatiquement son état, quoi qu'il arrive.

ce débat se résume à la vieille question de savoir si les développeurs savent mieux ou si l'utilisateur sait mieux. Les designers professionnels dans tous les domaines des facteurs humains luttent avec cela chaque jour.

Ted a fait remarquer que l'une des applications les plus téléchargées sur le marché est L'App Killer. Les gens obtiennent un peu de sérotonine supplémentaire quand ils arrêtent les applications. Ils y sont habitués avec un ordinateur de bureau/portable. Il garde les choses se déplacer rapidement. Ça garde le processeur au frais. et le ventilateur de tourner sur. Il utilise moins d'énergie.

quand vous considérez qu'un appareil mobile est un navire beaucoup plus petit, alors vous pouvez particulièrement apprécier leur incitation à "jeter par-dessus bord ce dont vous n'avez plus besoin". Maintenant, les développeurs D'Android ont raisonné que L'OS sait mieux et que quitter une application est antique. Je le soutiens sans réserve.

cependant, je crois aussi que vous ne devriez pas frustrer l'utilisateur, même si cette frustration est portée de leur propre ignorance. Pour cette raison, je conclus qu'avoir une option "Quitter" est une bonne conception, même si c'est surtout un bouton placebo qui ne fait rien de plus que de fermer la vue.

Ted, ce que vous essayez d'accomplir peut être fait, peut-être pas comme vous le pensez en ce moment.

je vous suggère de lire sur les activités et les Services. Arrêtez d'utiliser le terme "app" et commencez à faire référence aux composantes, c.-à-d. L'activité, le Service. Je pense que vous avez juste besoin d'en savoir plus sur la plateforme Android; il s'agit d'un changement de mentalité à partir d'une application PC standard. Le fait qu'aucun de vos messages n'a eu le mot "activité" (sauf une citation FAQ, i.e. pas vos mots) en eux me dit que vous avez besoin de lire plus.

Blog post " quand inclure un bouton de sortie dans les applications Android (indice: jamais) explique loin, loin mieux que je ne peux. J'aimerais que tous les développeurs Android l'aient déjà lu.

extraits:

d'après mon expérience, ce que [les utilisateurs] veulent vraiment est: une façon sans équivoque de garantir qu'une application cessera de consommer ressources (batterie, cycles CPU, transfert de données, etc.).

de nombreux utilisateurs perçoivent qu'un bouton de sortie met en œuvre cette exigence et de demander à être ajouté. Développeurs, cherchant à plaire à leurs utilisateurs, complaisamment en ajouter un. Peu après, ils échouent tous les deux.

• dans la plupart des cas, le bouton de sortie appelle simplement Activity.finish() . C'est exactement équivalent à appuyer sur le bouton arrière. exactement. les Services continuent de fonctionner et les sondages continuent de se faire. Les utilisateurs peuvent penser qu'ils ont tué l'application, mais elles n'ont pas, et à bientôt ils seront encore plus fâchés.
• le comportement de sortie est maintenant ambigu. Votre bouton de sortie devrait-il simplement fermer L'activité, ou devrait-il également arrêter tous les Services, récepteurs et alarmes associés? Que doit faire retour ? Que se passe-t-il s'ils frappent Home à la place? Qu'advient-il si votre application dispose d'un widget? Le bouton "exit" devrait-il empêcher la mise à jour?

la solution est de faire le bouton arrière se comporter comme vous attendez le bouton de sortie. Mieux encore, il suffit d'arrêter de consommer des ressources à chaque fois l'application n'est pas visible.

allez-y, lisez l'article complet.

je pense que le point est qu'il n'est pas nécessaire de quitter l'application, sauf si vous avez buggy logiciel. Android quitte l'application lorsque l'utilisateur ne l'utilise pas et que l'appareil a besoin de plus de mémoire. Si vous avez une application qui doit exécuter un service en arrière-plan, vous voudrez probablement un moyen de désactiver le service.

par exemple, Google Listen continue à diffuser des podcasts lorsque l'application n'est pas visible. Mais il y a toujours le bouton pause pour désactiver le podcast lorsque l'utilisateur est fait avec elle. Si je me souviens bien, écoutez, même mettre un raccourci dans la barre de notification pour que vous puissiez toujours accéder au bouton pause rapidement. Un autre exemple est une application comme une application twitter par exemple qui scrute constamment un service sur internet. Ces types d'applications devrait vraiment permettre à l'utilisateur de choisir la fréquence à interroger le serveur, ou si le même sondage dans un thread d'arrière-plan.

si vous avez besoin d'avoir un code qui s'exécute sur exit, vous pouvez outrepasser onPause(), onStop(), ou onDestroy (). http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle

si vous êtes incapable de comprendre comment rendre vos données/connexions (et donc votre" application") persistantes, alors vous serez incapable de faire ce que vous" besoin " de faire avec Android.

ceux qui téléchargent ces mignonnes petites applications tueurs trouvent généralement qu'ils n'aident pas la vie de la batterie ou l'utilisation de la mémoire, mais empêchent le système D'exploitation de faire son travail de gérer la mémoire efficacement...

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

je considère la lecture "Android sans Fil le Développement de l'Application" publié par Addison-Wesley. Je suis en train de le finir et il est très complet.

Il semble que vous avez quelques malentendus fondamentaux de la plate-forme Android. Moi aussi j'étais un peu frustré au début avec le cycle de vie des applications Android apps, mais après être arrivé à une meilleure compréhension, je suis venu à vraiment apprécier cette approche. Ce livre répondra toutes vos questions et bien plus encore. C'est vraiment la meilleure ressource que j'ai trouvé pour les nouveaux développeurs Android.

aussi, je pense que vous devez laisser aller d'un port ligne-pour-ligne de l'application existante. Afin de porter votre application à la plate-forme Android, une partie de la conception de l'application va changer. Le cycle de vie des applications utilisé est nécessaire car les appareils mobiles disposent de ressources très limitées par rapport aux systèmes de bureau et permettent aux appareils Android d'exécuter plusieurs applications. d'une manière ordonnée et attentive aux ressources. Faites une étude plus approfondie de la plate-forme, et je pense que vous vous rendrez compte que ce que vous voulez faire est tout à fait faisable. Le meilleur de la chance.

soit dit en passant, je ne suis aucunement affilié à Addison-Wesley ou à toute personne ou organisation associée à ce livre. Après avoir relu mon billet, je me sens un peu fanboyish. J'ai vraiment, vraiment aimé et trouvé ça très utile. :)

réponse: (Romain Guy): l'utilisateur ne le fait pas, le système gère ceci automatiquement. C'est ce que le cycle de vie de l'activité (en particulier onPause/onStop/onDestroy). Quoi que vous fassiez, ne pas mettre un "quitter" ou "quitter" bouton de l'application. il est inutile avec Android modèle d'application. Cela est également contraire à la façon dont les applications de base travail.

1: le retrait total d'une demande peut être unmandatory, mais il n'est pas inutile. Et si windows n'avait pas d'option de sortie? Le système serait lent car la mémoire était pleine et L'OS a dû deviner à quels programmes vous avez été fait avec. Je me fiche de ce que Romain Guy ou même Larry Page et Sergey Brin disent - ce sont des faits incontestables: les systèmes fonctionnent plus lentement quand ils doivent tuer des tâches pour obtenir leur mémoire avant qu'une nouvelle application puisse être lancée. Vous ne pouvez pas me dire qu'il ne faut pas de temps pour tuer une application! Même la lumière des étoiles lointaines prendre du temps... Il est une certaine utilisation pour permettre à l'utilisateur de fermer complètement les applications.

2: contrairement à comment les applications de base fonctionnent? Qu'est-ce que ça veut dire? Quand j'ai fini d'exécuter une application pour le moment, elle ne fait plus aucun travail...elle attend juste d'être tuée par L'OS quand sa mémoire est nécessaire.

en résumé, il y a une différence nette entre la minimisation et la sortie, et aucune pinch hits bien pour l'autre. Ne nous laissons un tournevis dans chaque vis? Ou d'une clé dans chaque porte? Est-ce qu'on laisse tous nos appareils sous tension jusqu'à ce que le disjoncteur explose et qu'on doive allumer un autre appareil? Ne nous laissez le lave-vaisselle plein de plats et de prendre suffisamment à chaque fois pour faire de la place pour une nouvelle sale? On laisse toutes les voitures rouler dans l'allée jusqu'à ...

si l'utilisateur veut minimiser une application, alors la meilleure chose est de la minimiser. Si un utilisateur veut quitter une application, puis par tous les moyens, il est meilleur à la sortie.

est-il désapprouvé? C'est la vue D'Androïde - ils froncent les sourcils sur elle. Et de nombreux développeurs indépendants rookie Android froncent les sourcils.

mais quand on en arrive là, il y a un bon codage et un mauvais codage. Il existe de bons modèles de flux de programmes et de mauvais modèles de flux de programmes.

laisser les programmes en mémoire quand l'utilisateur sait qu'ils sont faits avec eux tout simplement n'est pas un bon flux de programme. Il sert absolument pas but que ce soit, et il ralentit les choses lors du lancement de nouvelles applications ou lors de l'exécution des applications allouer plus de mémoire.

c'est un peu comme votre voiture: il y a des moments où vous la laissez en marche, comme s'arrêter à un feu d'arrêt, ou peut-être que le fast food traverse, ou s'arrêter au guichet automatique. Mais il existe d'autres situations où vous ne voulez l'éteindre, comme lorsque vous vous rendez au travail, ou à l'épicerie ou même à la maison.

de Même, si vous jouez à un jeu et le téléphone sonne, oui. Arrêtez le jeu et continuez à le faire tourner. Mais si l'utilisateur est fait avec le jeu pendant un certain temps, alors par tous les moyens laissez-les sortir.

exit sur certaines applications devraient être plus en avant que d'autres. Par exemple, les jeux ou les programmes où l'utilisateur est susceptible de vouloir sortir complètement, devraient avoir un évident sortie. D'autres programmes, comme, peut-être, les programmes de courrier électronique, où la sortie est un désir peu probable (de sorte qu'il peut continuer à vérifier pour le courrier électronique) -- ces les programmes ne devraient pas gaspiller l'espace de l'écran d'entrée de prime control avec une option de sortie, mais pour un bon flux de programme, il devrait avoir une option de sortie. Que se passe-t-il si quelqu'un décide qu'il ne veut pas que son programme de messagerie essaie de vérifier le courrier électronique alors qu'il est dans une zone de faible couverture, ou peut-être dans un appel Skype ou autre? Les laisser quitter le programme de messagerie si elles veulent!

suspendre et quitter sont deux tâches essentielles et ne remplissent pas le rôle de l'autre.

presque 99% du temps, il n'est pas nécessaire d'une application Android pour prendre en charge son propre cycle de vie. La plupart du temps, il s'agit d'une meilleure planification ou d'une conception plus intelligente de l'application. Par exemple, construisez plutôt un service interne (non exporté) pour gérer les téléchargements, etc., ou concevoir des actions et des tâches autour du flux de travail de l'utilisateur.

Mais cela étant dit, où il ya une volonté il ya un chemin. Android est - à-dire par le biais de l'android.OS.Classe de processus, un bien meilleur API than Java pour contrôler le processus sous-jacent. Et contrairement à Java, il ne traite pas le développeur comme un crétin en le cachant derrière un simple java.lang.Système.exit() de l'appel.

alors comment demandez-vous votre demande pour se suicider dans Android? L'astuce est simple:

créez votre propre classe D'application Android en héritant de l'android standard.App.Classe d'Application (n'oubliez pas de la déclarer dans le AndroidManifest.fichier xml).

outrepasser la méthode onCreate (), et stocker le numéro D'identification du processus qui a démarré votre application:

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

maintenant pour tuer votre application, Fournir une méthode kill ():

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

maintenant chaque fois que vous avez besoin de votre application pour commettre le suicide tapez juste le contexte de l'application, et appelez votre méthode de tuer!

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

juste se rappeler qu'en raison des politiques de gestion des processus dans Android, spécifiquement liés à services, Android peut juste opter pour redémarrer votre service (voir vous ne devez pas utiliser les tueurs de tâches sur Android ).

quand je conçois une application dans Android, je le vois de cette façon:

• vous travaillez avec votre application
• Le téléphone a sonné
• Vous prenez l'appel
• à la fin de l'appel, vous revenez à votre demande au même endroit que vous étiez

pour cela, vous n'avez besoin que du bouton retour ou du bouton accueil bouton de votre téléphone (soit par la pression courte ou longue) et la barre de notification.

lorsque je quitte mon application, je n'utilise que le bouton Back jusqu'à ce que j'en sorte ou le bouton Home .

C'est ainsi que la plupart des applications sont conçues, je pense. Mais si j'ai besoin d'une session ou d'une connexion, Je l'ai clairement indiqué à l'utilisateur avec un bouton de connexion/déconnexion et une notification (barre de titre ou autre). Il s'agit d'un style assez différent de la pure application de style "exit".

sur les PC, vous avez un bureau multi-GUI, et sur Android, vous avez évidemment multi-tâches, mais vous n'affichez qu'une application à la fois (je ne considère pas les widgets ici ^^). Et sur un téléphone mobile, à tout moment, vous pourriez avoir une notification pour quelque chose de plus important que ce que vous faites.

donc l'ensemble du concept d'une application reposent sur quelque chose de différent qui " entrer application - le travail - la sortie de l'application".

Hmmmm...

je pense que vous ne voyez pas l'application Android de la bonne façon. Vous pouvez faire quelque chose presque comme ce que vous voulez facilement:

• faire les activités de l'application Enregistrer/restaurer l'état comme il est encouragé dans la documentation du développeur livecycle.

• si une connexion est nécessaire à l'étape de restauration (aucune information de connexion/session disponible) alors faites-le.

• éventuellement ajouter un bouton/menu/timeout dans lequel cas vous ferez un finish() sans enregistrer le login et d'autres informations de session, faisant implicitement la fin de la session de l'application: donc si l'application est démarrée/ramenée au premier plan, il commencera une nouvelle session.

de Cette façon, vous n'avez pas vraiment si l'application est vraiment supprimé de la mémoire ou non.

Si vous voulez vraiment supprimer de la mémoire (ce est découragé, et BTW dans quel but?), vous pouvez le tuer conditionnellement à la fin de onDestroy() avec java.lang.System.exit(0) (ou peut-être restartPackage(..) ?). Bien sûr, le faire seulement dans le cas où vous voulez "vraiment mettre fin à l'application", parce que le onDestroy() fait partie du cycle de vie normal des activités et pas une fin d'application du tout.

comme une Application dans un contexte Android est juste un tas d'activités vaguement liées, quitter une Application n'a pas vraiment beaucoup de sens. Vous pouvez terminer () une activité, et la vue de l'activité précédente dans la pile D'activités sera dessinée.

le noyau Linux a une fonctionnalité appelée out-of-memory killer (comme mentionné ci-dessus, les politiques sont configurables au niveau de l'espace utilisateur aussi bien que le noyau n'est pas optimal, mais en aucun cas inutile).

et il est fortement utilisé par Android:

• OOM killer n'est pas pour userspace

• Android Notes (Oom Killer Info - où vous pouvez configurer la fonctionnalité OOM sur Android)

• Portage D'Android Sur La Cible Réelle

certaines applications userspace sont disponibles pour aider avec ces applications kill, par exemple:

• Autokiller / configurer le tueur de tâches interne D'Android

vous avez apparemment trouvé la réponse que vous voulez dans la commande finish (). Cela ne supprimera pas votre application de la mémoire, mais Android le fera chaque fois qu'il a besoin des ressources, de sorte qu'il ne fait pas de différence que vous ne serez pas le faire explicitement.

je voudrais seulement ajouter que, pour atteindre le plein effet qu'une demande de sortie aurait généralement, vous souhaitez réinitialiser l'application de l'état quel que soit son état est normalement au moment de la première exécution après une botte de l'appareil, juste avant d'appeler finish() sur toutes vos activités. De cette façon, si l'utilisateur sélectionne votre application, il semble avoir été exécuté "frais", " sans aucun état laissé par le point avant la simulation "de sortie."

S'il y a des actions spéciales qui ne devraient se produire que sur" exit", comme sauvegarder le travail de l'utilisateur ou autre, vous pouvez également les exécuter avant la partie re-initialisation de la routine ci-dessus.

This approche vous permet d'atteindre votre objectif d'avoir une commande "exit" sans violer la philosophie D'Android de laisser la gestion des ressources OS, y compris la fermeture des applications, dans les mains du système d'exploitation.

personnellement, je n'utiliserais pas cette approche, parce que les utilisateurs Android s'attendent à ce qu'une application préserve sa continuité lorsqu'ils la revisitent, et donc ils ne sont pas habitués à la modalité de" quitter " une application. Je soutiendrais plutôt une fonction "clair" qu'un utilisateur peuvent appeler pour réinitialiser l'application d'un manquement de l'état initial, sans la nécessité de "quitter" dans le processus.

la seule exception serait lorsque l'Utilisateur a appuyé sur le bouton arrière un nombre suffisant de fois pour provoquer la fermeture de l'application. Dans cette situation, il n'y a aucune attente de la part de l'utilisateur que l'État ait été sauvegardé (et s'il y a un état non sauvegardé dans l'application, alors vous, en tant que développeur, devriez avoir du code qui manipule le bouton de retour qui détecte que non sauvegardé données, et invite l'utilisateur à le sauvegarder sur SharedPreferences ou sur un fichier, ou sur un autre support non volatile).

concernant le système.sortie (0):

Si vous décidez d'utiliser le système.exit (0) pour fermer votre application avec une finalité rude (par exemple, à la suite d'une pression finale sur le bouton arrière), alors je vous avertirais que bien que pour moi cela "fonctionne", et dans certains cas a été le seul moyen que j'ai été en mesure de fermer une application sans aucune trace de celui-ci reste, il y a un petit problème qui se produit dans Jelly Bean lorsque vous utilisez cette approche.

spécifiquement, si vous utilisez la liste des applications récentes pour ouvrir votre application, puis utilisez le bouton Précédent pour fermer l'application (avec cette fermeture implémentée via le système.exit (0)), la liste des applications récentes sera à nouveau visible, car elle n'aura jamais été fermée. Si vous appuyez ensuite sur l'entrée de votre application dans cette liste pour l'exécuter une deuxième fois de la même, déjà-ouvert, Liste des applications récentes, il n'y aura pas de réponse.

je soupçonne que la cause de cela est que la récente liste des applications s'accroche à une référence à votre application qui est devenue non-fonctionnelle en raison de votre avoir fermé l'application en utilisant le système.exit (0). Une fermeture plus civilisée de votre application en utilisant finish () aurait pu informer L'OS d'une manière qui lui aurait permis de rafraîchir sa récente liste D'applications, mais système.exit (0) ne fait apparemment pas cela.

C'est ce n'est pas un gros problème en soi, car très peu de gens vont ouvrir une application à partir d'applications récentes, puis la quitter, et l'ouvrir immédiatement à nouveau à partir de la même Liste d'applications récentes ouvertes. Et s'ils tapent le bouton home et puis rouvrir la liste des applications récentes, l'entrée de votre application sera là, et il sera entièrement fonctionnelle. Mais je pense qu'il montre que l'utilisation du système.exit(0) peut interférer avec la bonne communication entre votre application et le système d'exploitation, et cela suggère qu'il pourrait y avoir d'autres conséquences, plus graves, peut-être subtiles, de cette approche.

Je suis D'accord avec Ted. Je comprends que la sortie de la demande n'est pas "Androïde", mais il ne semble pas que cela devrait être exclu. Ici sont trois raisons pour lesquelles vous pourriez vouloir une sortie réelle à l'application (pas juste l'activité):

1. l'utilisateur pourrait vouloir un certain contrôle sur l'application qui est tué dans le cas de mémoire faible. Si Une application est en cours d'exécution en arrière-plan, ensuite, vous pouvez quitter l'application B lorsque vous avez fini avec elle si cette application ne se fait pas tuer par le système d'exploitation.

2. si votre application dispose de données sensibles mises en cache en mémoire, vous pourriez comme de tuer l'application de sorte qu'un virus/ver de/app voleur ne pouvez pas obtenir. Je connaître le modèle de sécurité est censé l'empêcher, mais juste au cas où...

3. si votre application utilise des ressources (réseau, CPU, capteurs, etc.)) cela pourrait nuire au téléphone, puis une façon de veiller à ce que ces ressources sont libérées est de quitter l'application. Je comprends que les applications bien comportées devraient libérer des ressources quand ils ne sont pas nécessaires. Mais encore une fois, le fait de quitter l'application semble être un moyen raisonnable de s'en assurer.

il y a une conception (relativement) simple qui vous permettra de contourner l'énigme de la" sortie". Faites votre application avoir un État" de base " (activité) qui est juste un écran blanc. Sur la première onCreate de l'activité, vous pouvez lancer une autre activité principale de votre application fonctionnalité est en. La "sortie" peut alors être réalisée en terminant cette deuxième activité et en retournant à la base d'un écran vide. Le système d'exploitation peut garder cet écran vide en mémoire aussi longtemps qu'il le veut...

en essence, parce que vous ne pouvez pas sortir vers OS, vous transformez simplement en un rien créé par vous-même.

j'espère que les choses changeront avec le temps. L'utilisateur doit être capable de tuer une application ou un processus si le processus de l'application est sabboxé correctement par le système D'exploitation. Il y a une notion selon laquelle les applications doivent être parfaitement écrites ou l'utilisateur n'utilisera que les applications qui suivent toutes les recommandations SDK. Je pense que c'est un défi de taille.

tout d'abord, jamais Ne jamais utiliser le système.exit (0). c'est comme endormir une personne en lui donnant un coup de poing sur la tête!

Deuxième: je suis confronté à ce problème. Avant de partager ma solution, je veux partager mes pensées.

je pense qu'un "Bouton de Sortie" est stupide. Vraiment vraiment très stupide. Et je pense que les utilisateurs (consommateurs) qui demandent un bouton quitter pour votre application est stupide aussi. Ils ne comprennent pas comment l'OS fonctionne et comment est la gestion des ressources (et il fait un excellent travail).

je pense que si vous écrivez un bon morceau de code qui fait les bonnes choses (mises à jour, sauve, et pousse) au bon moment et les conditions et en utilisant les choses correctes (Service et récepteur) il fonctionnera assez bien et personne ne se plaindra.

mais pour ce faire, vous devez étudier et apprendre comment les choses fonctionne sur Android. Quoi qu'il en soit, c'est ma solution pour fournir aux utilisateurs un "bouton de sortie".

j'ai créé un Menu Options toujours visible dans chaque activité (j'ai une super activité qui fait ça).

Lorsque l'utilisateur clique sur ce bouton, c'est ce qui se passe:

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

donc j'économise en références partagées que je veux tuer mon application, et je commence une intention. S'il vous plaît regardez ces drapeaux; ceux-ci nettoieront tous mon dos appeler mon activité de Tableau de bord qui est mon "maison" activité.

donc dans mon Activité du tableau de bord j'utilise cette méthode dans le résumé:

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

et ça marchera plutôt bien.

la seule chose que je ne comprends pas pourquoi cela se produit est que lorsque je fais la dernière finition (et j'ai vérifié: il suit tout le flux correct de onPause → onStop → onDestroy) l'application est toujours sur l'activité récente (mais il est vide).

il semble comme la dernière intention (qui a commencé la DashboardActivity) est toujours dans le système.

je dois creuser plus afin de l'enlever aussi.

sans une fonction de sortie pour le développeur d'application de tuer leur propre application, il est très mauvaise conception.

mon application doit permettre à l'utilisateur de changer dynamiquement les données dynamiquement pendant l'exécution et l'utilisateur doit redémarrer mon application pour faire l'effet de changement, mais Android n'a pas permis à mon application redémarrer par lui-même. Android OS a un très mauvais cycle de vie de l'application de conception.

il m'a fallu plus de temps pour lire cette Q&r que d'implémenter un cycle de vie D'application Android semi-approprié.

c'est une application GPS qui recherche des points et envoie l'emplacement actuel à un service Web toutes les quelques secondes à l'aide d'un thread... Cela pourrait être un sondage toutes les 5 minutes dans le cas de Ted pour une mise à jour, puis onStop peut simplement commencer l'activité de mise à jour Ted était tellement préoccupé si on en trouvait une (asynchrone Ted, ne code pas comme un programmeur Windows ou votre les programmes tournent comme les programmes Windows ... pouah, c'est pas dur).

j'ai fait un code initial dans onCreate pour mettre en place des choses pour la vie de l'activité, y compris 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();
}

ce code peut être complètement erroné, mais il fonctionne. C'est l'une de mes premières applications Android.

Voilà, une application qui ne consomme pas CPU quand il est à l'arrière-plan, mais est immédiatement prêt à rouvrir parce qu'il est en RAM (bien que ne possédant pas la RAM comme c'est le cycle de vie de L'Android) ... une application est toujours prête, c'est un téléphone, les gars/filles. Si une application devait utiliser toute la RAM et ne pouvait pas être arrêtée par L'OS alors la chose pourrait arrêter de sonner =P C'est pourquoi L'OS a besoin d'être en mesure de fermer votre application quand il est à l'arrière-plan (si votre application n'est pas un hog de Ressource il ne sera pas fermé BTW), alors écrivons juste de meilleures applications.

pour fermer une application à n'importe quel point utiliser FLAG_ACTIVITY_CLEAR_TOP drapeau dans L'intention et puis system.exit();

Ou il n'y a même façon, mais sans system.exit() si vous voulez quitter appeler cette méthode:

public void exit() {
    startActivity(new Intent(this, HomeActivity.class).
    setFlags(Intent.FLAG_ACTIVITY_NEW_TASK | IntentCompat.FLAG_ACTIVITY_CLEAR_TASK).putExtra(EXIT_FLAG, true));
}

dans votre HomeActivity.onCreate() ajouter le code suivant

protected void onCreate(Bundle savedInstanceState) {
    if (getIntent().getBooleanExtra(EXIT_FLAG, false)) {
        if ((getIntent().getFlags() & Intent.FLAG_ACTIVITY_LAUNCHED_FROM_HISTORY) == 0) {
            finish();
        }
    }
......................

cela fonctionnera sans briser le cycle de vie de L'Androïde.

chaque fois que vous passez à la page suivante par intention, utilisez:

`YourActivityname.this.finish()`;

exemple:

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

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

de sorte qu'aucune activité ne sera en cours d'exécution sur le fond et quand vous voulez Exit votre application, utiliser:

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

Cette sortie a fonctionné comme un charme pour moi :)

le cycle de vie de L'application Android est conçu pour les utilisateurs de téléphone mobile, pas les utilisateurs d'ordinateur.

le cycle de vie de l'application est le paradigme brutalement simpliste requis pour transformer un serveur Linux en un appareil de consommation.

Android est Java sur Linux, un vrai serveur multiplateformes OS. C'est comme ça que ça s'est propagé si vite. Le cycle de vie de l'application englobe la réalité sous-jacente de L'OS.

Pour les utilisateurs mobiles, les applications sont juste installé ou non installé. Il n'y a pas de concept de fuite ou de sortie. En fait, les processus app sont conçus pour fonctionner jusqu'à ce que L'OS les libère pour leurs ressources détenues.

Puisqu'il s'agit d'un débordement de pile, toute personne lisant ceci est un utilisateur d'ordinateur et doit désactiver 90% de ses connaissances pour comprendre le cycle de vie de l'application mobile.

dans tous les cas, si vous voulez résilier votre application, vous pouvez toujours appeler System.exit(0); .

si vous avez 10,20 .. plusieurs activités en cours d'exécution et vous voulez terminer tous les et sortir du système.

crée un réseau statique dans application class ou constants class.

constantes

public class Constants {

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

}

activité principale ajouter la référence d'activité courante dans ce tableau

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

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);
            }
        });
    }
}