Ciclo de vida de la actividad Android más simple

Me di cuenta de que la sección de actividad de desarrolladores de Android se ha actualizado desde que inicié mi aplicación, pero todavía no estoy claro cuál es el ciclo de vida de actividad más sencillo.

Por lo que puedo distinguir:

OnCreate, onResume y onPause son los elementos esenciales.

La actividad se puede eliminar en cualquier momento después de onPause, por lo que debería guardar todo mi estado de aplicación en un archivo onPause y no confiar en onStop o onDestroy. Además, onSaveInstanceState no se llama antes de cada onPause por lo que no es realmente vale la pena usar.

En lugar de intentar escribir cargas de código para manejar todos los escenarios, ¿por qué no destruir la actividad al final de su onPause?

El ciclo de vida sería entonces onCreate y onResume antes de que esté activo, luego onPause cuando se vuelve inactivo. No se necesitarían otros métodos.

Yo usaría onCreate para llamar a setContentView y configurar oyentes de vista, pero todo lo demás se pondría en onResume, incluyendo la carga del estado restaurado de un archivo? Como se dijo anteriormente, onPause guardaría el estado en un archivo y destruiría la actividad.

Por lo que puedo ver, la única desventaja de esto podría ser que cuando un popup está en la pantalla, la actividad se elimina y tiene que ser recreado cuando el popup está cerrado, lo que significa que la actividad no será visible detrás de la ventana emergente No he probado esto)

Puede tomar un poco más de tiempo para reiniciar la actividad, pero como el sistema podría haber eliminado la actividad de todos modos sin previo aviso, tiene que guardar todo el estado de todos modos.

¿Alguna idea?

Actualización: Supongo que lo que estaba pensando era donde una actividad de "primera página" llama a una actividad de juego. La actividad de primera página llamaría a la actividad de juego cuando el jugador hace clic en "Reproducir"

La actividad del juego establecería sus vistas y oyentes, etc. en onCreate, y en onResume cargaría un archivo que contenía el estado del juego, o iniciaría un nuevo juego si no existía ningún archivo.

OnPause del juego, escribe el estado del juego en el archivo, entonces lo que suceda a la actividad del juego (nada, o se detiene / destruye, o lo que sea) el método onResume siempre cargaría todos los datos de nuevo en el archivo.

Eso es lo que estaba pensando, si eso tiene sentido?

Update2: He ideado una solución simple que he documentado en una respuesta a continuación, si alguien está interesado!

No admite los estados de Pausa y Estado detenido del ciclo de vida de la actividad de Android. Una vez que ya no se muestra se mata a sí mismo y tiene que ser reiniciado manualmente, pero sí sigue desde donde lo dejó!

9 Solutions collect form web for “Ciclo de vida de la actividad Android más simple”

¿Estás buscando esto?

Ciclo de vida de la actividad

Para responder más a su pregunta, sí, como se puede ver claramente en el diagrama anterior el ciclo de vida "más simple" (es decir, el número más pequeño de llamadas de método) es en efecto onCreate(); onStart(); onResume(); onPause(); onCreate(); onStart(); onResume(); onPause(); .

También debe saber acerca de onSaveInstanceState() y onRetainNonConfigurationInstance() . Estos NO son métodos de ciclo de vida.

Todos estos métodos están muy bien documentados. Lea detenidamente esta documentación.

Para aclarar las cosas, aquí hay un par de escenarios de la vida real:

  1. La actividad está funcionando, otras actividades vienen encima de él, onPause se llama. El sistema se queda sin memoria, llama a onSaveInstanceState , mata la actividad. El usuario presionado varias veces, la actividad tiene que volver a instanciarse (preferiblemente utilizando los datos guardados en onSaveInstanceState ).
  2. La actividad se está ejecutando, el usuario presiona hacia atrás. En este punto onPause->onDestroy se llaman, sin llamar a onSaveInstanceState .

Usted debe entender la diferencia esencial entre onPause y onSaveInstanceState . El primero se llama siempre , mientras que el último sólo se llama cuando la instancia de actividad podría volver a instanciarse en el futuro. Siguiendo esta línea de pensamiento, sus usuarios esperarán dos cosas:

  1. Cuando navegan lejos de su actividad y más tarde vuelven a ella, lo quieren en la misma instancia exacta que lo dejaron (esto se lograría usando onSaveInstanceState ). No esperan que si salen de su actividad. Sin embargo:
  2. onPause que los datos que han ingresado se mantendrán (lo que se hará en onPause ). Por ejemplo, si comenzaron a componer un mensaje, esperarán verlo como un borrador la próxima vez que regresen, aunque salgan de la actividad.

