onRestart — restauración de Activity en el ciclo de vida

onRestart — la esencia del método en el ciclo de vida de Android

onRestart — un método callback que Android llama estrictamente antes de onStart cuando una Activity regresa del estado Stopped invisible a ser visible. Este método es único porque solo se llama cuando la Activity se muestra nuevamente — durante la primera creación de la instancia, la secuencia comienza con onCreate, omitiendo onRestart. El ciclo completo: onCreate → onStart → onResume (primer inicio) u onRestart → onStart → onResume (visualización posterior).

Desde la perspectiva del sistema Android, onRestart es una optimización que permite a la Activity prepararse para su regreso: actualizar datos del repositorio, sincronizar el estado de la UI, verificar la conectividad de red. A diferencia de onResume, que se llama cada vez que la Activity obtiene el foco (incluyendo al regresar de un diálogo o menú del sistema), onRestart se activa solo durante un ciclo completo de ocultación y retorno. Esto hace de onRestart el lugar ideal para operaciones de actualización “pesadas” que no son necesarias durante una pérdida parcial del foco.

Según la especificación del ciclo de vida de Activity de Android, el intervalo de tiempo entre onStop y onRestart puede variar desde unos segundos (el usuario cambió rápidamente) hasta varias horas (la aplicación estaba en segundo plano y el usuario regresó). Durante este tiempo, los datos en una fuente remota (API, BD) podrían haber cambiado, por lo que onRestart es un punto natural para verificar la vigencia.

Cuándo se llama a onRestart: condiciones y secuencia

onRestart solo se llama cuando una Activity regresa del estado Stopped, al cual la Activity entró después de que se llamara a onStop. A continuación se enumeran todos los escenarios que conducen a onRestart.

Escenarios de invocación de onRestart:

• Regreso desde otra Activity — el usuario abrió una nueva Activity (por ejemplo, tocó una notificación) y luego navegó hacia atrás (presionó “Atrás”). Pila: MainActivity.onPause → MainActivity.onStop → SecondActivity se crea → el usuario presiona “Atrás” → SecondActivity.onPause → SecondActivity.onStop → SecondActivity.onDestroy → MainActivity.onRestart → MainActivity.onStart → MainActivity.onResume.
• Regreso después de minimizar — el usuario minimizó la aplicación (Inicio) y después de un tiempo regresó. CurrentActivity.onPause → CurrentActivity.onStop → (aplicación en segundo plano) → el usuario regresa → CurrentActivity.onRestart → CurrentActivity.onStart → CurrentActivity.onResume.
• Regreso desde la pantalla de bloqueo — la pantalla de bloqueo cubre la Activity; después del desbloqueo, la Activity recibe onRestart si ha pasado un tiempo significativo (más de 5 segundos).
• Regreso desde una aplicación lanzada mediante Intent — cámara, galería, navegador — cualquier aplicación de terceros lanzada mediante startActivityForResult() o ActivityResultLauncher.

Cuándo NO se llama a onRestart: durante la rotación de pantalla (la Activity se destruye y se recrea mediante onCreate), al regresar de un cuadro de diálogo (la Activity no entra en onStop, solo onPause → onResume), durante la muerte del proceso (la Activity se recrea).

onRestart vs onCreate: cuál elegir

onRestart y onCreate son dos enfoques diferentes para restaurar una Activity. La elección entre ellos depende de si la Activity fue destruida por completo o simplemente ocultada.

Regla de selección: realice la inicialización de View y la suscripción a LiveData/StateFlow en onCreate (o onViewCreated para Fragment). Las actualizaciones de datos, la recarga de listas y las comprobaciones de estado — en onRestart. Si los datos se cargan a través de ViewModel, onRestart puede simplemente llamar al método refresh() en el ViewModel, y la View se suscribirá a los datos actualizados a través de un flujo reactivo.

Google recomienda: no duplique la lógica de onCreate en onRestart. Extraiga métodos refresh() en ViewModel que carguen datos actuales, y llámelos en onRestart. Esto preserva una arquitectura MVVM limpia y elimina la duplicación de código.

Casos de uso de onRestart: actualización de datos y UI

onRestart es el lugar ideal para operaciones que deben realizarse cada vez que se regresa a la pantalla, pero no son necesarias en la primera apertura. Aquí hay escenarios típicos:

• Actualizar una lista desde BD o API — el usuario fue a otra Activity, cambió datos allí, regresó — la lista debe estar actualizada. Llame a viewModel.refreshItems() en onRestart.
• Verificación de autorización — si la Activity estuvo oculta durante mucho tiempo, el token de acceso pudo haber expirado. onRestart es el punto para verificar la validez del token y redirigir a la pantalla de inicio de sesión.
• Sincronización del estado de la UI — cambio de tema, cambio de idioma, actualización de configuraciones — los cambios deben aplicarse al regresar a la pantalla.
• Recarga de medios — si la Activity muestra contenido que pudo haber cambiado (feed de noticias, tipos de cambio, clima), actualice los datos en onRestart.
• Verificación de conectividad de red — al regresar del modo fuera de línea, la Activity debe verificar la disponibilidad de la red y cambiar la UI.
• Restauración de animaciones — las animaciones liberadas en onStop deben reiniciarse en onRestart antes de onStart.

