Active: vad är det, tillståndet Active i iOS livscykel

Active: vad är detta för tillstånd

Active — ett tillstånd i en mobilapplikations livscykel, där appen är i förgrunden, visas på enhetens skärm och aktivt interagerar med användaren. I detta tillstånd tar appen emot alla beröringshändelser, knapptryckningar, data från accelerometer och gyroskop, samt har full tillgång till grafikprocessorn för rendering av gränssnittet.

På iOS är Active-tillståndet en del av femtillståndsmodellen för livscykeln: Not Running → Inactive → Active → Inactive → Background → Suspended → Not Running. På Android är motsvarigheten Activitys tillstånd efter anrop av onResume, när Activity är överst i stacken och tar emot användarinmatning. Active är det enda tillstånd där UI är fullt interaktivt och reagerar på gester, scrollning, klick och animationer.

Systemet ger appen i Active maximal prioritet för processor och RAM. Detta innebär att systemet inte kommer att avsluta en sådan app vid resursbrist — först kommer bakgrunds- och suspenderade processer att avlastas. Appen måste dock använda resurser effektivt för att inte tömma batteriet och orsaka CPU-throttling.

För användaren är Active normalt arbetstillstånd med appen. Användaren ser gränssnittet, kan trycka på knappar, fylla i formulär, scrolla i flödet. Varje avbrott i detta tillstånd (samtal, notis, svep uppåt för Control Center) flyttar appen till Inactive, varefter den kan återgå till Active eller gå till Background.

Hur systemet avgör att appen är Active

iOS använder UIApplicationMain för tillståndshantering. Vid övergång till Active anropar systemet applicationDidBecomeActive. För SwiftUI är motsvarande mekanism observation av scenePhase via Environment. Android använder onResume som indikator för Activitys aktivitet i förgrunden. Båda metoderna garanterar att appen får en notis om tillståndsändringen och kan anpassa sitt beteende.

Active i iOS: Swift, UIKit och SwiftUI

I iOS hanteras tillståndet Active via UIApplicationDelegate. Huvudmetoden — applicationDidBecomeActive(_:). Den anropas vid första lanseringen av appen och vid återkomst från Inactive. Denna metod är den idealiska platsen för att återuppta uppgifter som pausades vid övergång till Inactive: starta animationer, återuppta timers, starta om sensorer, kontrollera datauppdateringar på servern.

UIKit: AppDelegate och SceneDelegate

Från och med iOS 13 introducerade Apple UISceneDelegate för stöd av flera fönster på iPad. I detta fall ersätts applicationDidBecomeActive med sceneDidBecomeActive för varje scen. Appar som bara stöder en skärm kan fortsätta använda UIApplicationDelegate. Båda metoderna anropas i det ögonblick appen eller scenen blir aktiv.

import UIKit

@main
class AppDelegate: UIResponder, UIApplicationDelegate {

    // Appen blev aktiv — återupptar uppgifter
    func applicationDidBecomeActive(_ application: UIApplication) {
        resumeAnimations()
        restartTimers()
        refreshDataIfNeeded()
        startObservingSensors()
    }

    // Appen förlorar aktivitet — pausar
    func applicationWillResignActive(_ application: UIApplication) {
        pauseAnimations()
        stopTimers()
        saveDraftData()
    }

    private func resumeAnimations() {
        UIView.animate(withDuration: 0.3) {
            // Återupptagning av UI-animationer
        }
    }

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

Koden visar korrekt hantering av Active i UIKit. applicationDidBecomeActive återupptar animationer, timers och kontrollerar om datauppdatering behövs. applicationWillResignActive pausar allt som kan förbruka resurser och sparar utkast. Ett sådant metodpar garanterar att appen reagerar korrekt på tillståndsändringar.

SwiftUI: scenePhase

I SwiftUI finns ingen AppDelegate — tillståndshantering sker via Environment<ScenePhase>. Värdet .active sätts när scenen är i förgrunden och interaktiv. SwiftUI startar automatiskt om animationer och uppdateringar vid återkomst till Active. Utvecklaren behöver bara prenumerera på onChange för att utföra sidoeffekter.

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("Scenen blev aktiv")
                resumeWork()
            case .inactive:
                print("Scenen blev inaktiv")
                pauseWork()
            case .background:
                print("Scenen gick till bakgrunden")
                saveState()
            @unknown default:
                break
            }
        }
    }

    private func resumeWork() {
        // Återupptagning av nätverksförfrågningar, animationer
    }

    private func pauseWork() {
        // Pausning av tidskänsliga uppgifter
    }

    private func saveState() {
        // Spara appens tillstånd
    }
}

I SwiftUI är scenePhase den enda sanningskällan om appens tillstånd. onChange gör det möjligt att utföra åtgärder vid varje övergång. Det är viktigt att komma ihåg att scenePhase endast är tillgängligt på iOS 14+ och i SwiftUI Lifecycle. För UIKit-appar med SwiftUI-skärmar, använd metoden med UIApplicationDelegate.