Usted debe entender cómo se supone que estos métodos se utilizan para obtener lo que sus usuarios esperan. La forma en que usted los utiliza realmente depende de usted, de sus necesidades y de la naturaleza de su aplicación.

El sistema Android gestiona el ciclo de vida: es decir, instancia de actividades y métodos de ciclo de vida de llamadas. Así que no sé lo que quieres decir con "destruir la actividad". Tú, como desarrollador, no tienes tal habilidad.

En segundo lugar, el flujo del ciclo de vida de la actividad puede ser a veces confuso (sé que luché con él al principio). Por lo tanto, sólo implementar todos los métodos de ciclo de vida y poner las declaraciones de registro en ellos. Luego intente todos los casos de uso de la vida real (incluyendo la recepción de una llamada durante el uso de la aplicación) para ver cómo se llaman los métodos del ciclo de vida.

Estaba estudiando el ciclo de vida de la actividad y el proceso completo de lo que sucede cuando se inicia cualquier actividad, a partir de onCreate . Aquí hay un diagrama UML para ayudarte.

Haga clic en este enlace para ver una versión de alta resolución .

Introduzca aquí la descripción de la imagen

La respuesta es tan simple como el ciclo de vida. Sólo reemplazar las devoluciones de llamada cuando necesite manejar cosas allí.

Android siempre llamará a cada callback cómo se supone que, excepto en ciertas circunstancias.

El hecho de que ciertas devoluciones de llamada no están garantizadas para ser llamado no significa que sean inútiles. Simplemente no trate de manejar cosas sensibles en estos métodos de devolución de llamada.

Creo que he encontrado lo que estoy buscando! (Me 1, Bono 0)

Esto es para una sola actividad de 'Juego' que utiliza métodos mínimos para controlar un hilo de 'GameThread' que maneja el juego. Utiliza una clase 'GameData' adicional para almacenar datos que se requiere que sean persistentes entre activaciones.

Si la aplicación pierde el foco (es decir, una llamada telefónica entrante, o el usuario hace clic de nuevo, etc.), Game guarda los datos del juego en un archivo y sale. Para reanudar, sólo tiene que iniciar la aplicación de nuevo y vuelve a donde lo dejó.

El archivo de disposición 'game.xml' es un SurfaceView que cubre toda la pantalla

Game.java:

  1. OnCreate configura el SurfaceHolder para SurfaceView y crea el GameThread
  2. SurfaceChanged llama a GameThread.startThread para iniciar el GameThread, si no se ha iniciado, pasar el tamaño de la pantalla
  3. OnPause llama a GameThread.endThread para finalizar GameThread y finaliza esta actividad
  4. OnTouch pasa eventos táctiles al método GameThread.doTouch

GameThread.java:

  1. StartThread configura datos almacenados localmente, carga GameData desde el archivo e inicia el hilo
  2. Run es un bucle de juego estándar, que llama a actualizaciones estándar de updatePhysics y drawScreen para cada trama. Una vez finalizado el bucle de juego, guarda los datos del juego en el archivo
  3. EndThread detiene el bucle del juego en ejecución y espera a que finalice
  4. Las acciones doTouch tocan eventos de la actividad del juego

Parece funcionar. Significa tener que manejar diferentes pantallas (por ejemplo, pantalla de título, opciones, juego y juego) en el hilo, pero eso no es el fin del mundo, IMHO.

Tal vez voy a publicar el código en CodeReview (voy a actualizar esto si lo hago) y ver si alguien tiene comentarios. Mientras tanto, será mejor que me codifiquen los próximos Angry Birds!

OnCreate () obviamente primero. Su actividad puede entonces ingresar onPause (). A partir de ahí, podría sobreResume () o onDestroy (). Ese es el camino más sencillo a través del ciclo de vida que conozco.

Tuve una actividad que no tenía un método onPause (). A través de una extraña serie de eventos me di cuenta en DDMS que mi aplicación no era visible, pero todavía estaba solicitando freshAds de AdMob 🙂 Niza batería sucker. Eso ya se ha resuelto, pero me recordó lo importante que son las cosas simples.

Lo que personalmente creo es desarrollador debe dividir el trabajo en diferentes estados de la actividad. Secuencia de la obra debe ser retenido en este caso lo que es más importante que pienso y es por eso porque Android no puede manejar un procesamiento de interfaz de usuario largo en un solo hilo y da error que Android tiene 'tanto trabajo que hacer' en Esta referencia que podría ser la causa de conseguir accidente a veces Así que debemos evitar escribir código entero en una sección. El código se escribiría en funciones o clases de diferencia y podemos derivar estas funciones según el requisito. Gracias.

