Détails de la destruction et des loisirs des composants d'applications Android

Quelqu'un pourrait-il me pousser dans la direction de certaines informations concrètes, dignes de confiance (et de préférence concises) sur ce qui suit:

  1. L'ordre dans lequel les composants sont détruits et (le cas échéant) recréés par le système (Fragment, Activité, Threads / AsyncTasks / Timers de l'activité, données statiques (quand les classes sont-elles déchargées?), Threads / AsyncTasks / Timers dans d'autres classes, host TabActivity, Groupe d'activités, services locaux liés, application, processus) à la fois lorsque l'application est en arrière-plan et au premier plan.
    À quels points, la destruction peut s'arrêter (quels états peuvent être rencontrés lors du retour à l'application – comme «tout, y compris l'objet Application détruit, processus en vie»?

  2. Android LatinIME build
  3. HTML5 vidéo - cadre recherche précise sur les appareils Android?
  4. Convertir InputStream en BufferedReader
  5. Android - Impossible de détruire l'activité après la fin, causée par IllegalStateException: Impossible d'effectuer cette action après onSaveInstanceState
  6. Obtenez de la valeur (String) de ArrayList <ArrayList <String >> (); En Java
  7. La bibliothèque d'annonces PlayServices 7.5.0 nécessite l'autorisation WRITE_EXTERNAL_STORAGE
  8. Est-il possible (sans modifier Android) de provoquer par programmation le même genre de destruction, de sorte qu'il soit impossible de distinguer quand le système le fait, ou un mécanisme distinct est-il nécessaire lorsque nous choisissons de libérer de la mémoire (déclenchée par onLowMemory)?

  9. Des étapes de reproduction fiables de tous les scénarios à partir de 1) (cela ne fonctionnerait-il pas?

  10. " Si l'utilisateur quitte une tâche pendant une longue période, le système efface la tâche de toutes les activités, à l'exception de l'activité racine. Lorsque l'utilisateur retourne à la tâche à nouveau, seule l'activité racine est restaurée ": est-ce en dehors du processus / composant Cycle de vie / destruction, ou attaché à elle?

J'ai lu diverses sources pour donner des informations, souvent incomplètes et trompeuses, parfois incorrectes.
Je l'avoue, j'ai écris certaines parties de la documentation, donc j'ai peut-être manqué ou mal compris quelque chose.

[EDIT] Pour éviter les malentendus: ce que je demande, c'est Android détruisant des composants pour libérer de la mémoire, en contournant Activity.onDestroy.
Lorsque je mets l'application en arrière-plan et que je retourne plus tard, l'une de ces séquences se produira:

  • OnPause, onStop, onRestart, onStart, onResume
  • OnPause, onStop, Application.onCreate, onCreate (notNull), onStart, onResume

[EDIT2] Bounty a commencé. Besoin d'informations fiables sur: Activités, Fragments, Application, services liés (potentiellement à distance), processus.
Scénarios de destruction partielle / complète. Voir 1er point.

  • Peut définirDisplayShowTitleEnabled être défini dans xml au thème d'un ActionBar?
  • Android: comment débloquer sans relâche un service
  • Le poids de l'Android ne fonctionne pas correctement
  • Pourquoi mon compte Facebook android sdk est-il appelé deux fois?
  • Volley JSONException: fin de l'entrée au caractère 0 de
  • Fragment n'a pas créé de vue
  • 6 Solutions collect form web for “Détails de la destruction et des loisirs des composants d'applications Android”

    Le crédit pour cela passe à hackbod pour l'écrire ici (lire la réponse complète), et à CommonsWare pour lier un commentaire.

    En bref: Tous les documents , réécrit plusieurs fois, continuent de nous mentir. Ils ne trompent pas, ils nous donnent des informations fausses. Sauf si vous utilisez Fragments (si le support v4 compte aussi), l'Android libère de la mémoire en tue tout le processus ou ne fait rien.

    Bien sûr, cela ne répond pas à tout:

    • Point 4 de la question
    • Pourquoi j'ai souvent vu onCreate (notNull) en appuyant de nouveau sur une pile d'activités avec les activités de gestion de toutes les modifications de configuration (Android 2.3.7)
    • Comment cela se rapporte à la croyance largement acceptée que onPause est le dernier appel que vous êtes certain d'obtenir, et onStop peut ne jamais être appelé (comment, puis, l'application peut-elle passer à l'arrière plan pour être tuée?)

    Nous en arrivons quelque part.

    C'est ce que mon expérience, et celle des développeurs que j'ai posée, semble suggérer:

      • Les fragments ne sont pas autodestinés.
      • Les activités non visibles sur la pile de l'application peuvent être autodestinées dans n'importe quel ordre et dans n'importe quel nombre.
      • Détruit l'activité (ou toute autre classe) Les threads et la statique restent intacts jusqu'à ce que l'application soit détruite.
      • TimerTasks: n'a pas testé.
      • Services locaux liés: détruits quelque part entre la destruction de la dernière activité obligatoire et de la demande.
      • L'application est la dernière chose à suivre dans un processus, et "va" avec tous les threads.
      • Le processus peut exister pendant une longue période (20 minutes) après la destruction de l'objet Application, sauf si vous avez un tueur automatique de tâches.
      • Les activités sous TabActivity ou dans ActivityGroups ne sont pas autodestinées, mais allez tout en même temps si le conteneur est détruit.
        Exemple: une activité TabActivity avec ActivityGroups sous les onglets. Toutes les activités en direct. Une autre activité est démarrée, en plein écran. Le TabActivity avec tout ce qu'il contient est maintenant admissible à la destruction par Android, tout à la fois ou pas du tout.
    1. NO .
      Si vous détruisez manuellement une activité, elle passe à travers le cycle de vie entier et ne passe pas un Bundle à onCreate lorsque vous lancer à nouveau.
      En outre, onLowmemory n'est pas fiable – même avec de petites étapes d'allocation, il ne sera jamais appelé avant que OutOfMemoryError ne soit lancé.
    2. NO .
      Bien que l'autodestruction / restauration soit une caractéristique majeure dans Android, il n'y a aucun moyen de tester de tels scénarios.
    3. Cela ne concerne probablement que le processus existant ou non. Si c'est le cas, Android tentera de restaurer les anciennes activités. Sinon, c'est un redémarrage propre.

    Ce qui précède inclut certaines hypothèses.
    J'attends toujours que quelqu'un le confirme et fournisse des docs (les garanties ne dépendent pas de la mise en œuvre actuelle des classes).
    S'il vous plaît, corrigez-moi si l'un de ces problèmes est incorrect.

    Modifier: Les informations ci-dessus peuvent être périmées, elles ont été testées sur Android 2.1-2.3

    Eh bien, mon ami, je suppose que vous aurez beaucoup de problèmes dans votre recherche. Fondamentalement parce que vous parlez de deux boîtes noires: le collecteur de déchets Dalvik et le gestionnaire de tas de l'Android. Je dirais que vous ne pouvez pas croire que l'Android continuera un ordre de destruction d'objet. Mais, vous pouvez croire que ce cycle de vie va être suivi [Programmation Android, 2011]:

    Cycle de vie de l'activité:

    onCreate() - Called after the instance of the activity has been created for the first time onRestart() - Called after an activity has been interrupted, just before the onStart(); onStart() - Called when the object activity and their visions become visible to the user; onResume()- Called when the object activity and their visions become interactive to the user; onPause() - Called when a different instance of the activity is going to get visible and the present activity ceases to interact with the user onStop() - Called when the activity is no longer visible or is not interacting onDestroy() - Called when an activity instance must be destroyed and it's no longer needed. 

    Les fragments ont des cycles de vie différents, y compris les méthodes sur l'accès, surCreateView et onActivityCreated. Mais, pourquoi vous inquiétez-vous de l'ordre des objets de la destruction? Je ne vois aucune raison pour que vous puissiez surveiller de tels événements, mais si vous avez vraiment besoin, en savoir plus sur le collecteur d'ordures.

    1. La méthode ActivityManagerService # trimApplications () supprime tous les processus d'application inutilisés si le récepteur actuel de l'application est nul, n'a aucune activité et aucun service.

    En ce qui concerne les activités, ils ne seront détruits que sur Destroy () jusqu'à ce que, sauf si le développeur appelle manuellement la fonction finish ()

    Le cycle de vie des fragments est complètement adapté à son activité parent, alors, lorsque l'activité parent détruit sur Destroy (), les fragments sur Destroy () seront également appelés.

    Timer Tasks finit leur travail et devient candidat à la collecte des ordures, une fois que l'activité les crée, la tâche s'exécute dans son propre fil, pas de relation avec l'activité, même si l'activité est détruite, la tâche se termine …

    Ce n'est pas une réponse complète, mais ce que je recommande, c'est que vous postulez des messages sur chacune de ces méthodes. Ajoutez votre propre onPause() , onStop() , onResume() , etc. et à l'intérieur, mettez une ligne comme ceci:

     Toast.makeText(this, "onPause()", Toast.LENGTH_SHORT).show(); 

    Vous ne pouvez pas appeler directement ces méthodes, mais le déplacement d'une autre activité vers le haut de la pile entraînera l'appel de ces méthodes sur l'activité existante. Une autre chose à garder à l'esprit est que onCreate() n'a pas besoin d'être appelé chaque fois que vous démarrez une activité. Cela dépend vraiment de la façon dont vous démarrez l'activité, par exemple si vous envoyez cette intention

     Intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK|Intent.FLAG_ACTIVITY_SINGLE_TOP); 

    Il apparaîtra appel onNewIntent() place s'il a déjà été créé. En résumé, la meilleure chose est juste pour regarder les messages Toast. Vous devez également vous concentrer sur l'utilisation du débogueur. Placez un point d'arrêt sur chaque méthode et vous pouvez le voir. Une chose dont je suis sûr est que vous ne pouvez pas invoquer directement ces méthodes comme onPause() . Gardez également à l'esprit que, en général, vous ne savez pas quand on onDestroy() sera appelé.

    coAndroid est un fan Android de Google, tout sur les téléphones Android, Android Wear, Android Dev et Android Games Apps.