onStart: Wesen, Sichtbarkeit der Activity auf dem Android-Bildschirm

Das Wesen von onStart in Android

onStart ist die zweite Methode des Activity-Lebenszyklus, die vom System nach onCreate (oder nach onRestart bei Rückkehr aus einem gestoppten Zustand) aufgerufen wird. Im Moment des Aufrufs von onStart wird die Activity oder Fragment auf dem Bildschirm sichtbar. Der Benutzer sieht die Oberfläche, aber der Bildschirm ist noch nicht bereit für die Interaktion — der Eingabefokus erscheint erst nach onResume.

Die onStart-Methode gehört zur „sichtbaren Lebensdauer“ (visible lifetime) einer Activity — dem Intervall zwischen onStart und onStop. Während dieser Zeit kann die Activity teilweise von anderen Fenstern (z. B. einer transparenten Activity oder einem Dialogfenster) überdeckt sein, aber ihre UI bleibt sichtbar. Dies unterscheidet die sichtbare Lebensdauer von der „Vordergrund-Lebensdauer“ (onResume — onPause), wenn die Activity den vollen Eingabefokus hat.

Das Verständnis dieser dreistufigen Hierarchie ist für die korrekte Verteilung des Codes entscheidend. onCreate — einmalige Initialisierung, onStart — Verbindung sichtbarer Ressourcen, onResume — exklusiver Zugriff auf exklusive Ressourcen. Ein Entwickler, der diese Ebenen verwechselt, riskiert Speicherlecks oder ein falsches Anwendungsverhalten beim Wechsel zwischen Bildschirmen.

onStart in Activity

In Activity wird die onStart-Methode jedes Mal aufgerufen, wenn der Bildschirm auf dem Display erscheint — sowohl beim ersten Start (nach onCreate) als auch bei der Rückkehr aus dem Hintergrund (nach onRestart). Im Gegensatz zu onCreate kann onStart mehrmals während der Lebensdauer einer Activity-Instanz aufgerufen werden, daher wird hier Code platziert, der jedes Mal ausgeführt werden soll, wenn der Bildschirm erscheint.

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

Wichtige Regel: Alle in onStart verbundenen Ressourcen müssen in onStop freigegeben werden. Dies stellt sicher, dass die Activity, wenn sie vom Bildschirm verborgen ist, keinen Akku verbraucht, keine Systemereignisse abhört und keinen Speicher belegt. Android Studio enthält Lint-Regeln, die vor dem Registrieren eines BroadcastReceiver ohne entsprechende Abmeldung warnen.

onStart in Fragment

onStart in Fragment ist eng mit dem Lebenszyklus der Container-Activity verbunden. Das Fragment erhält den onStart-Aufruf, nachdem die es enthältende Activity onStart erhalten hat. Wenn das Fragment jedoch im verzögerten Modus hinzugefügt wird (FragmentTransaction.commit() ohne addToBackStack), kann onStart mit Verzögerung aufgerufen werden.

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()
    }
}

Besonderheiten von Fragment.onStart: Wenn sich das Fragment in einem ViewPager mit offscreenPageLimit = 1 befindet, erhalten benachbarte Fragmente ebenfalls onStart, bevor sie sichtbar werden. Dies kann zu einer vorzeitigen Listener-Registrierung führen. Verwenden Sie in solchen Fällen die Methode setUserVisibleHint() oder überprüfen Sie isVisible innerhalb von onStart, um Listener nur für tatsächlich sichtbare Fragmente zu registrieren.

Unterschied zwischen onStart und onResume

Der Hauptunterschied zwischen onStart und onResume ist die Ebene der Bildschirmaktivität. onStart signalisiert, dass die Activity auf dem Bildschirm sichtbar ist, aber nicht unbedingt im Vordergrund. onResume signalisiert, dass die Activity im Vordergrund ist und den Eingabefokus hat. Der Unterschied wird anhand eines Dialogfenster-Beispiels demonstriert: Wenn ein Dialog über einer Activity erscheint, verliert die Activity onResume (onPause wird aufgerufen), bleibt aber sichtbar — onStart/onStop werden nicht aufgerufen.

Die Vergleichstabelle zeigt deutlich, in welchen Szenarien jede Methode aufgerufen wird:

Diese Tabelle hilft dem Entwickler zu entscheiden, in welche Methode ein bestimmter Code platziert werden soll. Wenn die App beispielsweise die Videowiedergabe bei jeder Bildschirmüberlappung (auch einem Dialog) anhalten soll, wird der Code in onPause platziert. Wenn das Video nur bei vollständiger Ausblendung des Bildschirms gestoppt werden soll — wird der Code in onStop platziert.

Listener und Dienste registrieren

onStart ist der optimale Ort, um Listener zu registrieren, die nur arbeiten sollen, während die Activity auf dem Bildschirm sichtbar ist. Dies betrifft drei Haupttypen von Systemkomponenten: BroadcastReceiver für Systemereignisse, LocationListener für Geolokalisierung und SensorListener für Gerätesensoren.

BroadcastReceiver in onStart

BroadcastReceiver wird dynamisch über Context.registerReceiver() in onStart registriert und in onStop über unregisterReceiver() abgemeldet. Die dynamische Registrierung ist der statischen Registrierung (im Manifest) vorzuziehen, da sie die Lebensdauer des Empfängers auf den Sichtbarkeitszeitraum der Activity beschränkt — die App wacht nicht durch System-Broadcast-Nachrichten auf, wenn die Activity verborgen ist.

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 und SensorListener

Geolokalisierung und Sensoren sind ressourcenintensive Operationen. Das Anfordern von GPS-Updates in onStart und das Abbrechen in onStop stellt sicher, dass die App keinen Akku verbraucht, wenn der Bildschirm verborgen ist. Für die Feineinstellung verwenden Sie requestLocationUpdates mit einem minimalen Intervall und Abstand — z. B. 10 Sekunden und 10 Meter, was ein optimales Gleichgewicht zwischen Genauigkeit und Energieverbrauch bietet.

Animationen und onStart

Das Starten von Animationen in onStart anstelle von onCreate stellt sicher, dass die Animation jedes Mal startet, wenn der Bildschirm erscheint. Wenn Sie eine Animation in onCreate starten, funktioniert sie nur bei der ersten Activity-Erstellung, nicht bei der Rückkehr aus dem Hintergrund. onStart wird jedes Mal aufgerufen, wenn die Activity sichtbar wird, was es zum idealen Ort macht, um zyklische Animationen und Übergänge zu starten.

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()
}

Für Animationen, die ObjectAnimator oder ValueAnimator verwenden, ist es wichtig, cancel() in onStop aufzurufen. Wenn die Animation nach dem Ausblenden der Activity weiterläuft, verbraucht sie unnötig GPU- und CPU-Ressourcen, verschlechtert die Geräteleistung und beschleunigt die Akkuentladung. Mit Android Studio Profiler (GPU-Diagramm) können Sie aktive Animationen verfolgen und Lecks erkennen.

Die Paarungsregel onStart/onStop gilt auch für die Arbeit mit der Kamera für die Vorschau (CameraX). Das Öffnen der Kamera in onStart und das Schließen in onStop stellt sicher, dass die Kamera nicht für andere Apps blockiert ist, wenn Ihre App nicht auf dem Bildschirm sichtbar ist. Ein Verstoß gegen diese Regel ist eine häufige Ursache für negative Bewertungen im Google Play Store.