2010-12-08 42 views
6

si vous avez une application Android qui a plus d'une activité, et l'activité A démarre B, donc si l'activité b bloque le processus est tué, mais est rétabli par android OS et recommence l'activité A au lieu de simplement fermer l'application, pourquoi ?Pourquoi android «fait-il revivre» les applications qui se brisent?

+0

Est-ce que ça fait revivre A, ou simplement tuer B? – blindstuff

+0

il redémarre tout le processus, mais démarre avec onCreate et onStart seulement A, si vous avez un qui commence B qui commence C et C a eu une exception de plantage puis Android commencerait le processus de demande et mettre B sur le premier plan, si vous appuyez sur La touche 'retour' vous donnera A à nouveau, bien qu'elle appelle de nouveau A onCreate. – codeScriber

+0

Ouais, j'ai essayé ce que vous avez mentionné, vous semblez avoir raison, bien que parfois je l'obtienne toujours de revenir à A. J'espère que quelqu'un connaît la réponse. – blindstuff

Répondre

4

Vous vous plaignez qu'Android tentera de récupérer l'état de votre application après un crash? ;)

Ceci est le résultat de la gestion des ressources d'Android et du cycle de vie de l'activité au travail. Gardez à l'esprit qu'une seule tâche peut être composée d'un certain nombre d'activités pouvant s'étendre sur plusieurs processus ou applications. Comme indiqué ici: http://android-developers.blogspot.com/2010/04/multitasking-android-way.html Les processus Android ne s'arrêtent pas "proprement" dans le sens traditionnel du processus nix. Les composants de votre application reçoivent des événements de cycle de vie, mais après un certain point, l'application peut être supprimée sans avertissement supplémentaire afin que le système puisse récupérer ses ressources. Par exemple, un utilisateur peut naviguer sur le Web, cliquer sur un lien YouTube pour lancer l'application YouTube, puis cliquer sur un bouton de partage pour lancer son application de réseau social préférée et publier le lien vidéo. Tout cela fait partie de la même tâche. Si l'utilisateur appuie plusieurs fois sur le bouton, il reviendra sur la page dans le navigateur à partir duquel il a démarré. Une fois que vous démarrez l'application de réseau social, le système peut décider que la mémoire est insuffisante et que le processus du navigateur va en perdre davantage. (Après tout, ce n'est pas à l'avant et l'utilisateur ne s'en apercevra pas.) Lorsque l'utilisateur appuie sur le bouton retour pour revenir à l'activité du navigateur, il redémarre et reconstruit le dernier état où l'utilisateur l'a quitté. Au pire, l'utilisateur subit un court délai pendant que les choses se réinitialisent. Mais cette même séquence d'événements restaure un état d'activité précédent, même dans la même application au cours du même processus. Dans votre scénario, l'activité B s'est fermée à la suite du crash. Ainsi, le système fait exactement ce qu'il fait toujours: il revient à l'activité précédente: Activité A. Mais le processus de l'activité A n'est pas encore là (il s'est écrasé!), Le système le redémarre et peut reconstruire son état précédent.

+0

c'est vrai ce que vous dites, cependant dans le logcat vous pouvez voir que même si l'application a reçu le signal 3 (tuer gracieusement) il meurt encore méchamment, signifiant non onDestroy et l'onTerminate de l'application est appelée. Je ne me plains pas, mais je suis un peu gênant pour moi spécifiquement et je pensais que ce serait bien s'il y avait un moyen d'arrêter cela parce qu'il y a tellement d'aspects de tâches et de processus qui peuvent être changés. – codeScriber