Not Running — was ist das, der anfängliche Lebenszyklus-Zustand

Not Running — was ist dieser Zustand

Not Running ist der grundlegende Lebenszyklus-Zustand einer mobilen Anwendung, in dem sie nicht in den RAM des Geräts geladen ist und keine Systemressourcen verbraucht. In iOS und Android bedeutet dieser Zustand das vollständige Fehlen von Prozessen und Threads, die mit der Anwendung verbunden sind. Der Benutzer sieht das App-Symbol auf dem Startbildschirm, aber die Anwendung selbst ist nicht aktiv und befindet sich nicht in der Liste der letzten Apps.

Wenn der Benutzer auf das App-Symbol tippt, erstellt das System einen neuen Prozess, lädt den ausführbaren Code in den Speicher und initialisiert alle notwendigen Datenstrukturen. Dieser Prozess wird als Kaltstart (Cold Start) bezeichnet und ist im Hinblick auf die Ladezeit am ressourcenintensivsten.

Das System kann die Anwendung aus jedem anderen Zustand in Not Running versetzen. Wenn sich die Anwendung im Hintergrund oder im Suspended-Zustand befindet, hat das Betriebssystem das Recht, sie zu entladen, wenn nicht genügend RAM für Aufgaben mit höherer Priorität vorhanden ist — zum Beispiel für eine aktive Anwendung im Vordergrund.

Der Entwickler muss berücksichtigen, dass die Anwendung vom System jederzeit beendet werden kann, wenn sie sich im Hintergrund befindet. Dies bedeutet, dass alle nicht gespeicherten Daten verloren gehen können. Daher ist es von entscheidender Bedeutung, den Zustand bei Übergängen von Active zu Background in Schlüssel-Wert-Speichern (UserDefaults, SharedPreferences) oder einer lokalen Datenbank zu speichern.

Wie das System bestimmt, welche Anwendung entladen werden soll

iOS verwendet Prioritäten basierend auf dem aktuellen Anwendungszustand: Active hat die höchste Priorität, gefolgt von Inactive, Background, Suspended und schließlich Not Running — die niedrigste Priorität. Android verwendet eine ähnliche Prozesshierarchie: Der Vordergrundprozess hat Priorität OOM_ADJ = 0, Visible-Prozess = 100, Service-Prozess = 200, Background-Prozess = 300, Empty-Prozess = 400. Je höher der Wert, desto wahrscheinlicher wird der Prozess bei Speichermangel beendet.

Kalt- und Warmstart einer Anwendung

Kaltstart (Cold Start) tritt auf, wenn die Anwendung von Not Running direkt zu Active übergeht. Das System erstellt einen neuen Prozess, lädt die Klassen, initialisiert die statischen Felder, erstellt den Hauptthread und startet das UI-Framework. Auf iOS bedeutet dies den Aufruf von application(_:didFinishLaunchingWithOptions:), auf Android — den Aufruf von Application.onCreate() und Activity.onCreate(). Die Kaltstartzeit kann je nach Komplexität der Anwendung zwischen 200 ms und mehreren Sekunden liegen.

Warmstart (oder Hot Start) — die Anwendung befand sich im Suspended-Zustand und wird ohne vollständiges Neuladen wieder aufgenommen. Das System stellt den letzten UI-Stack aus dem Speicher wieder her, und der Benutzer arbeitet an derselben Stelle weiter. Ein Warmstart ist deutlich schneller als ein Kaltstart, da der größte Teil des Codes bereits in den Speicher geladen ist. Auf iOS ruft ein Warmstart application(_:didFinishLaunchingWithOptions:) nicht auf, sondern nur applicationWillEnterForeground und applicationDidBecomeActive.

Der Unterschied zwischen Kalt- und Warmstart ist entscheidend für die Benutzererfahrung. Während eines Kaltstarts muss der Entwickler sicherstellen, dass der Start so schnell wie möglich erfolgt — verzögerte Initialisierung von Modulen, verzögertes Laden schwerer Ressourcen, Minimierung der Arbeit im Hauptthread beim Start. Google empfiehlt einen Kaltstart von nicht mehr als 500 ms, Apple — nicht mehr als 400 ms für iOS.

// Messung der Kaltstartzeit in Android
class App : Application() {
    private var startTime: Long = 0L

    override fun onCreate() {
        super.onCreate()
        startTime = System.currentTimeMillis()
    }

    fun getStartupTime(): Long {
        return System.currentTimeMillis() - startTime
    }
}

// Activity mit verzögerter Initialisierung starten
class MainActivity : AppCompatActivity() {
    private val viewModel: MainViewModel by lazy {
        ViewModelProvider(this).get(MainViewModel::class.java)
    }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        // Nur das notwendige Minimum für den ersten Frame
        setupNavigation()
    }

    override fun onPostCreate(savedInstanceState: Bundle?) {
        super.onPostCreate(savedInstanceState)
        // Schwere Initialisierung nach dem Rendern
        initializeHeavyModules()
    }
}

