Hot Start dans les applications mobiles : définition, facteurs et comment l'accélérer

Qu'est-ce que le Hot Start dans les applications mobiles

Hot Start est un scénario de lancement où le processus de l'application existe déjà dans la RAM de l'appareil. L'utilisateur réduit l'application, puis revient — et le système ne crée pas un nouveau processus mais reprend l'existant. Dans ce scénario, aucun chargement de l'OS, d'initialisation de la classe Application ou de création de processus n'est nécessaire, ce qui réduit considérablement le temps jusqu'à l'apparition de l'UI à l'écran. Selon la documentation Android (2025), Hot Start ne prend que 200 à 500 ms, alors que Cold Start peut atteindre 5 secondes ou plus. La différence de vitesse est particulièrement notable sur les appareils à mémoire limitée, où le système décharge plus fréquemment les applications en arrière-plan.

La principale caractéristique de Hot Start est l'ensemble minimal de méthodes du cycle de vie appelées. Sous Android, ce sont Activity.onCreate et Activity.onStart ; sous iOS, c'est applicationDidBecomeActive. Contrairement à Cold Start, où Application.onCreate, ContentProvider.onCreate, Activity.onCreate et de nombreuses initialisations de bibliothèques sont appelées séquentiellement, Hot Start saute toutes ces étapes. Le développeur doit comprendre quel code s'exécute spécifiquement lors d'un démarrage à chaud — souvent, les initialisations lourdes de SDK, d'analyses et de conteneurs DI sont répétées à la fois en Cold et Hot Start, bien qu'elles ne soient plus nécessaires lors d'un démarrage à chaud.

Cold Start, Warm Start et Hot Start : comparaison

Les trois scénarios de lancement d'application diffèrent par la profondeur d'initialisation. Cold Start se produit lorsque l'application est lancée pour la première fois après l'installation, un redémarrage de l'appareil ou une éviction de la mémoire. Le système crée un nouveau processus Linux, charge les classes Application, crée des instances ContentProvider, effectue l'initialisation des bibliothèques et seulement ensuite rend l'Activity. L'ensemble du processus prend 2 à 10 secondes selon la complexité de l'application et les caractéristiques de l'appareil.

Warm Start est un scénario intermédiaire. Le processus de l'application est vivant en mémoire, mais l'Activity a été détruite et doit être recréée. Cela se produit, par exemple, lors d'une rotation de l'écran ou lors du retour d'une autre application où l'Activity a été supprimée par manque de mémoire mais le processus est resté. Warm Start inclut l'appel de Activity.onCreate et Activity.onStart, mais n'inclut pas Application.onCreate ni l'initialisation de ContentProvider. Le temps de Warm Start est de 500 ms à 2 secondes. Hot Start est le plus rapide des trois : l'Activity existe déjà dans la pile de retour, le processus est vivant, et le système appelle simplement Activity.onRestart, onStart et onResume. Le temps de Hot Start est de 200 à 500 ms. La différence avec Warm Start est que l'Activity n'est pas créée à nouveau — elle est restaurée à partir de l'instance existante.

Cycle de vie Android pendant Hot Start

Sous Android, Hot Start est déclenché lorsque l'utilisateur revient à l'application via l'écran des Récentes ou en tapant sur l'icône de l'application en état réduit. Le système vérifie si le processus est vivant et, si c'est le cas, appelle séquentiellement Activity.onRestart, onStart et onResume. La méthode onCreate n'est pas appelée pendant Hot Start car l'instance de l'Activity existe déjà en mémoire. C'est une différence importante avec Warm Start, où onCreate est encore appelé en raison de la destruction de l'Activity. Selon Google I/O 2019, le temps typique de Hot Start sous Android est de 200 à 400 ms, et tout ralentissement à cette étape augmente directement le temps de lancement perçu.

Les développeurs négligent souvent que le code d'initialisation de l'UI, les abonnements LiveData ou la configuration de RecyclerView sont effectués non seulement dans onCreate mais aussi dans onStart ou onResume. Pendant Hot Start, ces blocs de code s'exécutent à nouveau, même si l'UI était déjà configurée. Il est recommandé de séparer l'initialisation unique (dans onCreate avec vérification de savedInstanceState) et la logique reprenable (onStart/onResume). Par exemple, les opérations lourdes — configuration des adaptateurs, chargement des listes — doivent être déplacées dans un bloc qui ne s'exécute pas pendant onRestart, ou vérifier savedInstanceState.

