Active : qu'est-ce que l'état Active dans le cycle de vie iOS

Active : qu'est-ce que cet état

Active — un état du cycle de vie d'une application mobile dans lequel elle est au premier plan, affichée sur l'écran de l'appareil et interagit activement avec l'utilisateur. Dans cet état, l'application reçoit tous les événements tactiles, les pressions sur les touches, les données de l'accéléromètre et du gyroscope, et a un accès complet au processeur graphique pour le rendu de l'interface.

Sur iOS, l'état Active fait partie du modèle de cycle de vie à cinq états : Not Running → Inactive → Active → Inactive → Background → Suspended → Not Running. Sur Android, l'équivalent est l'état de l'Activity après l'appel de onResume, lorsque l'Activity est au sommet de la pile et accepte les entrées de l'utilisateur. Active est le seul état où l'UI est entièrement interactive et répond aux gestes, au défilement, aux tap et aux animations.

Le système accorde à une application en Active la priorité la plus élevée pour le CPU et la RAM. Cela signifie que le système ne mettra pas fin à une telle application en cas de pénurie de ressources — les processus en arrière-plan et suspendus seront déchargés en premier. Cependant, l'application doit utiliser les ressources de manière efficace pour éviter d'épuiser la batterie et de provoquer un limitation du CPU.

Pour l'utilisateur, Active est l'état normal de travail avec une application. L'utilisateur voit l'interface, peut appuyer sur des boutons, remplir des formulaires et parcourir les flux. Toute interruption de cet état (un appel, une notification, un balayage vers le haut pour Control Center) fait passer l'application en Inactive, après quoi elle peut revenir en Active ou aller en Background.

Comment le système détermine que l'application est Active

iOS utilise UIApplicationMain pour gérer l'état. Lors de la transition vers Active, le système appelle applicationDidBecomeActive. Pour SwiftUI, le mécanisme équivalent est l'observation de scenePhase via Environment. Android utilise onResume comme indicateur que l'Activity est au premier plan. Les deux approches garantissent que l'application reçoit une notification de changement d'état et peut adapter son comportement.

Active dans iOS : Swift, UIKit et SwiftUI

Sur iOS, l'état Active est géré via UIApplicationDelegate. La méthode principale est applicationDidBecomeActive(_:). Elle est appelée au premier lancement de l'application et lors du retour d'Inactive. Cette méthode est l'endroit idéal pour reprendre les tâches qui ont été suspendues lors de l'entrée en Inactive : démarrer des animations, reprendre des minuteurs, redémarrer des capteurs, vérifier les mises à jour de données sur le serveur.

UIKit : AppDelegate et SceneDelegate

Avec iOS 13, Apple a introduit UISceneDelegate pour prendre en charge plusieurs fenêtres sur iPad. Dans ce cas, applicationDidBecomeActive est remplacé par sceneDidBecomeActive pour chaque scène individuelle. Les applications qui ne prennent en charge qu'un seul écran peuvent continuer à utiliser UIApplicationDelegate. Les deux approches sont appelées lorsque l'application ou la scène devient active.

import UIKit

@main
class AppDelegate: UIResponder, UIApplicationDelegate {

    // L'application est devenue active — reprise des tâches
    func applicationDidBecomeActive(_ application: UIApplication) {
        resumeAnimations()
        restartTimers()
        refreshDataIfNeeded()
        startObservingSensors()
    }

    // L'application perd de l'activité ’ pause
    func applicationWillResignActive(_ application: UIApplication) {
        pauseAnimations()
        stopTimers()
        saveDraftData()
    }

    private func resumeAnimations() {
        UIView.animate(withDuration: 0.3) {
            // Reprise des animations de l'UI
        }
    }

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

Le code montre le traitement correct d'Active dans UIKit. applicationDidBecomeActive reprend les animations, les minuteurs et vérifie si des mises à jour de données sont nécessaires. applicationWillResignActive met en pause tout ce qui pourrait consommer des ressources et sauvegarde les brouillons. Une telle paire de méthodes garantit que l'application répond correctement aux changements d'état.

SwiftUI : scenePhase

SwiftUI n'a pas d'AppDelegate — la gestion d'état se fait via Environment<ScenePhase>. La valeur .active est définie lorsque la scène est au premier plan et interactive. SwiftUI redémarre automatiquement les animations et les mises à jour lors du retour en Active. Le développeur n'a qu'à s'abonner à onChange pour effectuer des effets secondaires.

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("La scène est devenue active")
                resumeWork()
            case .inactive:
                print("La scène est devenue inactive")
                pauseWork()
            case .background:
                print("La scène est passée en arrière-plan")
                saveState()
            @unknown default:
                break
            }
        }
    }

    private func resumeWork() {
        // Reprise des requêtes réseau, animations
    }

    private func pauseWork() {
        // Mise en pause des tâches sensibles au temps
    }

    private func saveState() {
        // Sauvegarde de l'état de l'application
    }
}

Dans SwiftUI, scenePhase est la seule source de vérité sur l'état de l'application. onChange permet d'effectuer des actions à chaque transition. Il est important de se rappeler que scenePhase n'est disponible que sur iOS 14+ et dans SwiftUI Lifecycle. Pour les applications UIKit avec des écrans SwiftUI, utilisez l'approche UIApplicationDelegate.