Das Beispiel zeigt die Messung der Kaltstartzeit in Android. Application.onCreate() wird beim Übergang von Not Running zu Active aufgerufen. Der Zeitstempel wird beim Start des Prozesses aufgezeichnet. Die Activity verwendet eine verzögerte Initialisierung über einen lazy-Delegaten, um den ersten Frame nicht zu blockieren. onPostCreate ist der optimale Ort, um schwere Module zu initialisieren, da die UI bereits gerendert wurde.

Not Running in iOS: Swift und AppDelegate

In iOS wird Not Running über das UIApplicationDelegate-Protokoll verwaltet. Wichtige Methoden: application(_:didFinishLaunchingWithOptions:) wird nach einem Kaltstart aufgerufen, applicationWillTerminate(_:) wird vor der Beendigung der Anwendung durch den Benutzer aufgerufen. Allerdings kann das System die Anwendung beenden, ohne applicationWillTerminate aufzurufen — zum Beispiel bei einer Notbeendigung oder Speicherdruck. iOS garantiert nicht, dass diese Methode aufgerufen wird, daher sollten Daten in applicationDidEnterBackground gespeichert werden.

Übergangsszenarien zu Not Running auf iOS

Der Benutzer kann die Anwendung manuell mit einem Wisch im App Switcher beenden. Das System kann die Anwendung aus dem Speicher entladen, während sie sich im Hintergrund befindet. Die Anwendung kann abstürzen. In allen Fällen werden alle beim Start erstellten Objekte zerstört. Der nicht gespeicherte Zustand geht für immer verloren. Unter iOS 13+ wird empfohlen, NSUserActivity oder den Zustandswiederherstellungsmechanismus über UIApplication.stateRestorationIdentifier zu verwenden, um den Zustand zu bewahren.

import UIKit

@main
class AppDelegate: UIResponder, UIApplicationDelegate {

    // Kaltstart: Anwendung von Not Running übergegangen
    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        // Initialisierung des minimalen Servicesatzes
        setupAnalytics()
        configureAppearance()
        return true
    }

    // Anwendung beendet — nur manuelles Schließen
    func applicationWillTerminate(
        _ application: UIApplication
    ) {
        saveCriticalData()
    }

    // Daten vor dem Wechsel in den Hintergrund speichern
    func applicationDidEnterBackground(
        _ application: UIApplication
    ) {
        saveApplicationState()
    }

    private func saveCriticalData() {
        UserDefaults.standard.synchronize()
    }

    private func saveApplicationState() {
        let state = ["lastScreen": "main", "timestamp": Date()]
        try? NSKeyedArchiver.archivedData(
            withRootObject: state,
            requiringSecureCoding: true
        )
    }
}

Der Code zeigt die korrekte Behandlung von Not Running unter iOS. applicationWillTerminate wird nur aufgerufen, wenn der Benutzer die App manuell beendet. Das Speichern kritischer Daten wird in applicationDidEnterBackground dupliziert, da diese Methode garantiert vor dem Wechsel in den Hintergrund aufgerufen wird. Die Zustandswiederherstellung ermöglicht das Speichern des UI-Stacks für eine spätere Wiederherstellung während eines Kaltstarts.

Not Running in Android: Kotlin und Prozess

In Android bedeutet Not Running, dass der Anwendungsprozess nicht existiert. Das Android zugrunde liegende Linux-System verwaltet Prozesse über den Zygote-Mechanismus. Wenn eine Anwendung gestartet wird, gabelt Zygote einen neuen Prozess, lädt Dalvik/ART und ruft Application.onCreate() auf. Android hat kein direktes Äquivalent zu applicationWillTerminate — das System kann den Prozess jederzeit ohne Vorwarnung beenden.

Android-Prozesslebenszyklus

Wenn eine Activity zum ersten Mal aufgerufen wird, erstellt das System den Prozess, die Application und die Activity über die Kette onCreate → onStart → onResume. Wenn der Benutzer Zurück drückt, wird die Activity zerstört (onDestroy), und der Prozess kann vom System beendet werden. Ein wesentlicher Unterschied zu iOS: In Android kann der Prozess auch ohne aktive Activities weiter existieren — zum Beispiel, wenn ein Foreground Service ausgeführt wird oder ein aktiver BroadcastReceiver vorhanden ist.

// Behandlung von Not Running über SavedStateHandle im ViewModel
class MainViewModel(
    private val savedStateHandle: SavedStateHandle
) : ViewModel() {

    companion object {
        private const val KEY_LAST_SCREEN = "last_screen"
        private const val KEY_USER_DATA = "user_data"
    }

    fun saveCurrentState(screen: String, data: String) {
        savedStateHandle[KEY_LAST_SCREEN] = screen
        savedStateHandle[KEY_USER_DATA] = data
    }

    fun restoreState(): AppState? {
        val screen = savedStateHandle.get<String>(KEY_LAST_SCREEN)
        val data = savedStateHandle.get<String>(KEY_USER_DATA)
        return if (screen != null && data != null) {
            AppState(screen, data)
        } else null
    }
}

