Grab corta ANRs em 32% e acelera o startup em 35% com R8 e Baseline Profiles
Aprofundamento CEVIU
Aprofundamento
O caso do Grab mostra o que acontece quando um app de 10 anos, com mais de 10 milhões de linhas de código e centenas de bibliotecas de terceiros, para de empurrar o problema com a barriga. O build é híbrido: Bazel no debug e Gradle nos builds de release com R8. Isso pesou, porque cada experimento com R8 podia levar até 2 horas no CI remoto. A saída foi alinhar os builds diários de QA ao comportamento de produção e automatizar a coleta de artefatos como mapping.txt e configuration.txt.
O ganho de ANR vem de um ponto específico. Os Cloud Profiles do Google Play não cobriam caminhos de inicialização críticos do Grab, como a montagem dos grafos do Dagger no launch. Sem cobertura, o app dependia de JIT e de otimização local nos dias seguintes à instalação. Com o Baseline Profile próprio, esses caminhos chegam compilados já na instalação. O R8 deu 12% de melhora no cold start e os Baseline Profiles mais 15%, somando 27%. Os picos de ANR a cada release semanal, ligados à leitura de muitos arquivos DEX, praticamente sumiram.
Para quem toca produto, tem um detalhe de custo contínuo. Medido com o app-sizer, o R8 baixou de forma permanente o custo em download de cada linha de código. Em tempos de código gerado por IA, em que o volume cresce rápido, isso segura o tamanho do app. O time ainda planeja guardrails de CI pré-merge, com justificativa e revisão para qualquer keep rule nova.
O que mudou
O resultado é feito de etapas. Na fase 1, em 2025, o R8 em modo compat com Baseline e Startup Profiles já entregou 25% menos ANRs, 16% menos tamanho de download e 27% de ganho no cold start. A fase 2, nove meses depois, levou ao R8 Full Mode e somou 14% de redução de tamanho, 10% de startup e 10% de ANRs. A fase 3, de refino das keep rules, acrescenta cerca de 3,6% de redução de tamanho. Os 32%, 30% e 35% finais são a soma disso tudo.
Por que isso importa
Startup lento, ANR e app inchado custam retenção e instalação. O Grab mostra um caminho replicável em base legada: ativar o otimizador aos poucos, restringir keep rules ao mínimo, medir os scores do R8 no CI e travar regressões antes do merge. A migração do Full Mode exigiu mexer em reflection, Gson e dynamic proxies, então reserve tempo de teste para isso.
Linha do tempo
Grab detalha corte de 32% nos ANRs e ganho de 35% no startup com R8 e Baseline Profiles.
Perguntas frequentes
Quanto o Grab melhorou em ANR, tamanho e startup?
A queda foi de cerca de 32% nos ANRs percebidos pelo usuário e de cerca de 30% no tamanho de download. O startup a frio ficou 35% mais rápido. O ganho veio de R8, Baseline Profiles, Startup Profiles e refino das keep rules.
Por que os Baseline Profiles ajudaram se o Google Play já tem Cloud Profiles?
Os Cloud Profiles não cobriam todos os caminhos de inicialização críticos do Grab, como o grafo de dependências do Dagger no launch. Fora da cobertura, o app rodava em JIT e otimizava localmente ao longo dos dias. O Baseline Profile próprio faz esses caminhos serem compilados já na instalação.
O que quebrou na migração para o R8 Full Mode?
Os pontos delicados foram o uso de reflection, o Gson e os dynamic proxies do Java. O R8 não enxerga o uso em runtime dos proxies e remove ou renomeia classes, o que causa crash. O time adotou as consumer keep rules do Gson mais recente e criou regras bem pontuais para as classes que dependem de reflection.
Como o Grab evita que os ganhos se percam com o tempo?
Ele usa o R8 Configuration Analyzer para medir os scores de otimização, shrinking e ofuscação e acompanha tudo em um dashboard de CI. A meta é integrar guardrails pré-merge, em que toda keep rule nova precise de justificativa e revisão.
Fontes
- developer.android.comfonte original
- Categoria
- CEVIU Startups, Tecnologia e Programação
- Publicado
- 21 de outubro de 2026
- Editoria
- CEVIU Startups, Tecnologia e Programação

