Hot Start en aplicaciones móviles: qué es, factores y cómo acelerarlo

Qué es Hot Start en aplicaciones móviles

Hot Start es un escenario de inicio donde el proceso de la aplicación ya existe en la RAM del dispositivo. El usuario minimiza la aplicación, luego regresa — y el sistema no crea un nuevo proceso sino que reanuda el existente. En este escenario, no se requiere carga del SO, inicialización de la clase Application ni creación de procesos, lo que reduce drásticamente el tiempo hasta que la UI aparece en pantalla. Según la documentación de Android (2025), Hot Start toma solo 200–500 ms, mientras que Cold Start puede alcanzar 5 segundos o más. La diferencia de velocidad es especialmente notable en dispositivos con memoria limitada, donde el sistema descarga aplicaciones en segundo plano con más frecuencia.

La característica principal de Hot Start es el conjunto mínimo de métodos del ciclo de vida llamados. En Android, estos son Activity.onCreate y Activity.onStart; en iOS, es applicationDidBecomeActive. A diferencia de Cold Start, donde se llaman secuencialmente Application.onCreate, ContentProvider.onCreate, Activity.onCreate y muchas inicializaciones de bibliotecas, Hot Start omite todas estas etapas. El desarrollador debe entender qué código se ejecuta específicamente durante un inicio en caliente — a menudo, inicializaciones pesadas de SDK, analíticas y contenedores DI se repiten tanto en Cold como en Hot Start, aunque ya no sean necesarias durante un inicio en caliente.

Cold Start, Warm Start y Hot Start: comparación

Los tres escenarios de inicio de aplicación difieren en la profundidad de inicialización. Cold Start ocurre cuando la aplicación se inicia por primera vez después de la instalación, reinicio del dispositivo o eliminación de la memoria. El sistema crea un nuevo proceso Linux, carga las clases de Application, crea instancias de ContentProvider, realiza la inicialización de bibliotecas y solo luego renderiza la Activity. Todo el proceso toma de 2 a 10 segundos dependiendo de la complejidad de la aplicación y las características del dispositivo.

Warm Start es un escenario intermedio. El proceso de la aplicación está vivo en memoria, pero la Activity fue destruida y debe ser recreada. Esto sucede, por ejemplo, al rotar la pantalla o al regresar de otra aplicación donde la Activity fue eliminada por falta de memoria pero el proceso permaneció. Warm Start incluye llamar a Activity.onCreate y Activity.onStart, pero no incluye Application.onCreate ni la inicialización de ContentProvider. El tiempo de Warm Start es de 500 ms a 2 segundos. Hot Start es el más rápido de los tres: la Activity ya existe en la pila de retroceso, el proceso está vivo y el sistema simplemente llama a Activity.onRestart, onStart y onResume. El tiempo de Hot Start es de 200–500 ms. La diferencia con Warm Start es que la Activity no se crea de nuevo — se restaura desde la instancia existente.

Ciclo de vida de Android durante Hot Start

En Android, Hot Start se activa cuando el usuario regresa a la aplicación a través de la pantalla de Recientes o tocando el icono de la aplicación mientras está minimizada. El sistema verifica si el proceso está vivo y, de ser así, llama secuencialmente a Activity.onRestart, onStart y onResume. El método onCreate no se llama durante Hot Start porque la instancia de Activity ya existe en memoria. Esta es una diferencia importante con Warm Start, donde onCreate aún se llama debido a la destrucción de la Activity. Según Google I/O 2019, el tiempo típico de Hot Start en Android es de 200–400 ms, y cualquier ralentización en esta etapa aumenta directamente el tiempo de inicio percibido.

Los desarrolladores a menudo pasan por alto que el código de inicialización de UI, las suscripciones a LiveData o la configuración de RecyclerView se realizan no solo en onCreate sino también en onStart u onResume. Durante Hot Start, estos bloques de código se ejecutan nuevamente, aunque la UI ya estaba configurada. Se recomienda separar la inicialización única (en onCreate con verificación de savedInstanceState) y la lógica reanudable (onStart/onResume). Por ejemplo, las operaciones pesadas — configuración de adaptadores, carga de listas — deben moverse a un bloque que no se ejecute durante onRestart, o verificar savedInstanceState.

Ejemplo de seguimiento del tipo de inicio

El siguiente código en Kotlin demuestra una forma sencilla de detectar el escenario de inicio y medir el tiempo. La variable launchTimeStamp captura el momento de inicio, y isColdStart permite separar la lógica para inicio en frío y en caliente.

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()
            // inicialización única
        } else {
            isColdStart = false
            // Hot Start — Activity se restaura
        }
    }

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

Ciclo de vida de iOS durante el inicio en caliente

En iOS, Hot Start corresponde a regresar la aplicación desde segundo plano a través de sceneDidBecomeActive (UIKit) o onAppear (SwiftUI). El sistema operativo no recrea el proceso si la aplicación estaba en estado Suspendido o en Segundo plano. Durante un inicio en caliente, se llama a applicationDidBecomeActive en AppDelegate, pero no se llama a applicationDidFinishLaunching — esto es análogo a Android donde se omite Application.onCreate. iOS elimina las aplicaciones de la memoria de forma más agresiva: si el dispositivo no tiene suficiente RAM, el sistema puede eliminar una aplicación en segundo plano, y el siguiente inicio será un Cold Start. Según la documentación de Apple Developer, el tiempo promedio de Hot Start en iOS es de 300–600 ms.

