Inicialização e perfis de referência
Inicializações a frio mais rápidas.
Inicialização e perfis de referência é uma aula grátis de Android Academy no CoddyKit. Esta é a aula 4 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de Android Academy, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de Android Academy inclui 4 aulas no total.
Primeiras impressões: inicialização do aplicativo
O tempo de inicialização é a primeira coisa que todo usuário percebe. O Google Play até mesmo apresenta inicializações lentas como um problema de qualidade. Uma inicialização a frio rápida faz o aplicativo parecer sofisticado; uma lenta faz os usuários desistirem.
Nesta lição, você aprenderá os três tipos de inicialização, o que torna a inicialização lenta e as ferramentas modernas — Inicialização de aplicativos e Perfis de referência — que tornam as inicializações a frio muito mais rápidas.
Inicialização a frio, morna e quente
O Android define três cenários de inicialização, do mais lento ao mais rápido:
- Inicialização a frio: o processo não existe. O Android o cria, executa
Applicatione depois exibe sua primeira tela. É a mais lenta e a mais importante para otimizar. - Inicialização morna: o processo está ativo, mas a atividade precisa ser recriada.
- Inicialização quente: a atividade ainda está na memória; basta trazê-la para a frente. É quase instantânea.
Os esforços de otimização se concentram na inicialização a frio, pois é esse o cenário enfrentado com mais frequência por usuários novos e recorrentes.
Medindo o tempo de inicialização
Você não pode melhorar aquilo que não mede. Há duas maneiras simples:
- Logcat: o sistema registra uma linha
Displayedcom o tempo até o primeiro quadro. - Macrobenchmark:
StartupTimingMetricfornece números estáveis e reproduzíveis da inicialização a frio.
Execute o comando adb abaixo e procure a linha 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"Mantenha Application.onCreate leve
Tudo o que estiver em Application.onCreate() é executado na linha de execução principal antes do primeiro quadro. Uma inicialização pesada nesse ponto atrasa diretamente a inicialização.
A versão incorreta abaixo inicializa várias bibliotecas imediatamente. Adie ou execute em segundo plano tudo o que não for necessário para a primeira tela.
// 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.A biblioteca Jetpack App Startup
A biblioteca App Startup substitui vários provedores de conteúdo de bibliotecas (cada um consumindo tempo) por um único provedor compartilhado e permite expressar de forma clara a ordem e as dependências da inicialização.
Você implementa um Initializer por componente; o App Startup os executa uma vez, na ordem das dependências.
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.Inicialização tardia e em segundo plano
Melhor do que ordenar trabalhos imediatos é fazer menos trabalho durante a inicialização. Há duas estratégias:
- Tardia: crie objetos pesados no primeiro uso com o
by lazydo Kotlin. - Em segundo plano: mova a inicialização que não envolve a interface para fora da linha de execução principal.
Assim, o primeiro quadro não é bloqueado por um trabalho de que o usuário ainda não precisa.
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 versus JIT: por que a primeira execução é lenta
Por padrão, o Android executa o código de bytes do seu aplicativo com uma combinação de interpretação e compilação Just-In-Time (JIT). Na primeira vez que um trecho frequente é executado, ele é interpretado (lentamente); somente depois o ambiente de execução o compila em código nativo.
É exatamente por isso que a inicialização a frio e a primeira rolagem parecem mais lentas. Os Perfis de referência resolvem isso informando ao dispositivo quais códigos importantes devem ser compilados Ahead-Of-Time (AOT) durante a instalação.
O que é um perfil de referência
Um perfil de referência é uma lista das classes e dos métodos usados durante seus fluxos críticos (inicialização e primeira rolagem). Você o distribui com o aplicativo; durante a instalação, o dispositivo compila esses métodos com AOT, para que sejam executados na velocidade do código nativo desde o primeiro lançamento.
O Google relata melhorias na inicialização frequentemente na faixa de 20% a 40%, sem alterações no código dos recursos — apenas com o 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.Gerando um perfil de referência
Você gera o perfil escrevendo um pequeno teste que percorre o caminho crítico em um dispositivo; as ferramentas registram quais métodos foram executados e gravam o arquivo de perfil. Depois, você o confirma no controle de versão e recompila.
Veja um gerador típico que captura a inicialização e uma rolagem.
@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.Verificando o ganho
Sempre confirme a melhoria com um teste de desempenho, comparando a inicialização com e sem a aplicação do perfil (CompilationMode.None versus Partial com o perfil).
Se você não medir, não poderá provar que o perfil ajudou — e um perfil desatualizado pode até prejudicar o desempenho. Gere-o novamente sempre que seus caminhos frequentes mudarem 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()
}Um plano de otimização da inicialização
Reúna tudo em um plano reproduzível:
- Meça a inicialização a frio com Macrobenchmark e
adb am start -W. - Reduza o trabalho de
Application.onCreate: adie comby lazye mova o trabalho para fora da linha de execução principal. - Use o App Startup para combinar provedores de conteúdo e ordenar a inicialização.
- Distribua um perfil de referência para a compilação AOT do caminho crítico.
- Verifique com um teste de desempenho e mantenha o perfil atualizado.
O resultado: um primeiro quadro rápido que os usuários percebem.
Verificação rápida
Você distribui um perfil de referência com seu aplicativo. O que ele faz principalmente para melhorar a inicialização?
Recapitulação: rápido desde o primeiro quadro
Você aprendeu a otimizar a inicialização, a métrica de desempenho mais visível:
- Otimize a inicialização a frio; meça com Macrobenchmark e
adb am start -W. - Mantenha
Application.onCreateleve: inicialização tardia e trabalho que não envolve a interface em segundo plano. - Use a biblioteca App Startup para combinar provedores e ordenar inicializadores.
- Distribua um perfil de referência para que o código frequente seja compilado com AOT durante a instalação e execute na velocidade nativa desde a primeira execução.
- Sempre verifique o ganho com um teste de desempenho e mantenha o perfil atualizado.
Isso conclui Otimização e criação de perfis de desempenho: agora você pode medir, controlar a recomposição, corrigir vazamentos e fazer o aplicativo iniciar rapidamente.
Perguntas Frequentes
A aula “Inicialização e perfis de referência” é grátis?
Sim — o texto completo de “Inicialização e perfis de referência” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de Android Academy, atualize para CoddyKit PRO. O curso de Android Academy inclui 4 aulas no total.
O que vou aprender em “Inicialização e perfis de referência”?
Inicializações a frio mais rápidas. Você pratica Android Academy com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.
Preciso ter experiência prévia para começar Android Academy?
Nenhuma experiência prévia é necessária. Android Academy no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 4 de 4.
Quanto tempo leva a aula “Inicialização e perfis de referência”?
A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.
Posso escrever e executar código nesta aula de Android Academy?
Sim. Cada aula de Android Academy inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.
Todas as aulas deste curso
- Medindo o desempenho
- Dominando a recomposição
- Vazamentos de memória e correções
- Inicialização e perfis de referência