Övergångar till Active-tillståndet

Active kan nås på flera sätt. Det första och uppenbara — kallstart: användaren trycker på ikonen, appen går från Not Running via Inactive till Active. Det andra — återkomst från bakgrunden: användaren växlar tillbaka till appen via App Switcher, appen passerar Inactive och blir Active. Det tredje — återkomst från tillfälligt avbrott: användaren avslutar ett samtal, stänger Control Center eller svarar på en notis — appen återvänder från Inactive till Active.

Kedja av övergångar till Active

Not Running → Inactive → Active — kallstart. Background → Inactive → Active — återkomst från bakgrunden. Inactive → Active — återkomst från tillfälligt avbrott. I varje fall anropas applicationDidBecomeActive, men sammanhanget kan skilja sig. Vid kallstart anropas didFinishLaunchingWithOptions före Active, vid återkomst från bakgrunden — willEnterForeground. Utvecklaren kan använda dessa skillnader för att välja strategi för tillståndsåterställning.

Viktig anmärkning: vid återkomst från Suspended anropar iOS inte didFinishLaunchingWithOptions, eftersom appen redan var laddad i minnet. Detta innebär att initialiseringskoden som placerats i denna metod inte körs igen. Utvecklare glömmer ofta detta och flyttar kritisk logik till applicationWillEnterForeground eller applicationDidBecomeActive för båda scenarierna.

Active i Android: livscykel för Activity

I Android är motsvarigheten till Active Activitys tillstånd efter anrop av onResume(). Activity anses aktivt när det är i förgrunden och tar emot användarinmatning. Detta tillstånd motsvarar toppen av Activity-stacken. Om ett annat Activity dyker upp ovanför (även delvis), går det aktuella Activity till tillståndet onPause — motsvarigheten till iOS Inactive.

Den viktigaste skillnaden i Android — flera Activity kan vara aktiva samtidigt i multi-window-läge (split screen, freeform). I detta fall anses Activity som användaren interagerar med vara aktivt, och det angränsande — pausat (onPause). iOS stöder inte multi-window på iPhone, endast på iPad via UIScene.

class MainActivity : AppCompatActivity() {

    override fun onResume() {
        super.onResume()
        // Appen blev aktiv — återupptar uppgifter
        resumeCameraPreview()
        startLocationUpdates()
        activateSensors()
    }

    override fun onPause() {
        super.onPause()
        // Appen förlorar aktivitet — frigör resurser
        releaseCamera()
        stopLocationUpdates()
        deactivateSensors()
    }

    private fun resumeCameraPreview() {
        // Starta kameraförhandsvisning (kräver tillstånd)
        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()
        )
    }
}

Koden visar hantering av Active i Android via onResume/onPause. onResume återupptar arbetet med kameran, geolokalisering och sensorer — resurser som bara bör vara aktiva när appen är synlig för användaren. onPause frigör dessa resurser för att inte tömma batteriet. CameraX lifecycle-aware API stoppar automatiskt förhandsvisningen vid onPause.

Bästa praxis för hantering av Active

Första regeln — utför inte tunga operationer i applicationDidBecomeActive eller onResume. Ladda data, tolka JSON, arbeta med databasen — allt detta bör vara asynkront och inte blockera huvudtråden. Använd GCD (DispatchQueue) i iOS och Coroutines i Kotlin för bakgrundsuppgifter. Huvudtråden bör bara uppdatera UI och starta asynkrona operationer.

Andra regeln — synkronisera tillståndet vid varje återkomst till Active. Användaren kan ha ändrat inställningar i systemappen, fått ett push-meddelande eller uppdaterat data i en annan app. Kontrollera cacheminnets aktualitet vid övergång till Active — data kan ha blivit föråldrad under användarens frånvaro.

Tredje regeln — förlita dig inte på Active som det enda tillståndet. Appen kan hoppa över Active och gå direkt från Not Running till Background (om den startas i bakgrunden). På iOS händer detta vid start via ett push-meddelande med alternativet content-available. På Android — vid start via BroadcastReceiver. Kontrollera alltid det aktuella tillståndet innan du utför UI-operationer.

Fjärde regeln — använd Activity Result API på Android istället för onActivityResult. Detta gör det möjligt att hantera resultatet av kamera-, galleri- eller behörighetsanrop direkt i Active-tillstånd utan dataförlust vid återskapande av Activity. För iOS, använd async/await med UIApplication.shared.open för systemdialoger.

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 {
            // Skjut upp körningen till återkomst till Active
            NotificationCenter.default.addObserver(
                forName: .appDidBecomeActive,
                object: nil,
                queue: .main
            ) { _ in
                block()
            }
        }
    }
}

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

Koden visar en Active-tillståndshanterare som gör det möjligt för andra komponenter i appen att kontrollera det aktuella aktiva tillståndet. performWhenActive kör antingen blocket omedelbart (om appen är aktiv) eller skjuter upp körningen till återkomst till Active. Detta är användbart för tjänster som måste utföra en åtgärd efter att användaren återvänder till appen.