Una diferencia clave en iOS es la falta de un análogo directo de Warm Start en el sentido de Android. En iOS, cuando se minimiza una aplicación, se llama a sceneDidEnterBackground, y al regresar, se llama a sceneWillEnterForeground y sceneDidBecomeActive. Si el sistema elimina la escena pero mantiene el proceso vivo, el siguiente inicio será Cold desde la perspectiva de la escena pero Hot desde la perspectiva del proceso. El desarrollador debe considerar esto al colocar el código de inicialización: las suscripciones a NotificationCenter, las actualizaciones de UI y los reseteos de estado deben estar en sceneDidBecomeActive, no solo en viewDidLoad.

Ejemplo de manejo de Hot Start en iOS

Este código en Swift muestra cómo rastrear el número de inicios en caliente y separar la lógica. El contador foregroundCount se incrementa en cada regreso desde segundo plano.

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var foregroundCount = 0

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

        if foregroundCount == 1 {
            // Cold Start — inicialización completa
            setupSDKs()
        } else {
            // Hot Start — solo actualización de UI
            refreshUI()
        }
    }

    private func refreshUI() {
        // actualización de datos en pantalla
    }
}

Factores que afectan la velocidad de Hot Start

Varias categorías de factores afectan la velocidad de Hot Start. La primera es la cantidad de trabajo en los métodos del ciclo de vida onStart y onResume. Si el desarrollador colocó carga de datos de red, análisis JSON, inicialización de adaptadores o cálculos pesados en estos métodos, cada bloque agrega decenas o cientos de milisegundos al tiempo de inicio. Según Android Vitals, las aplicaciones con una duración de Hot Start superior a 800 ms pierden hasta el 20% de los usuarios al regresar.

La segunda categoría son los fragmentos y Vistas restaurados desde savedInstanceState. Si los fragmentos contienen ViewPager2 pesado, WebView o jerarquías complejas profundamente anidadas, su restauración consume recursos de CPU. Según Google I/O 2023, cada ViewGroup anidado agrega en promedio 2–5 ms al tiempo de renderizado durante Hot Start. La tercera categoría son los SDK de terceros: las bibliotecas de analítica, informes de fallos, pruebas A/B y cargadores DEX pueden realizar inicialización en cada regreso desde segundo plano. Se recomienda verificar qué SDK ejecutan código específicamente en onStart/onResume y diferir las tareas no críticas a un hilo en segundo plano.

Métodos de optimización del inicio en caliente

La optimización de Hot Start se reduce a minimizar el trabajo en los métodos del ciclo de vida de reanudación. El primer método es la inicialización perezosa: cualquier código que no sea necesario para el primer fotograma de la UI debe ejecutarse después de onResume con un retraso mediante Handler.postDelayed o Coroutine.launch(Dispatchers.IO). El segundo método es el almacenamiento en caché del estado de la Vista: cuando la aplicación se minimiza, guarde los datos en un caché en memoria para que durante Hot Start no tenga que recargarlos desde la base de datos o la red. El tercer método es usar SavedStateHandle en Android y StateRestorationPolicy en iOS para minimizar la cantidad de datos restaurados.

Carga perezosa después de Hot Start

En este ejemplo, Handler.postDelayed pospone la inicialización de analítica 500 ms después de renderizar el primer fotograma. Esto no afecta el tiempo de inicio percibido porque el usuario ya ve la interfaz.

class AnalyticsDeferrer {

    fun lazyInitAfterHotStart() {
        val handler = Handler(Looper.getMainLooper())
        handler.postDelayed({
            // inicialización después del primer fotograma
            Analytics.init(Application.getInstance())
            CrashReporter.start()
        }, 500)
    }
}

Uso de la biblioteca App Startup

AndroidX App Startup le permite controlar el orden de inicialización de los componentes al inicio. Todos los ContentProvider se inicializan automáticamente durante Cold Start, pero puede desactivar la inicialización automática para componentes que no sean necesarios durante 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<*>>()
}

Herramientas de monitoreo del tiempo de inicio

Para medir el tiempo de Hot Start, existen tanto herramientas integradas de las plataformas como soluciones de terceros. En Android, la herramienta clave es Android Vitals en Google Play Console — recopila automáticamente métricas de tiempo de inicio para todos los escenarios (Cold, Warm, Hot) desglosadas por modelo de dispositivo y versión del SO. Adicionalmente, puede usar Macrobenchmark de AndroidX — una biblioteca para pruebas automatizadas de rendimiento de inicio. En iOS, el equivalente es MetricKit, que recopila datos sobre tiempo de inicio, frecuencia de cuadros y uso de memoria.

Para la creación de perfiles detallados de inicio en caliente, son adecuados Firebase Performance Monitoring (rastrea trazas personalizadas) y New Relic con paneles de tiempo de inicio. Del lado del desarrollador, para la medición manual se usa reportFullyDrawn en Android — una API que informa al sistema el momento exacto en que la UI está renderizada y lista para la interacción. En iOS, el equivalente es endActivity en MetricKit. Combinando estas herramientas, puede identificar qué SDK o bloque de código ralentiza Hot Start en dispositivos específicos.

Ejemplo de Macrobenchmark para Hot Start

Código en Kotlin que utiliza la biblioteca Macrobenchmark para medir Cold y Hot Start. La prueba inicia la Activity y mide el tiempo hasta el estado completo.

@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()
        }
    }
}