Existen 7 métodos que gestionan el ciclo de vida de la actividad en la aplicación de Android:

  1. OnCreate ()
  2. OnStart ()
  3. En resumen()
  4. OnRestart ()
  5. OnPause ()
  6. OnStop ()
  7. OnDestroy ()

He escrito más en profundidad sobre estos métodos en mi blog

La aplicación para Android madura, completa y funcional completa se transita (estado = función del tiempo) de acuerdo con la respuesta proporcionada por @Felix.

Pero lo que si sólo desea crear una aplicación que ni siquiera tiene interfaz gráfica de usuario. Y desea el ciclo de vida más simple, entonces tengo la respuesta a continuación.

Esta respuesta probablemente le resultaría interesante. Sistema Android después de leer AndroidManifest.xml sabe cuál es el punto de entrada. Cualquier actividad que tenga esta

 <activity android:name=".MainActivity"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> 

Será el punto de partida o de entrada para el sistema. Después de esto, su proceso de aplicación obtuvo la memoria donde puede iniciarse.

Su principal proceso de creación es la tarea del sistema Android. Cuando se inicia un componente de aplicación y la aplicación no tiene otros componentes en ejecución, el sistema Android inicia un nuevo proceso de Linux. Después de que el proceso llama a onCreate () , crea el hilo principal. Esa es la razón por la que debe llamar a onCreate () , ya que el hilo principal se inicializa y el hilo principal es el disparador de todas sus acciones futuras.

En onCreate (), obtuvo su hilo principal. Después de eso, es totalmente depende de usted, lo que callbacks desea llamar. No hay ninguna regla que debes llamar a onStart () después de onCreate ().

Sólo un método de ciclo de vida onCreate () está garantizado para ser el ciclo de vida de su componente.

Y, además, para entender, lo que cada método de ciclo de vida está haciendo dentro de él, poner el código a continuación.

 //add the log line Log.i(this.getClass().getCanonicalName(), "##############"); int count = 0; for (StackTraceElement stackTraceElement: Thread.currentThread().getStackTrace()) { count++; Log.i(this.getClass().getCanonicalName(), "\""+Thread.currentThread().getStackTrace()[2].getMethodName()+"\" "+count+" "+stackTraceElement.getMethodName()); }; //end of log line 

Por lo tanto, siempre agregue encima del mismo código para ver los registros en la consola de chat de registro.

Cuando la aplicación inicia GUI, llama a onStart (). Si no llama al método super () dentro de la devolución de llamada, el sistema android muestra un error de tubería roto y no puede procesar y depurar más.

Introduzca aquí la descripción de la imagen

Sin embargo, puede implementar su propia lógica dentro de cada método de devolución de llamada. Por ejemplo, puede hacer la suma de dos números en onStart ().

Por lo tanto, todos los métodos de devolución de llamada android son métodos parcialmente implementados. No son métodos puramente abstractos porque deberías llamar al método super () dentro de ellos .

La imagen adjunta dice: El proceso principal de la aplicación llama a Create (), delega sus responsabilidades al hilo principal (hilo de interfaz de usuario) y al hilo principal llama a estas otras 16 devoluciones de llamada.

Introduzca aquí la descripción de la imagen

Además, si desea ver todos sus métodos en un momento determinado, coloque este código debajo.

 //to see all the methods (including super methods) at this time, you call use the java reflection as below Log.i(this.getClass().getCanonicalName(), "##############"); int count1 = 0; for (Method method: this.getClass().getMethods()) { count1++; count++; Log.i(this.getClass().getCanonicalName(), count1+" "+method); }; //end of log line //At another time, after you add some other methods or android using GC removes some methods, you see your changed state (Bundle Snapshot) of your class //Because your bundle (ie, the state of your class/activity) is the function of time. 

En mi escenario, desde el fragmento de código justo arriba, veo que ha llamado 375 métodos.

Nota: Si hubiera agregado otro método dentro de onCreate () antes de imprimir todos sus métodos usando sólo un fragmento de código, también habría visto ese método. Esto significa que su estado de la clase (es decir, la instantánea) es según usted, lo que haces una y otra vez, sigues actualizando tu instantánea.

  • Cómo reiniciar la aplicación de Android desde la aplicación
  • ¿Registrar automáticamente eventos de ciclo de vida de Android mediante ActivityLifecycleCallbacks?
  • OnCreateView método se llama cuando? Y ¿Cuántas veces en el ciclo de vida de la actividad?
  • Ciclo de vida y servicio de las aplicaciones de Android
  • Android - tutorial de Bloc de notas - ciclo de vida - algunos trabajos realizados dos veces?
  • Android: aplicación global onPause () y onResume ()?
  • Cualquier manera de forzar la aplicación de memoria en el emulador de Android?
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.