De acuerdo con el ciclo de vida de actividad de Android, la única devolución de llamada garantizada para ser llamada (si una actividad deja el estado En ejecución, que normalmente se espera) es onPause()
.¿Por qué implementar onDestroy() si no se garantiza que se invoque?
Por lo tanto, debo suponer que hay escenarios en los que tiene sentido para implementar onStop()
onDestroy()
y aunque no son realmente garantizado a ser llamado.
Entiendo que onStop()
debe implementarse cuando es posible que una actividad regrese al estado En ejecución a través del estado Detenido (por qué hacer eso en lugar de regresar directamente es una pregunta diferente).
Pero la necesidad de onDestroy()
, cuando puedo colocar toda la limpieza/ahorro de estado en onPause()
, no me queda claro.
¿Puede describir una situación de aplicación real (es decir, no análoga a conducir un automóvil, etc.) en la que tendría sentido implementar onDestroy()
?
Porque en circunstancias normales, se llamará a onDestroy(). Es solo que no está garantizado que se lo llame. Por ejemplo, si tu proceso es asesinado por el asesino. – Falmarri
@Falmarri Pero una aplicación bien escrita debe diseñarse para el peor de los casos. ¿Estás implicando una mejora del rendimiento en circunstancias normales? – uTubeFan
¿Por qué está usando ese diagrama (2008 !?) en lugar del [oficial] (http://developer.android.com/images/activity_lifecycle.png)? Esto es algo que ha cambiado bastante desde 1.5. – dmon