De 4 s a 800 ms: cómo arreglamos un arranque en frío

De 4 segundos a 800 ms: la odisea de un arranque en frío que casi nos cuesta la cordura

25 de septiembre de 2026

Te voy a contar una historia que empieza con un número y termina con otro. El primero es 4.000. El segundo, 800. Entre medias hay tres semanas de café, profileros abiertos a las 2 de la mañana y una discusión acalorada sobre si los perfiles de baseline eran magia negra o simplemente magia.

Vamos al lío.

El caso: una app que arrancaba como un PC de 2008

Imagina que tienes una app nativa. Bonita, funcional, con un equipo de diseño que se ha dejado el alma en cada animación. Todo perfecto. Hasta que llega el usuario, pulsa el icono y… espera. Y espera. Y sigue esperando.

Cuatro segundos. Cuatro segundos eternos hasta que aparece la primera pantalla útil. En el mundo del móvil, cuatro segundos es una barbaridad. Es el tiempo que tarda alguien en aburrirse, cerrar la app y abrir la de la competencia. Es la diferencia entre un usuario fiel y un usuario que ni se acuerda de que existías.

El equipo de producto lo notó en las métricas: la tasa de abandono en el primer arranque era brutal. Y no, no era culpa de la red. Era culpa nuestra. Del código. Del arranque en frío.

Así que me tocó a mí. Bueno, a mí y a un par de compañeros que, como yo, tienen una relación de amor-odio con los profileros.

Paso 1: medir antes de tocar nada (o el arte de no dispararse en el pie)

Lo primero que hice fue lo que debería hacer todo el mundo y casi nadie hace: medir. Porque sí, todos tenemos una intuición sobre dónde va lento el arranque, pero la intuición en rendimiento es como preguntarle a tu cuñado sobre política: suena convincente y suele estar equivocada.

Aquí entró en juego Macrobenchmark, la librería de benchmarking de Android que te permite medir el arranque de forma realista, sin trampas ni atajos. Nada de medir en un emulador con 16 GB de RAM y el modo avión activado. No. Medimos en dispositivos reales, con condiciones reales, y con el modo de arranque en frío bien configurado.

Los números que salieron fueron dolorosos:

• Arranque en frío medio: 4.100 ms
• Percentil 90: 5.300 ms
• Percentil 99: 6.800 ms

Ahí estaba. La app no arrancaba lenta. La app arrancaba como si le pesaran los pies.

Paso 2: entender qué demonios pasa en esos 4 segundos

Un arranque en frío en Android es una coreografía compleja. El sistema tiene que:

1. Cargar el proceso.
2. Inicializar la Application.
3. Ejecutar los proveedores de contenido.
4. Cargar clases.
5. Inflar la primera Activity.
6. Ejecutar el código de inicialización.
7. Y, si te descuidas, hacer llamadas de red que no deberían estar ahí.

Lo nuestro era un clásico: demasiado trabajo en el hilo principal. La Application hacía cosas que no le correspondían. Los proveedores de contenido inicializaban librerías que no se usaban hasta mucho después. Y el código de la primera pantalla cargaba recursos que no se necesitaban para el primer frame.

Vamos, que estábamos haciendo el equivalente a preparar un banquete de cinco platos antes de que el cliente haya pedido la bebida.

Paso 3: la revelación (o cómo descubrí los Baseline Profiles)

Aquí es donde entra el héroe de esta historia: los Baseline Profiles.

Si no los conoces, te lo resumo rápido: son archivos que le dicen al runtime de Android qué clases y métodos se usan durante el arranque, para que el compilador AOT (ahead-of-time) los optimice de antemano. Es como darle al sistema una lista de los ingredientes que vas a usar antes de que empiece a cocinar. En lugar de ir buscando cada cosa en la despensa, ya lo tiene todo a mano.

La diferencia entre no tener perfiles y tenerlos es, literalmente, la diferencia entre arrancar en frío y arrancar con el motor caliente.

Pero claro, no basta con generarlos y rezar. Hay que hacerlo bien:

1. Generar el perfil con Macrobenchmark: configuramos una prueba que simula el arranque en frío y captura las clases que se cargan.
2. Incluir el perfil en el build: se añade al APK como un archivo de texto que el sistema lee al instalar.
3. Verificar que se está aplicando: porque sí, a veces el perfil está ahí y el sistema pasa de él. Hay que asegurarse.

Paso 4: el día que todo cambió (y no, no fue magia)

Después de varias iteraciones, de pelearme con el Gradle, de descubrir que un proveedor de contenido estaba inicializando una librería de analítica que no se usaba hasta la tercera pantalla, y de mover un montón de trabajo fuera del hilo principal, llegó el momento de la verdad.

Volvimos a medir. Mismos dispositivos. Mismas condiciones. Mismo café.

• Arranque en frío medio: 820 ms
• Percentil 90: 980 ms
• Percentil 99: 1.200 ms

Casi cinco veces más rápido. De 4 segundos a 800 milisegundos. El equipo de producto pensó que habíamos hecho trampa. El de diseño, que si habíamos quitado animaciones. Y yo, que si alguien había tocado el código sin avisar.

No. Era real. Los Baseline Profiles, junto con una buena dosis de sentido común y eliminar trabajo innecesario del arranque, habían hecho su magia.

Paso 5: las lecciones (porque esto no es solo una historia bonita)

Si has llegado hasta aquí, te debo algo más que una anécdota. Te debo las lecciones. Estas son las que me llevo yo:

1. Mide antes de tocar. Sin datos, estás adivinando. Y adivinar en rendimiento es caro.

2. El arranque en frío no es un problema de un solo sitio. Es la Application, son los proveedores, es el inflado de la primera Activity, son las librerías que se inicializan sin necesidad. Hay que mirar todo.

3. Los Baseline Profiles no son opcionales. Si tienes una app nativa en Android y no los usas, estás dejando rendimiento sobre la mesa. Punto.

4. Macrobenchmark es tu amigo. No midas con cronómetros mentales. Mide con herramientas que simulan condiciones reales.

5. El trabajo del hilo principal es sagrado. Todo lo que puedas mover fuera, muévelo. El usuario no debería esperar a que inicialices una librería que no va a usar hasta dentro de tres pantallas.

6. La optimización no es un evento, es un proceso. Lo que hoy va rápido, mañana va lento porque alguien añadió una dependencia en la Application. Hay que medir de forma continua.

Reflexión final: el arte de quitar peso

Al final, esto no va de trucos ni de magia negra. Va de quitar peso. De entender que el arranque en frío es el momento más frágil de tu app, el primer apretón de manos con el usuario, y que cada milisegundo cuenta.

Pasamos de 4 segundos a 800 ms. Pero lo importante no fue el número. Fue entender por qué tardaba, dónde estaba el problema y cómo atacarlo con las herramientas correctas.

Así que te dejo una pregunta: ¿cuánto tarda tu app en arrancar en frío? Si no lo sabes, ya tienes algo que hacer este fin de semana. Y si lo sabes y son más de 2 segundos, ya tienes trabajo para el lunes.

Nos vemos en los profileros.