Exemple de suivi du type de lancement

Le code Kotlin suivant montre une façon simple de détecter le scénario de lancement et de mesurer le temps. La variable launchTimeStamp capture le moment du début du lancement, et isColdStart permet de séparer la logique pour le démarrage à froid et à chaud.

class MainActivity : AppCompatActivity() {

    private var launchTimeStamp = 0L
    private var isColdStart = true

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        if (savedInstanceState == null) {
            isColdStart = true
            launchTimeStamp = System.currentTimeMillis()
            // initialisation unique
        } else {
            isColdStart = false
            // Hot Start — Activity est restaurée
        }
    }

    override fun onResume() {
        super.onResume()
        if (isColdStart) {
            val launchTime =
                System.currentTimeMillis() - launchTimeStamp
            Log.d("LaunchTime", "Cold Start : $launchTime ms")
        }
    }
}

Cycle de vie iOS lors d'un démarrage à chaud

Sous iOS, Hot Start correspond au retour de l'application depuis l'arrière-plan via sceneDidBecomeActive (UIKit) ou onAppear (SwiftUI). Le système d'exploitation ne recrée pas le processus si l'application était dans un état Suspendu ou en Arrière-plan. Lors d'un démarrage à chaud, applicationDidBecomeActive est appelé dans AppDelegate, mais applicationDidFinishLaunching n'est pas appelé — c'est analogue à Android où Application.onCreate est sauté. iOS décharge les applications de la mémoire de manière plus agressive : si l'appareil manque de RAM, le système peut décharger une application en arrière-plan, et le lancement suivant sera un Cold Start. Selon la documentation Apple Developer, le temps moyen de Hot Start sous iOS est de 300 à 600 ms.

Une différence clé sous iOS est l'absence d'analogue direct de Warm Start au sens Android. Sous iOS, lorsqu'une application est réduite, sceneDidEnterBackground est appelé, et au retour, sceneWillEnterForeground et sceneDidBecomeActive sont appelés. Si le système décharge la scène mais maintient le processus en vie, le lancement suivant sera Cold du point de vue de la scène mais Hot du point de vue du processus. Le développeur doit en tenir compte lors du placement du code d'initialisation : les abonnements à NotificationCenter, les mises à jour de l'UI et les réinitialisations d'état doivent être dans sceneDidBecomeActive, pas seulement dans viewDidLoad.

Exemple de gestion de Hot Start sous iOS

Ce code Swift montre comment suivre le nombre de démarrages à chaud et séparer la logique. Le compteur foregroundCount s'incrémente à chaque retour de l'arrière-plan.

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var foregroundCount = 0

    func sceneDidBecomeActive(
        _ scene: UIScene
    ) {
        foregroundCount += 1

        if foregroundCount == 1 {
            // Cold Start — initialisation complète
            setupSDKs()
        } else {
            // Hot Start — mise à jour UI uniquement
            refreshUI()
        }
    }

    private func refreshUI() {
        // mise à jour des données à l'écran
    }
}

Facteurs influençant la vitesse de Hot Start

Plusieurs catégories de facteurs influencent la vitesse de Hot Start. La première est la quantité de travail dans les méthodes du cycle de vie onStart et onResume. Si le développeur a placé le chargement de données réseau, l'analyse JSON, l'initialisation d'adaptateurs ou des calculs lourds dans ces méthodes, chaque bloc ajoute des dizaines ou des centaines de millisecondes au temps de démarrage. Selon Android Vitals, les applications avec une durée de Hot Start supérieure à 800 ms perdent jusqu'à 20 % des utilisateurs au retour.

