Active: was ist der Active-Zustand im iOS-Lebenszyklus

Active: was ist dieser Zustand

Active — ein Zustand des mobilen App-Lebenszyklus, in dem sie sich im Vordergrund befindet, auf dem Bildschirm des Geräts angezeigt wird und aktiv mit dem Benutzer interagiert. In diesem Zustand empfängt die App alle Touch-Ereignisse, Tastendrücke, Beschleunigungsmesser- und Gyroskopdaten und hat vollen Zugriff auf den Grafikprozessor zur Darstellung der Oberfläche.

Auf iOS ist der Active-Zustand Teil des Fünf-Zustands-Lebenszyklusmodells: Not Running → Inactive → Active → Inactive → Background → Suspended → Not Running. Auf Android ist das Äquivalent der Activity-Zustand nach dem Aufruf von onResume, wenn die Activity oben im Stapel liegt und Benutzereingaben annimmt. Active ist der einzige Zustand, in dem die UI vollständig interaktiv ist und auf Gesten, Scrollen, Tippen und Animationen reagiert.

Das System gibt einer App in Active die höchste Priorität für CPU und RAM. Das bedeutet, dass das System eine solche App bei Ressourcenknappheit nicht beenden wird — zuerst werden Hintergrund- und angehaltene Prozesse entladen. Die App sollte jedoch Ressourcen effizient nutzen, um Batterieentladung und CPU-Drosselung zu vermeiden.

Für den Benutzer ist Active der normale Zustand der Arbeit mit einer App. Der Benutzer sieht die Oberfläche, kann Schaltflächen drücken, Formulare ausfüllen und durch Feeds scrollen. Jede Unterbrechung dieses Zustands (ein Anruf, eine Benachrichtigung, Wischen nach oben für Control Center) versetzt die App in Inactive, wonach sie zu Active zurückkehren oder in den Background gehen kann.

Wie das System feststellt, dass die App Active ist

iOS verwendet UIApplicationMain zur Zustandsverwaltung. Beim Übergang zu Active ruft das System applicationDidBecomeActive auf. Für SwiftUI ist der äquivalente Mechanismus die Überwachung von scenePhase über Environment. Android verwendet onResume als Indikator dafür, dass die Activity im Vordergrund ist. Beide Ansätze garantieren, dass die App eine Statusänderungsbenachrichtigung erhält und ihr Verhalten anpassen kann.

Active in iOS: Swift, UIKit und SwiftUI

Auf iOS wird der Active-Zustand über UIApplicationDelegate verwaltet. Die Hauptmethode ist applicationDidBecomeActive(_:). Sie wird beim ersten Start der App und bei der Rückkehr aus Inactive aufgerufen. Diese Methode ist der ideale Ort, um Aufgaben fortzusetzen, die beim Eintritt in Inactive angehalten wurden: Animationen starten, Timer fortsetzen, Sensoren neu starten, Datenaktualisierungen auf dem Server überprüfen.

UIKit: AppDelegate und SceneDelegate

Mit iOS 13 führte Apple UISceneDelegate zur Unterstützung mehrerer Fenster auf iPad ein. In diesem Fall wird applicationDidBecomeActive durch sceneDidBecomeActive für jede einzelne Szene ersetzt. Apps, die nur einen einzelnen Bildschirm unterstützen, können weiterhin UIApplicationDelegate verwenden. Beide Ansätze werden aufgerufen, wenn die App oder Szene aktiv wird.

import UIKit

@main
class AppDelegate: UIResponder, UIApplicationDelegate {

    // Anwendung wurde aktiv — Aufgaben werden fortgesetzt
    func applicationDidBecomeActive(_ application: UIApplication) {
        resumeAnimations()
        restartTimers()
        refreshDataIfNeeded()
        startObservingSensors()
    }

    // Anwendung verliert Aktivität — pausiere
    func applicationWillResignActive(_ application: UIApplication) {
        pauseAnimations()
        stopTimers()
        saveDraftData()
    }

    private func resumeAnimations() {
        UIView.animate(withDuration: 0.3) {
            // UI-Animationen fortsetzen
        }
    }

    private func refreshDataIfNeeded() {
        let lastRefresh = UserDefaults.standard.object(forKey: "lastRefresh") as? Date ?? .distantPast
        if Date().timeIntervalSince(lastRefresh) > 300 {
            fetchDataFromServer()
        }
    }
}