Transitions vers l'état Active

Active peut être atteint par plusieurs chemins. Le premier et le plus évident est un démarrage à froid : l'utilisateur tape sur l'icône, l'application passe de Not Running à Inactive puis à Active. Le second est le retour de l'arrière-plan : l'utilisateur revient à l'application via App Switcher, l'application traverse Inactive et devient Active. Le troisième est le retour d'une interruption temporaire : l'utilisateur termine un appel, ferme Control Center ou répond à une notification — l'application revient d'Inactive à Active.

Chaîne de transitions vers Active

Not Running → Inactive → Active — démarrage à froid. Background → Inactive → Active — retour de l'arrière-plan. Inactive → Active — retour d'une interruption temporaire. Dans chaque cas, applicationDidBecomeActive est appelée, mais le contexte peut différer. Lors d'un démarrage à froid, didFinishLaunchingWithOptions est appelé avant Active ; lors du retour de l'arrière-plan, willEnterForeground est appelé. Le développeur peut utiliser ces différences pour choisir une stratégie de restauration d'état.

Note importante : lors du retour de Suspended, iOS n'appelle pas didFinishLaunchingWithOptions car l'application était déjà chargée en mémoire. Cela signifie que le code d'initialisation placé dans cette méthode n'est pas réexécuté. Les développeurs oublient souvent cela et déplacent la logique critique vers applicationWillEnterForeground ou applicationDidBecomeActive pour les deux scénarios.

Active dans Android : cycle de vie d'Activity

Sur Android, l'équivalent d'Active est l'état de l'Activity après l'appel de onResume(). Une Activity est considérée comme active lorsqu'elle est au premier plan et accepte les entrées de l'utilisateur. Cet état correspond au sommet de la pile des Activities. Si une autre Activity apparaît par-dessus (même partiellement), l'Activity courante passe à l'état onPause — l'équivalent d'Inactive sur iOS.

Une différence clé dans Android est que plusieurs Activities peuvent être actives simultanément en mode multi-fenêtre (split screen, freeform). Dans ce cas, l'Activity avec laquelle l'utilisateur interagit est considérée comme active, tandis que la voisine est en pause (onPause). iOS ne prend pas en charge le multi-fenêtre sur iPhone, seulement sur iPad via UIScene.

class MainActivity : AppCompatActivity() {

    override fun onResume() {
        super.onResume()
        // L'application est devenue active — reprise des tâches
        resumeCameraPreview()
        startLocationUpdates()
        activateSensors()
    }

    override fun onPause() {
        super.onPause()
        // L'application perd de l'activité — libération des ressources
        releaseCamera()
        stopLocationUpdates()
        deactivateSensors()
    }

    private fun resumeCameraPreview() {
        // Démarrage de l'aperçu de la caméra (nécessite une autorisation)
        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()
        )
    }
}

Le code montre le traitement d'Active sur Android via onResume/onPause. onResume reprend la caméra, la géolocalisation et les capteurs — des ressources qui ne doivent être actives que lorsque l'application est visible pour l'utilisateur. onPause libère ces ressources pour éviter d'épuiser la batterie. L'API CameraX lifecycle-aware met automatiquement en pause l'aperçu lors d'onPause.

Bonnes pratiques pour gérer Active

Première règle — n'effectuez pas d'opérations lourdes dans applicationDidBecomeActive ou onResume. Chargement de données, analyse JSON, travail avec la base de données — tout cela doit être asynchrone et ne pas bloquer le thread principal. Utilisez GCD (DispatchQueue) sur iOS et Coroutines dans Kotlin pour les tâches d'arrière-plan. Le thread principal ne doit que mettre à jour l'UI et lancer des opérations asynchrones.

Deuxième règle — synchronisez l'état à chaque retour en Active. L'utilisateur peut avoir modifié les paramètres dans une application système, reçu une notification push ou mis à jour des données dans une autre application. Vérifiez la pertinence du cache lors de la transition vers Active — les données peuvent être obsolètes pendant l'absence de l'utilisateur.

Troisième règle — ne vous fiez pas à Active comme seul état. L'application peut sauter Active et passer directement de Not Running à Background (si elle est lancée en mode arrière-plan). Sur iOS, cela se produit lors du lancement via une notification push avec l'option content-available. Sur Android, lors du lancement via BroadcastReceiver. Vérifiez toujours l'état actuel avant d'effectuer des opérations UI.

Quatrième règle — utilisez l'Activity Result API sur Android au lieu d'onActivityResult. Cela permet de gérer le résultat d'appels à la caméra, à la galerie ou aux autorisations directement dans l'état Active sans perte de données lors de la recréation de l'Activity. Pour iOS, utilisez async/await avec UIApplication.shared.open pour les dialogues système.

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 {
            // Différer l'exécution jusqu'au retour en Active
            NotificationCenter.default.addObserver(
                forName: .appDidBecomeActive,
                object: nil,
                queue: .main
            ) { _ in
                block()
            }
        }
    }
}

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

Le code montre un gestionnaire d'état Active qui permet aux autres composants de l'application de vérifier l'état actif actuel. performWhenActive exécute le bloc immédiatement si l'application est active, ou diffère l'exécution jusqu'au retour en Active. C'est utile pour les services qui doivent effectuer une action après le retour de l'utilisateur dans l'application.