La deuxième catégorie concerne les fragments et les vues restaurés à partir de savedInstanceState. Si les fragments contiennent un ViewPager2 lourd, une WebView ou des hiérarchies complexes profondément imbriquées, leur restauration consomme des ressources CPU. Selon Google I/O 2023, chaque ViewGroup imbriqué ajoute en moyenne 2 à 5 ms au temps de rendu pendant Hot Start. La troisième catégorie concerne les SDK tiers : les bibliothèques d'analyse, de rapport de crash, de tests A/B et les chargeurs DEX peuvent effectuer une initialisation à chaque retour de l'arrière-plan. Il est recommandé de vérifier quels SDK exécutent du code spécifiquement dans onStart/onResume et de différer les tâches non critiques sur un thread d'arrière-plan.

Méthodes d'optimisation du démarrage à chaud

L'optimisation de Hot Start se résume à minimiser le travail dans les méthodes du cycle de vie de reprise. La première méthode est l'initialisation paresseuse : tout code non nécessaire pour la première image de l'UI doit s'exécuter après onResume avec un délai via Handler.postDelayed ou Coroutine.launch(Dispatchers.IO). La deuxième méthode est la mise en cache de l'état de la vue : lorsque l'application est réduite, sauvegardez les données dans un cache en mémoire pour ne pas avoir à les recharger depuis la base de données ou le réseau pendant Hot Start. La troisième méthode consiste à utiliser SavedStateHandle sous Android et StateRestorationPolicy sous iOS pour minimiser la quantité de données restaurées.

Chargement paresseux après Hot Start

Dans cet exemple, Handler.postDelayed retarde l'initialisation des analyses de 500 ms après le rendu de la première image. Cela n'affecte pas le temps de lancement perçu car l'utilisateur voit déjà l'interface.

class AnalyticsDeferrer {

    fun lazyInitAfterHotStart() {
        val handler = Handler(Looper.getMainLooper())
        handler.postDelayed({
            // initialisation après la première image
            Analytics.init(Application.getInstance())
            CrashReporter.start()
        }, 500)
    }
}

Utilisation de la bibliothèque App Startup

AndroidX App Startup permet de contrôler l'ordre d'initialisation des composants au lancement. Tous les ContentProvider sont initialisés automatiquement pendant Cold Start, mais vous pouvez désactiver l'initialisation automatique pour les composants non nécessaires pendant Hot Start.

@Initializer(Application::class)
class SdkInitializer : Initializer<Unit> {

    override fun create(context: Context) {
        SdkOne.init(context)
        SdkTwo.init(context)
    }

    override fun dependencies() = emptyList<Class<*>>()
}

Outils de surveillance du temps de lancement

Pour mesurer le temps de Hot Start, il existe à la fois des outils intégrés aux plateformes et des solutions tierces. Sous Android, l'outil clé est Android Vitals dans la Google Play Console — il collecte automatiquement les métriques de temps de lancement pour tous les scénarios (Cold, Warm, Hot) ventilées par modèle d'appareil et version d'OS. De plus, vous pouvez utiliser Macrobenchmark d'AndroidX — une bibliothèque pour les tests automatisés de performance de démarrage. Sous iOS, l'équivalent est MetricKit, qui collecte des données sur le temps de lancement, le taux d'images et l'utilisation de la mémoire.

Pour le profilage détaillé du démarrage à chaud, Firebase Performance Monitoring (suit les traces personnalisées) et New Relic avec des tableaux de bord de temps de lancement sont adaptés. Côté développeur pour la mesure manuelle, reportFullyDrawn sous Android est utilisé — une API qui indique au système le moment exact où l'UI est rendue et prête pour l'interaction. Sous iOS, l'équivalent est endActivity dans MetricKit. En combinant ces outils, vous pouvez identifier quel SDK ou bloc de code ralentit Hot Start sur des appareils spécifiques.

Exemple de Macrobenchmark pour Hot Start

Code Kotlin utilisant la bibliothèque Macrobenchmark pour mesurer Cold et Hot Start. Le test lance l'Activity et mesure le temps jusqu'à l'état complet.

@RunWith(AndroidJUnit4::class)
class StartupBenchmark {

    @get:Rule
    val benchmarkRule = MacrobenchmarkRule()

    @Test
    fun hotStart() {
        benchmarkRule.measureRepeated(
            packageName = "com.example.app",
            metrics = listOf(StartupTimingMetric()),
            iterations = 10,
            startupMode = StartupMode.HOT
        ) {
            pressHome()
            startActivityAndWait()
        }
    }
}