Perfiles de inicio y de referencia
Arranques en frío más rápidos
Perfiles de inicio y de referencia es una lección gratuita de Android Academy en CoddyKit. Esta es la lección 4 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de Android Academy, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de Android Academy incluye 4 lecciones en total.
La primera impresión: inicio de la aplicación
El tiempo de inicio es lo primero que experimenta cada usuario. Google Play incluso muestra los inicios lentos como un problema de calidad. Un inicio en frío rápido hace que una aplicación transmita calidad; uno lento hace que los usuarios la abandonen.
En esta lección aprenderá los tres tipos de inicio, qué hace que el inicio sea lento y las herramientas modernas —App Startup y Baseline Profiles— que hacen que los inicios en frío sean mucho más rápidos.
Inicio en frío, templado y en caliente
Android define tres escenarios de inicio, del más lento al más rápido:
- Cold start: el proceso no existe. Android lo crea, ejecuta
Applicationy, después, muestra la primera pantalla. Es el más lento y el más importante de optimizar. - Warm start: el proceso sigue activo, pero es necesario volver a crear la Activity.
- Hot start: la Activity sigue en memoria; solo hay que traerla al frente. Es casi instantáneo.
Los esfuerzos de optimización se centran en el cold start, porque es el escenario al que se enfrentan con mayor frecuencia los usuarios nuevos y los que regresan.
Medición del tiempo de inicio
No puede mejorar lo que no mide. Tiene dos formas sencillas de hacerlo:
- Logcat: el sistema registra una línea
Displayedcon el tiempo hasta el primer frame. - Macrobenchmark:
StartupTimingMetricproporciona mediciones estables y repetibles del inicio en frío.
Ejecute el comando adb siguiente y busque la línea Displayed.
# Cold-start the app and log time to first frame
adb shell am start -W -S com.example.app/.MainActivity
# Output includes:
# TotalTime: 412 <- ms to first frame
# Or filter logcat:
adb logcat | grep "Displayed com.example.app"Mantenga ligero Application.onCreate
Todo lo que se ejecuta en Application.onCreate() se ejecuta en el hilo principal antes del primer frame. La inicialización pesada aquí retrasa directamente el inicio.
La versión incorrecta siguiente inicializa varias bibliotecas de forma inmediata. Aplace o ejecute en segundo plano todo lo que no sea necesario para la primera pantalla.
// SLOW: blocks the first frame with eager init
class MyApp : Application() {
override fun onCreate() {
super.onCreate()
Analytics.init(this) // network, disk
ImageLoader.preload(this) // heavy
Database.warmUp(this) // disk I/O
}
}
// Each of these adds milliseconds before the user sees anything.La biblioteca Jetpack App Startup
La biblioteca App Startup sustituye varios content providers de bibliotecas (cada uno consume tiempo) por uno único y compartido, y permite expresar de forma clara el orden de inicialización y las dependencias.
Implemente un Initializer por componente; App Startup los ejecutará una vez y en el orden de sus dependencias.
class AnalyticsInitializer : Initializer<Analytics> {
override fun create(context: Context): Analytics {
return Analytics.init(context.applicationContext)
}
// Runs after Logger is ready
override fun dependencies() = listOf(LoggerInitializer::class.java)
}
// Registered via a single merged provider in the manifest,
// avoiding one ContentProvider per library.Inicialización diferida y en segundo plano
Mejor que ordenar el trabajo inmediato es hacer menos trabajo durante el inicio. Hay dos estrategias:
- Lazy: cree objetos pesados cuando se utilicen por primera vez mediante
by lazyde Kotlin. - En segundo plano: ejecute la inicialización que no sea de UI fuera del hilo principal.
Así, el primer frame no queda bloqueado por trabajo que el usuario todavía no necesita.
class MyApp : Application() {
// Built only when first accessed, not during onCreate
val imageLoader by lazy { ImageLoader.build(this) }
override fun onCreate() {
super.onCreate()
// Push non-critical setup off the main thread
CoroutineScope(Dispatchers.Default).launch {
Analytics.init(applicationContext)
}
}
}AOT frente a JIT: por qué la primera ejecución es lenta
De forma predeterminada, Android ejecuta el bytecode de su aplicación mediante una combinación de interpretación y compilación Just-In-Time (JIT). La primera vez que se ejecuta código frecuente, se interpreta (es lento); solo después el runtime lo compila a código nativo.
Por eso el inicio en frío y el primer desplazamiento resultan más lentos. Los Baseline Profiles lo solucionan indicando al dispositivo que compile Ahead-Of-Time (AOT) el código importante durante la instalación.
Qué es un Baseline Profile
Un Baseline Profile es una lista de las clases y métodos que se ejecutan durante sus recorridos críticos (inicio y primer desplazamiento). Se incluye con la aplicación; durante la instalación, el dispositivo compila esos métodos mediante AOT, de modo que se ejecutan a velocidad nativa desde el primer lanzamiento.
Google informa de mejoras del inicio que suelen situarse entre el 20 % y el 40 %, sin cambios en el código de sus funcionalidades: solo es necesario el perfil.
// build.gradle.kts
plugins { id("androidx.baselineprofile") }
dependencies {
baselineProfile(project(":baselineprofile"))
}
// The generated profile ships as
// assets/dexopt/baseline.prof
// and is applied automatically at install.Generación de un Baseline Profile
Para generar el perfil, escriba una prueba pequeña que recorra la ruta crítica en un dispositivo; las herramientas registran qué métodos se ejecutaron y escriben el archivo de perfil. Después, confirme los cambios y vuelva a compilar.
Este es un generador típico que captura el inicio y un desplazamiento.
@RunWith(AndroidJUnit4::class)
class BaselineProfileGenerator {
@get:Rule val rule = BaselineProfileRule()
@Test
fun generate() = rule.collect(packageName = "com.example.app") {
pressHome()
startActivityAndWait()
// exercise the critical journey
device.findObject(By.res("feed")).fling(Direction.DOWN)
}
}
// Run the generateBaselineProfile Gradle task to produce the file.Verificación de la mejora
Confirme siempre la mejora con un benchmark, comparando el inicio con y sin el perfil aplicado (CompilationMode.None frente a Partial con el perfil).
Si no mide, no puede demostrar que el perfil haya ayudado, y un perfil desactualizado incluso puede perjudicar el rendimiento. Regenérelo siempre que sus rutas críticas cambien significativamente.
@Test
fun startupWithProfile() = rule.measureRepeated(
packageName = "com.example.app",
metrics = listOf(StartupTimingMetric()),
iterations = 10,
startupMode = StartupMode.COLD,
compilationMode = CompilationMode.Partial() // uses the baseline profile
) {
pressHome()
startActivityAndWait()
}Plan de optimización del inicio
Reúna todo en un plan repetible:
- Mida el inicio en frío con Macrobenchmark y
adb am start -W. - Reduzca
Application.onCreate: aplace trabajo conby lazyy mueva el trabajo fuera del hilo principal. - Use App Startup para combinar content providers y ordenar la inicialización.
- Incluya un Baseline Profile para compilar mediante AOT la ruta crítica.
- Verifique la mejora con un benchmark y mantenga actualizado el perfil.
El resultado: un primer frame rápido que los usuarios notan.
Comprobación rápida
Incluye un Baseline Profile con su aplicación. ¿Qué hace principalmente para mejorar el inicio?
Repaso: rapidez desde el primer frame
Ha aprendido a optimizar el inicio, la métrica de rendimiento más visible:
- Optimice el cold start; mídalo con Macrobenchmark y
adb am start -W. - Mantenga ligero
Application.onCreate: inicialización lazy y trabajo que no sea de UI en segundo plano. - Use la biblioteca App Startup para combinar providers y ordenar los initializers.
- Incluya un Baseline Profile para que el código frecuente se compile mediante AOT durante la instalación y se ejecute a velocidad nativa desde la primera ejecución.
- Siempre verifique la mejora con un benchmark y mantenga actualizado el perfil.
Con esto completa Optimización y creación de perfiles de rendimiento: ahora puede medir, controlar la recomposición, corregir fugas e iniciar la aplicación rápidamente.
Preguntas frecuentes
¿La lección «Perfiles de inicio y de referencia» es gratis?
Sí — el texto completo de «Perfiles de inicio y de referencia» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de Android Academy, actualiza a CoddyKit PRO. El curso de Android Academy incluye 4 lecciones en total.
¿Qué aprenderé en «Perfiles de inicio y de referencia»?
Arranques en frío más rápidos Practicas Android Academy con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.
¿Necesito experiencia previa para empezar Android Academy?
No se requiere experiencia previa. Android Academy en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 4 de 4.
¿Cuánto tiempo toma la lección «Perfiles de inicio y de referencia»?
La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.
¿Puedo escribir y ejecutar código en esta lección de Android Academy?
Sí. Cada lección de Android Academy incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.
Todas las lecciones de este curso
- Medición del rendimiento
- Cómo controlar la recomposición
- Fugas de memoria y soluciones
- Perfiles de inicio y de referencia