onStart: esencia, visibilidad de Activity en la pantalla de Android

La esencia de onStart en Android

onStart es el segundo método del ciclo de vida de Activity, llamado por el sistema después de onCreate (o después de onRestart al regresar de un estado detenido). En el momento en que se llama a onStart, la Activity o Fragment se vuelve visible en pantalla. El usuario ve la interfaz, pero la pantalla aún no está lista para la interacción: el foco de entrada aparecerá solo después de onResume.

El método onStart forma parte del “período de vida visible” de una Activity: el intervalo entre onStart y onStop. Durante este período, la Activity puede estar parcialmente cubierta por otras ventanas (por ejemplo, una Activity transparente o una ventana de diálogo), pero su UI permanece visible. Esto distingue el período de vida visible del “período de vida en primer plano” (onResume — onPause), cuando la Activity tiene el foco de entrada completo.

Comprender esta jerarquía de tres niveles es fundamental para distribuir correctamente el código. onCreate: inicialización única, onStart: conexión de recursos visibles, onResume: acceso exclusivo a recursos exclusivos. Un desarrollador que confunde estos niveles corre el riesgo de crear fugas de memoria o un comportamiento incorrecto de la aplicación al cambiar entre pantallas.

onStart en Activity

En Activity, el método onStart se llama cada vez que la pantalla aparece en el display, tanto en el primer inicio (después de onCreate) como al regresar del fondo (después de onRestart). A diferencia de onCreate, onStart puede llamarse múltiples veces durante la vida de una instancia de Activity, por lo que aquí se coloca el código que debe ejecutarse cada vez que aparece la pantalla.

class DashboardActivity : AppCompatActivity() {
    private val connectivityReceiver = object : BroadcastReceiver() {
        override fun onReceive(context: Context?, intent: Intent?) {
            val isConnected = ... // Comprobación de ConnectivityManager
            binding?.statusIndicator?.setColor(
                if (isConnected) Color.GREEN else Color.RED
            )
        }
    }

    override fun onStart() {
        super.onStart()
        registerReceiver(
            connectivityReceiver,
            IntentFilter(ConnectivityManager.CONNECTIVITY_ACTION)
        )
        SensorManager.getInstance().registerStepCounter()
    }

    override fun onStop() {
        unregisterReceiver(connectivityReceiver)
        SensorManager.getInstance().unregisterStepCounter()
        super.onStop()
    }
}

Regla clave: todos los recursos conectados en onStart deben liberarse en onStop. Esto garantiza que cuando la Activity esté oculta de la pantalla, no consuma batería, no escuche eventos del sistema ni ocupe memoria. Android Studio incluye reglas lint que advierten sobre el registro de un BroadcastReceiver sin la correspondiente cancelación.

onStart en Fragment

onStart en Fragment está estrechamente vinculado al ciclo de vida de la Activity contenedora. El Fragment recibe la llamada onStart después de que la Activity que lo contiene haya recibido onStart. Sin embargo, si el Fragment se agrega en modo diferido (FragmentTransaction.commit() sin addToBackStack), onStart puede llamarse con retraso.

class MapFragment : Fragment() {
    private var mapView: MapView? = null

    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View {
        mapView = MapView(requireContext())
        return mapView!!
    }

    override fun onStart() {
        super.onStart()
        mapView?.onStart()
        LocationService.connect(requireContext())
    }

    override fun onStop() {
        mapView?.onStop()
        LocationService.disconnect()
        super.onStop()
    }
}

Especificidades de Fragment.onStart: si el Fragment está en un ViewPager con offscreenPageLimit = 1, los fragmentos vecinos también recibirán onStart antes de volverse visibles. Esto puede provocar un registro prematuro de listeners. Para estos casos, use el método setUserVisibleHint() o verifique isVisible dentro de onStart para registrar listeners solo para fragmentos realmente visibles.

Diferencia entre onStart y onResume