// Application — der erste Callback nach Not Running
class MyApplication : Application() {

    override fun onCreate() {
        super.onCreate()
        initCrashReporter()
        initDependencyInjection()
    }
}

SavedStateHandle ist eine Komponente von Android Architecture Components, die den Zustand während eines Übergangs zu Not Running automatisch speichert und bei einem Kaltstart wiederherstellt. Ein über ViewModelProvider erstelltes ViewModel überlebt Bildschirmdrehung und Activity-Zerstörung. Wenn der Prozess beendet wird, werden die Daten aus SavedStateHandle in ein Bundle serialisiert und im gespeicherten Instanzzustand abgelegt.

Gründe für den Übergang zu Not Running

Not Running tritt aus mehreren Gründen auf. Der Benutzer schließt die Anwendung manuell. Das System entlädt die Anwendung aufgrund von Speichermangel. Die Anwendung stürzt mit einer Ausnahme ab. Auf Android kann das System den Prozess während einer Massen-App-Aktualisierung oder eines Geräteneustarts beenden. iOS kann die Anwendung beenden, wenn eine Hintergrundaufgabe zeitlich überschritten wird (normalerweise 30 Sekunden).

Wie diagnostiziert man einen Übergang zu Not Running

Für iOS verwenden Sie die Konsolenprotokollierung in applicationWillTerminate und applicationDidFinishLaunching. Fügen Sie bei jedem Start ein Flag in UserDefaults hinzu — wenn das Flag beim nächsten Start fehlt, wurde die Anwendung unsachgemäß beendet. Verwenden Sie auf Android ActivityManager.isBackgroundRestricted(), um zu überprüfen, ob die Anwendung Hintergrundaufgaben ausführen kann. Überwachen Sie auch onTrimMemory(TRIM_MEMORY_COMPLETE) — dies ist ein Signal, dass der Prozess beendet wird.

Bewährte Methoden für die Arbeit mit Not Running

Erste Regel — gehen Sie niemals davon aus, dass applicationWillTerminate oder onDestroy aufgerufen werden. Speichern Sie kritisch wichtige Daten bei jedem Übergang von Active zu Background. Verwenden Sie Schlüssel-Wert-Speicher für einfache Einstellungen und SQLite/Room für strukturierte Daten.

Zweite Regel — messen Sie die Kaltstartzeit und optimieren Sie sie. Verzögerte Initialisierung, Minimierung der Arbeit im Hauptthread, Vorabladen von Ressourcen, Verwendung der SplashScreen-API — all dies verbessert die wahrgenommene Startzeit. Google empfiehlt einen Kaltstart von weniger als 200 ms für eine hervorragende Benutzererfahrung.

Dritte Regel — implementieren Sie die Zustandswiederherstellung. Verwenden Sie auf iOS UIApplication.stateRestorationIdentifier und NSUserActivity. Verwenden Sie auf Android SavedStateHandle im ViewModel in Kombination mit onSaveInstanceState. Dadurch kann der Benutzer nach einem Neustart der App an derselben Stelle weiterarbeiten.

Vierte Regel — behandeln Sie launchOptions und Intent, mit denen die Anwendung nach Not Running gestartet wurde. Deep Links, Push-Benachrichtigungen, universelle Links — alle werden über Startparameter übergeben. Der Entwickler muss diese Daten korrekt extrahieren und den Benutzer zum entsprechenden Bildschirm navigieren.

// Behandlung von Deep Links nach Kaltstart
func application(
    _ application: UIApplication,
    didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
) -> Bool {
    // Überprüfen, ob eine Benachrichtigung eingetroffen ist
    if let notification = launchOptions?[.remoteNotification] as? [String: Any] {
        handleNotification(notification)
    }
    // Deep Link überprüfen
    if let url = launchOptions?[.url] as? URL {
        handleDeepLink(url)
    }
    return true
}

private func handleDeepLink(_ url: URL) {
    guard let components = URLComponents(url: url, resolvingAgainstBaseURL: false),
          let screenId = components.queryItems?.first(where: { $0.name == "screen" })?.value
    else { return }
    openScreen(screenId)
}

Der Code zeigt die Behandlung von Startparametern beim iOS-Kaltstart. launchOptions enthält die Daten, mit denen das System die Anwendung gestartet hat. Benachrichtigungen, Deep Links und universelle Links werden über dieses Wörterbuch übergeben. Der Entwickler muss alle möglichen Startszenarien korrekt behandeln, um eine nahtlose Benutzererfahrung zu gewährleisten.