Qué NO hacer en onRestart: no reinicialice las Views — están vivas porque la Activity no fue destruida. No se suscriba nuevamente a LiveData — la suscripción en onCreate sigue viva. No cree nuevos Fragments — ya están en el FragmentManager.

onRestart y la muerte del proceso: una excepción importante

La excepción más importante: onRestart no se llama si el proceso de la aplicación fue eliminado por el sistema. Este es un punto clave que los desarrolladores a menudo pasan por alto cuando confían en onRestart para la restauración del estado.

Durante la muerte del proceso:

• La aplicación estaba en segundo plano, Android eliminó el proceso para liberar memoria.
• El usuario regresa — el sistema inicia un nuevo proceso.
• La Activity se recrea: onCreate(Bundle) → onStart → onResume.
• onRestart NO se llama — para el sistema, esta es una nueva instancia de Activity.

Cómo protegerse contra esto: guarde siempre el estado crítico en onSaveInstanceState(Bundle) (se llama antes de onStop) o use SavedStateHandle en ViewModel. En onCreate, verifique savedInstanceState: si no es null, restaure el estado desde Bundle; si es null, cargue datos nuevos.

Según Google Android Vitals, aproximadamente el 7% de los retornos a una Activity después de un largo tiempo en segundo plano ocurren después de la muerte del proceso. Esto significa que cada 15.ª Activity que debería haber llamado a onRestart, en realidad pasa por onCreate. Ignorar este escenario es una de las principales causas de errores de “pantalla vacía después del retorno”.

Ejemplos de código con onRestart en Kotlin

Ejemplo 1: onRestart con actualización de lista mediante ViewModel

La Activity llama a viewModel.refreshTasks() en onRestart para actualizar la lista de tareas después de regresar de la pantalla de edición.

class TaskListActivity : AppCompatActivity() {
    private val viewModel: TaskViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_task_list)
        viewModel.tasks.observe(this) { tasks ->
            Log.d("TaskList", "Recibidas ${tasks.size} tareas")
        }
    }

    override fun onRestart() {
        super.onRestart()
        Log.d("TaskList", "onRestart: actualizando lista de tareas")
        viewModel.refreshTasks()
    }
}

class TaskViewModel : ViewModel() {
    private val _tasks = MutableLiveData<List<Task>>()
    val tasks: LiveData<List<Task>> get() = _tasks

    fun refreshTasks() {
        viewModelScope.launch {
            _tasks.value = TaskRepository().getAllTasks()
        }
    }
}

ViewModel.refreshTasks() carga datos actuales del repositorio. LiveData notifica automáticamente a la Activity sobre los cambios de datos — la UI se actualiza sin código adicional. onRestart no crea una nueva suscripción — ya fue establecida en onCreate.

Ejemplo 2: onRestart con verificación de autorización

La Activity verifica la validez del token al regresar y redirige al inicio de sesión si es necesario.

class ProfileActivity : AppCompatActivity() {
    private val authManager = AuthManager()
    private val launcher = registerForActivityResult(
        ActivityResultContracts.StartActivityForResult()
    ) { Log.d("Profile", "Regresó de la pantalla de inicio de sesión") }

    override fun onRestart() {
        super.onRestart()
        if (!authManager.isTokenValid()) {
            Log.d("Profile", "Token expirado — redirigiendo al inicio de sesión")
            launcher.launch(Intent(this, LoginActivity::class.java))
        }
    }
}

class AuthManager {
    fun isTokenValid(): Boolean {
        val expiry = SharedPreferencesManager().getTokenExpiry()
        return System.currentTimeMillis() < expiry
    }
}

Si el usuario minimizó la aplicación durante mucho tiempo y regresó después de que el token expirara, onRestart lo redirigirá a la pantalla de inicio de sesión. Esto evita errores de API al intentar realizar una solicitud con un token expirado. Nota: la verificación está en onRestart, no en onResume, para evitar una verificación innecesaria al regresar de un diálogo.

Ejemplo 3: onRestart en Fragment con ViewLifecycleOwner

El Fragment usa onRestart mediante LifecycleObserver para actualizar datos.

class FeedFragment : Fragment() {
    private val viewModel: FeedViewModel by viewModels()

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        viewLifecycleOwner.lifecycle.addObserver(object : LifecycleObserver {
            @OnLifecycleEvent(Lifecycle.Event.ON_RESTART)
            fun onRestart() {
                Log.d("FeedFragment", "onRestart mediante LifecycleObserver")
                viewModel.refreshFeed()
            }
        })
    }
}

En lugar de sobrescribir onRestart en Fragment, se usa LifecycleObserver — un enfoque más flexible que permite agregar lógica de eventos del ciclo de vida sin herencia. ViewLifecycleOwner garantiza que el observer viva dentro del ámbito de la View (no sobrevive a onDestroyView).