Der Code zeigt die korrekte Active-Behandlung in UIKit. applicationDidBecomeActive setzt Animationen und Timer fort und prüft, ob Datenaktualisierungen erforderlich sind. applicationWillResignActive pausiert alles, was Ressourcen verbrauchen könnte, und speichert Entwürfe. Ein solches Methodenpaar stellt sicher, dass die App korrekt auf Zustandsänderungen reagiert.

SwiftUI: scenePhase

SwiftUI hat kein AppDelegate — die Zustandsverwaltung erfolgt über Environment<ScenePhase>. Der Wert .active wird gesetzt, wenn die Szene im Vordergrund und interaktiv ist. SwiftUI startet Animationen und Aktualisierungen bei der Rückkehr zu Active automatisch neu. Der Entwickler muss nur onChange abonnieren, um Nebenwirkungen auszuführen.

import SwiftUI

@main
struct ActiveDemoApp: App {
    @Environment(\.scenePhase) private var scenePhase

    var body: some Scene {
        WindowGroup {
            ContentView()
        }
        .onChange(of: scenePhase) { oldPhase, newPhase in
            switch newPhase {
            case .active:
                print("Szene wurde aktiv")
                resumeWork()
            case .inactive:
                print("Szene wurde inaktiv")
                pauseWork()
            case .background:
                print("Szene ging in den Hintergrund")
                saveState()
            @unknown default:
                break
            }
        }
    }

    private func resumeWork() {
        // Netzwerkanfragen, Animationen fortsetzen
    }

    private func pauseWork() {
        // Zeitkritische Aufgaben anhalten
    }

    private func saveState() {
        // Anwendungszustand speichern
    }
}

In SwiftUI ist scenePhase die einzige Quelle der Wahrheit über den App-Zustand. onChange ermöglicht Aktionen bei jedem Übergang. Es ist wichtig zu bedenken, dass scenePhase nur auf iOS 14+ und im SwiftUI Lifecycle verfügbar ist. Für UIKit-Apps mit SwiftUI-Bildschirmen verwenden Sie den UIApplicationDelegate-Ansatz.

Übergänge in den Active-Zustand

Active kann auf mehreren Wegen erreicht werden. Der erste und offensichtlichste ist ein Kaltstart: Der Benutzer tippt auf das Symbol, die App geht von Not Running über Inactive zu Active. Der zweite ist die Rückkehr aus dem Hintergrund: Der Benutzer wechselt über den App Switcher zurück zur App, die App durchläuft Inactive und wird Active. Der dritte ist die Rückkehr von einer vorübergehenden Unterbrechung: Der Benutzer beendet einen Anruf, schließt das Control Center oder reagiert auf eine Benachrichtigung — die App kehrt von Inactive zu Active zurück.

Übergangskette zu Active

Not Running → Inactive → Active — Kaltstart. Background → Inactive → Active — Rückkehr aus dem Hintergrund. Inactive → Active — Rückkehr von einer vorübergehenden Unterbrechung. In jedem Fall wird applicationDidBecomeActive aufgerufen, aber der Kontext kann unterschiedlich sein. Bei einem Kaltstart wird vor Active didFinishLaunchingWithOptions aufgerufen; bei der Rückkehr aus dem Hintergrund wird willEnterForeground aufgerufen. Der Entwickler kann diese Unterschiede nutzen, um eine Strategie zur Zustandswiederherstellung zu wählen.

Wichtiger Hinweis: Bei der Rückkehr aus Suspended ruft iOS didFinishLaunchingWithOptions nicht auf, da die App bereits in den Speicher geladen war. Das bedeutet, dass Initialisierungscode, der in dieser Methode platziert wurde, nicht erneut ausgeführt wird. Entwickler vergessen dies oft und verlagern kritische Logik für beide Szenarien in applicationWillEnterForeground oder applicationDidBecomeActive.

Active in Android: Activity-Lebenszyklus

In Android ist das Äquivalent von Active der Activity-Zustand nach dem Aufruf von onResume(). Eine Activity gilt als aktiv, wenn sie im Vordergrund ist und Benutzereingaben annimmt. Dieser Zustand entspricht der Spitze des Activity-Stapels. Wenn eine andere Activity darüber erscheint (auch teilweise), wechselt die aktuelle Activity in den onPause-Zustand — das Äquivalent zu iOS Inactive.

Ein wesentlicher Unterschied in Android ist, dass mehrere Activities im Multi-Window-Modus (Split Screen, Freeform) gleichzeitig aktiv sein können. In diesem Fall gilt die Activity, mit der der Benutzer interagiert, als aktiv, während die benachbarte pausiert (onPause) ist. iOS unterstützt kein Multi-Window auf dem iPhone, nur auf dem iPad über UIScene.

