onStart: essência, visibilidade da Activity na tela Android

A essência do onStart no Android

onStart é o segundo método do ciclo de vida da Activity, chamado pelo sistema após onCreate (ou após onRestart ao retornar de um estado parado). No momento em que onStart é chamado, a Activity ou Fragment se torna visível na tela. O usuário vê a interface, mas a tela ainda não está pronta para interação — o foco de entrada aparecerá apenas após onResume.

O método onStart faz parte do “tempo de vida visível” (visible lifetime) de uma Activity — o intervalo entre onStart e onStop. Durante este período, a Activity pode estar parcialmente coberta por outras janelas (por exemplo, uma Activity transparente ou janela de diálogo), mas sua UI permanece visível. Isso distingue o tempo de vida visível do “tempo de vida em primeiro plano” (onResume — onPause), quando a Activity tem foco de entrada completo.

Compreender essa hierarquia de três níveis é fundamental para distribuir o código corretamente. onCreate — inicialização única, onStart — conexão de recursos visíveis, onResume — acesso exclusivo a recursos exclusivos. Um desenvolvedor que confunde esses níveis corre o risco de criar vazamentos de memória ou comportamento incorreto do aplicativo ao alternar entre telas.

onStart na Activity

Na Activity, o método onStart é chamado toda vez que a tela aparece no display — tanto no primeiro lançamento (após onCreate) quanto ao retornar do segundo plano (após onRestart). Ao contrário do onCreate, onStart pode ser chamado múltiplas vezes durante a vida de uma instância da Activity, portanto, o código que deve ser executado toda vez que a tela aparece é colocado aqui.

class DashboardActivity : AppCompatActivity() {
    private val connectivityReceiver = object : BroadcastReceiver() {
        override fun onReceive(context: Context?, intent: Intent?) {
            val isConnected = ... // Verificação 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()
    }
}

Regra fundamental: todos os recursos conectados em onStart devem ser liberados em onStop. Isso garante que quando a Activity estiver oculta da tela, ela não consuma bateria, não ouça eventos do sistema nem ocupe memória. O Android Studio inclui regras lint que alertam sobre o registro de um BroadcastReceiver sem o cancelamento correspondente.

onStart no Fragment

onStart no Fragment está intimamente ligado ao ciclo de vida da Activity contêiner. O Fragment recebe a chamada onStart após a Activity que o contém ter recebido onStart. No entanto, se o Fragment for adicionado em modo diferido (FragmentTransaction.commit() sem addToBackStack), onStart pode ser chamado com atraso.

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 do Fragment.onStart: se o Fragment estiver em um ViewPager com offscreenPageLimit = 1, fragmentos vizinhos também receberão onStart antes de se tornarem visíveis. Isso pode levar ao registro prematuro de listeners. Para esses casos, use o método setUserVisibleHint() ou verifique isVisible dentro de onStart para registrar listeners apenas para fragmentos realmente visíveis.

Diferença entre onStart e onResume

A principal diferença entre onStart e onResume é o nível de atividade da tela. onStart sinaliza que a Activity está visível na tela, mas não necessariamente em primeiro plano. onResume sinaliza que a Activity está em primeiro plano e tem foco de entrada. A diferença é demonstrada com um exemplo de janela de diálogo: quando um Dialog aparece sobre uma Activity, a Activity perde onResume (onPause é chamado) mas permanece visível — onStart/onStop não são chamados.

A tabela comparativa mostra claramente em quais cenários cada método é chamado:

Esta tabela ajuda o desenvolvedor a decidir em qual método colocar um código específico. Por exemplo, se o aplicativo deve pausar a reprodução de vídeo durante qualquer sobreposição de tela (mesmo um diálogo), o código é colocado em onPause. Se o vídeo deve parar apenas quando a tela estiver completamente oculta — o código é colocado em onStop.

Registro de listeners e serviços

onStart é o local ideal para registrar listeners que devem funcionar apenas enquanto a Activity estiver visível na tela. Isso diz respeito a três tipos principais de componentes do sistema: BroadcastReceiver para eventos do sistema, LocationListener para geolocalização e SensorListener para sensores do dispositivo.

BroadcastReceiver em onStart

BroadcastReceiver é registrado dinamicamente via Context.registerReceiver() em onStart e cancelado em onStop via unregisterReceiver(). O registro dinâmico é preferível ao registro estático (no manifesto) porque limita o tempo de vida do receptor ao período de visibilidade da Activity — o aplicativo não acorda com mensagens de broadcast do sistema quando a 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 e SensorListener

Geolocalização e sensores são operações que consomem muitos recursos. Solicitar atualizações de GPS em onStart e cancelar em onStop garante que o aplicativo não consuma bateria quando a tela estiver oculta. Para ajuste fino, use requestLocationUpdates com intervalo e distância mínimos — por exemplo, 10 segundos e 10 metros, o que proporciona um equilíbrio ótimo entre precisão e consumo de energia.

Animações e onStart

Iniciar animações em onStart, em vez de em onCreate, garante que a animação comece toda vez que a tela aparecer. Se você iniciar uma animação em onCreate, ela funcionará apenas na primeira criação da Activity, não ao retornar do segundo plano. onStart é chamado toda vez que a Activity se torna visível, tornando-o o local ideal para iniciar animações cíclicas e transições.

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 animações que usam ObjectAnimator ou ValueAnimator, é importante chamar cancel() em onStop. Se a animação continuar executando após a Activity ser ocultada, ela consome recursos de GPU e CPU inutilmente, degradando o desempenho do dispositivo e acelerando o consumo de bateria. O Android Studio Profiler (gráfico GPU) permite rastrear animações ativas e detectar vazamentos.

A regra de pareamento onStart/onStop também se aplica ao trabalhar com a câmera para visualização (CameraX). Abrir a câmera em onStart e fechá-la em onStop garante que a câmera não seja bloqueada para outros aplicativos quando seu aplicativo não estiver visível na tela. Violar esta regra é uma causa comum de avaliações negativas no Google Play.