single - Android Application Class Lifecycle
pila de actividades android (4)
La aplicación para Android en la que estoy trabajando anula la clase Application para almacenar el estado liviano (nombre de usuario, ubicación gps, etc.) en variables estáticas. La mayor parte de este estado se establece en OnCreate de la actividad de inicio (nombre de usuario recuperado de las preferencias, el detector de ubicación se ejecuta). ¿Es seguro confiar en la actividad de inicio para inicializar la clase de aplicación? ¿Hay algún caso en el que la clase Application se pueda volver a crear sin que también se haya creado la actividad Launch?
Surge la pregunta porque me topé con una excepción de puntero nulo al acceder a una variable en la clase de Aplicación al reanudar la aplicación después de que el teléfono estuvo dormido durante varias horas (la aplicación se quedó en primer plano antes de que el teléfono se fuera a dormir). ¿Es posible que el proceso se haya cancelado mientras el teléfono estaba dormido y al despertar el teléfono, se volvió a crear la clase de la aplicación, se reanudó la actividad principal en la pila, pero no se ejecutó la actividad de inicio.onCreate, la clase de aplicación no fue inicializado?
Tenga en cuenta que he intentado probar este tipo de escenarios forzando a la aplicación a dejar de usar las configuraciones / Administrar aplicaciones. Sin embargo, no puedo recrear el problema. En la siguiente ejecución, se crea la clase Application, seguida de la actividad de inicio.onCreate.
¿Es seguro suponer que la instancia de la clase de aplicación existirá mientras dure el proceso, y que cuando se crea la clase de la aplicación es equivalente a "reiniciar" la aplicación, es decir. comenzar con una nueva pila de actividades (y la primera actividad en la pila es la actividad de lanzamiento)?
"Me encontré con una excepción de puntero nulo al acceder a una variable en la clase de aplicación al reanudar la aplicación"
Mira este enlace .. http://www.developerphil.com/dont-store-data-in-the-application-object/
En resumen: realice la iniciación en YourApplication.onCreate , no alguna LaunchActivity
Documentos para verificar:
- Procesos e hilos
- Guías API> Actividades
¿Es seguro confiar en la actividad de inicio para inicializar la clase de aplicación?
Sí, siempre que recuerde que la Aplicación puede existir más tiempo que esa Actividad y que la Actividad puede ser eliminada y recreada. No estoy seguro de qué actividad resucitará el Intento. Actividad: LANZAR o VER (para el escenario en el que la actividad se mató por ser demasiado pesada, mientras que el servicio de larga duración estuvo unido a la aplicación)
¿Hay algún caso en el que la clase Application se pueda volver a crear sin que también se haya creado la actividad Launch?
sí, si la última actividad visible no fue LaunchActivity
verificar el ciclo de vida de la aplicación Android y el uso de estática
¿Es posible que el proceso se haya cancelado mientras el teléfono estaba dormido y al despertar el teléfono, se volvió a crear la clase de la aplicación, se reanudó la actividad principal en la pila, pero no se ejecutó la actividad de inicio.onCreate, la clase de aplicación no fue inicializado?
Si se lanzaron varias actividades diferentes A, B, C y todo el proceso, creo que el sistema operativo Android es bueno con solo crear aplicaciones y actividad C, mientras que A y B se volverían a crear en el acceso, es decir, al volver a ellos.
¿Es seguro suponer que la instancia de la clase de aplicación existirá mientras dure el proceso,
sí
y que cuando se crea la clase de aplicación es equivalente a "reiniciar" la aplicación, es decir. comenzar con una nueva pila de actividades (y la primera actividad en la pila es la actividad de lanzamiento)?
No estoy seguro de cuándo se llamaría primero el reinicio de la actividad de inicio,
pero el último, es decir, aquel que el usuario debería ver.
No. Toda la aplicación se puede eliminar y volver a crear con la pila de tareas intacta; esto permite que el sistema recupere memoria en los dispositivos que lo necesitan y al mismo tiempo presenta una ilusión perfecta de multitarea para el usuario final. De los documentos:
Una actividad de fondo (una actividad que no es visible para el usuario y se ha pausado) ya no es crítica, por lo que el sistema puede matar de forma segura su proceso para reclamar memoria para otros procesos en primer plano o visibles. Si su proceso necesita ser eliminado, cuando el usuario navega de regreso a la actividad (haciéndolo visible en la pantalla de nuevo), su método onCreate (Bundle) será llamado con el estado de instancia salvado que había proporcionado previamente en el estado de excepción de almacenamiento (Bundle) para que puede reiniciarse en el mismo estado que el usuario lo dejó por última vez.
Es decir, el proceso (al que está ligada la Aplicación) puede eliminarse, pero luego reiniciarse, y las actividades individuales deben tener suficiente información para recrearse a partir de lo que han guardado antes de ser eliminadas, sin depender del estado global establecido en el proceso por otras actividades.
Considere almacenar el estado compartido persistente que necesita la inicialización de una Actividad en una base de datos SharedPreference o SQLite, o pasarlo a Actividades que lo necesiten como un Intento adicional.
Puede probar el escenario killing the process de su aplicación en ejecución.
Paso 1. Abre tu aplicación y luego presiona el botón de Home para esconderla en el fondo.
Paso 2. Invocar adb shell
Paso 3. Ingrese el comando su (debe obtener el permiso ROOT para finalizar el proceso)
Paso 4. ps (liste toda la identificación del proceso en ejecución y encuentre la suya)
Paso 5. kill 1234 (suponiendo que su aplicación se ejecuta en el proceso 1234)
Paso 6. Luego, regrese a su dispositivo y haga clic en el icono de inicio nuevamente. Puede encontrar que la última actividad en la pila de actividades se vuelve a abrir. También puede encontrar que se llama el método onRestoreInstanceState() para la actividad.