La principal diferencia entre onStart y onResume es el nivel de actividad en pantalla. onStart señala que la Activity es visible en pantalla pero no necesariamente está en primer plano. onResume señala que la Activity está en primer plano y tiene el foco de entrada. La diferencia se demuestra con un ejemplo de ventana de diálogo: cuando aparece un Dialog sobre una Activity, la Activity pierde onResume (se llama a onPause) pero permanece visible: no se llama a onStart/onStop.

La tabla comparativa muestra claramente en qué escenarios se llama cada método:

Esta tabla ayuda al desarrollador a decidir en qué método colocar un código específico. Por ejemplo, si la aplicación debe pausar la reproducción de video durante cualquier superposición de pantalla (incluso un diálogo), el código se coloca en onPause. Si el video debe detenerse solo cuando la pantalla esté completamente oculta, el código se coloca en onStop.

Registro de listeners y servicios

onStart es el lugar óptimo para registrar listeners que solo deben funcionar mientras la Activity sea visible en pantalla. Esto concierne a tres tipos principales de componentes del sistema: BroadcastReceiver para eventos del sistema, LocationListener para geolocalización y SensorListener para sensores del dispositivo.

BroadcastReceiver en onStart

BroadcastReceiver se registra dinámicamente mediante Context.registerReceiver() en onStart y se cancela en onStop mediante unregisterReceiver(). El registro dinámico es preferible al registro estático (en el manifiesto) porque limita el tiempo de vida del receptor al período de visibilidad de la Activity: la aplicación no se activa con mensajes de broadcast del sistema cuando la Activity está oculta.

private val batteryReceiver = object : BroadcastReceiver() {
    override fun onReceive(context: Context?, intent: Intent) {
        val level = intent.getIntExtra(BatteryManager.EXTRA_LEVEL, -1)
        binding?.batteryText?.text = "$level%"
    }
}

override fun onStart() {
    super.onStart()
    registerReceiver(batteryReceiver, IntentFilter(Intent.ACTION_BATTERY_CHANGED))
}

override fun onStop() {
    unregisterReceiver(batteryReceiver)
    super.onStop()
}

LocationListener y SensorListener

La geolocalización y los sensores son operaciones que consumen muchos recursos. Solicitar actualizaciones de GPS en onStart y cancelarlas en onStop garantiza que la aplicación no agote la batería cuando la pantalla esté oculta. Para un ajuste fino, use requestLocationUpdates con un intervalo y distancia mínimos, por ejemplo, 10 segundos y 10 metros, lo que proporciona un equilibrio óptimo entre precisión y consumo de energía.

Animaciones y onStart

Iniciar animaciones en onStart, en lugar de en onCreate, garantiza que la animación comience cada vez que aparece la pantalla. Si inicia una animación en onCreate, solo funcionará en la primera creación de Activity, no al regresar del fondo. onStart se llama cada vez que la Activity se vuelve visible, lo que lo convierte en el lugar ideal para iniciar animaciones cíclicas y transiciones.

private lateinit var pulseAnimator: ValueAnimator

override fun onStart() {
    super.onStart()
    pulseAnimator.start()
    binding?.loadingIndicator?.animate()?.alpha(1f)?.start()
}

override fun onStop() {
    pulseAnimator.cancel()
    binding?.loadingIndicator?.animate()?.cancel()
    super.onStop()
}

Para animaciones que usan ObjectAnimator o ValueAnimator, es importante llamar a cancel() en onStop. Si la animación continúa ejecutándose después de ocultar la Activity, consume recursos de GPU y CPU innecesariamente, degradando el rendimiento del dispositivo y acelerando el agotamiento de la batería. Android Studio Profiler (gráfico de GPU) permite rastrear animaciones activas y detectar fugas.

La regla de emparejamiento onStart/onStop también se aplica al trabajar con la cámara para vista previa (CameraX). Abrir la cámara en onStart y cerrarla en onStop garantiza que la cámara no esté bloqueada para otras aplicaciones cuando su aplicación no sea visible en pantalla. Violar esta regla es una causa común de reseñas negativas en Google Play.