class MainActivity : AppCompatActivity() {

    override fun onResume() {
        super.onResume()
        // Anwendung wurde aktiv — Aufgaben werden fortgesetzt
        resumeCameraPreview()
        startLocationUpdates()
        activateSensors()
    }

    override fun onPause() {
        super.onPause()
        // Anwendung verliert Aktivität — Ressourcen freigeben
        releaseCamera()
        stopLocationUpdates()
        deactivateSensors()
    }

    private fun resumeCameraPreview() {
        // Kameravorschau starten (benötigt Berechtigung)
        cameraProvider?.unbindAll()
        cameraProvider?.bindToLifecycle(
            this,
            cameraSelector,
            preview,
            imageAnalyzer
        )
    }

    private fun startLocationUpdates() {
        val locationRequest = LocationRequest.Builder(
            Priority.PRIORITY_HIGH_ACCURACY, 5000
        ).build()
        locationClient.requestLocationUpdates(
            locationRequest,
            locationCallback,
            Looper.getMainLooper()
        )
    }
}

Der Code zeigt die Active-Behandlung in Android über onResume/onPause. onResume setzt die Kamera, Geolokalisierung und Sensoren fort — Ressourcen, die nur aktiv sein sollten, wenn die App für den Benutzer sichtbar ist. onPause gibt diese Ressourcen frei, um Batterieentladung zu vermeiden. Die CameraX lifecycle-aware API pausiert die Vorschau bei onPause automatisch.

Best Practices für die Active-Behandlung

Erste Regel — führen Sie keine schweren Operationen in applicationDidBecomeActive oder onResume durch. Datenladen, JSON-Parsing, Datenbankarbeit — all dies sollte asynchron sein und den Hauptthread nicht blockieren. Verwenden Sie GCD (DispatchQueue) auf iOS und Coroutines in Kotlin für Hintergrundaufgaben. Der Hauptthread sollte nur die UI aktualisieren und asynchrone Operationen starten.

Zweite Regel — synchronisieren Sie den Zustand bei jeder Rückkehr zu Active. Der Benutzer könnte Einstellungen in einer System-App geändert, eine Push-Benachrichtigung erhalten oder Daten in einer anderen App aktualisiert haben. Überprüfen Sie die Relevanz des Caches beim Übergang zu Active — Daten könnten während der Abwesenheit des Benutzers veraltet sein.

Dritte Regel — verlassen Sie sich nicht auf Active als einzigen Zustand. Die App kann Active überspringen und direkt von Not Running zu Background gehen (wenn sie im Hintergrundmodus gestartet wird). Auf iOS geschieht dies beim Start über eine Push-Benachrichtigung mit der Option content-available. Auf Android beim Start über BroadcastReceiver. Überprüfen Sie immer den aktuellen Zustand vor der Ausführung von UI-Operationen.

Vierte Regel — verwenden Sie die Activity Result API auf Android anstelle von onActivityResult. Dies ermöglicht die Behandlung des Ergebnisses von Kamera-, Galerie- oder Berechtigungsaufrufen direkt im Active-Zustand ohne Datenverlust bei der Neuerstellung der Activity. Für iOS verwenden Sie async/await mit UIApplication.shared.open für Systemdialoge.

import UIKit

final class ActiveStateManager {
    static let shared = ActiveStateManager()
    private var isActive = false

    func setActive(_ active: Bool) {
        isActive = active
        if active {
            NotificationCenter.default.post(name: .appDidBecomeActive, object: nil)
        }
    }

    func performWhenActive(_ block: @escaping () -> Void) {
        if isActive {
            block()
        } else {
            // Ausführung bis zur Rückkehr zu Active verzögern
            NotificationCenter.default.addObserver(
                forName: .appDidBecomeActive,
                object: nil,
                queue: .main
            ) { _ in
                block()
            }
        }
    }
}

extension Notification.Name {
    static let appDidBecomeActive = Notification.Name("appDidBecomeActive")
}

Der Code zeigt einen Active-Zustandsmanager, der es anderen App-Komponenten ermöglicht, den aktuellen aktiven Zustand zu überprüfen. performWhenActive führt den Block entweder sofort aus, wenn die App aktiv ist, oder verschiebt die Ausführung bis zur Rückkehr zu Active. Dies ist nützlich für Dienste, die eine Aktion ausführen müssen, nachdem der Benutzer zur App zurückgekehrt ist.