A Grab reduz os ANRs em 32% e melhora o tempo de inicialização em 35% com o R8 e a otimização guiada por perfil

O Grab é o principal superapp do Sudeste Asiático, oferecendo serviços de entrega, mobilidade e finanças para milhões de usuários em oito países em um único app. Com uma base de código de 10 anos que contém mais de 10 milhões de linhas de código e centenas de bibliotecas de terceiros criadas usando uma configuração híbrida do Bazel e do Gradle, a equipe do Grab enfrentou três desafios crescentes: altas taxas de erros "O app não está respondendo" (ANR), um tamanho de app que continuava crescendo à medida que o superapp adicionava novos serviços e um tempo de inicialização que aumentava lentamente ano a ano.  Ao ativar a otimização do R8, refinar as regras de manutenção e implementar perfis de referência e de inicialização, o Grab reduziu a taxa de ANR percebida pelo usuário em 32%, diminuiu o tamanho do download do app em cerca de 30% e melhorou o tempo de inicialização em 35%.

Eliminating Post-Release ANR Spikes for a Smoother User Experience (em inglês)

Antes de otimizar o processo de build, o Grab enfrentava atrasos na inicialização a frio e picos de erros "O app não está respondendo" (ANR) logo após novas atualizações, principalmente devido à sobrecarga de leitura de muitos arquivos DEX durante a inicialização do app. 

Embora os perfis de nuvem do Google Play tenham otimizado os fluxos padrão em toda a base de usuários, eles não otimizam todos os caminhos de inicialização necessários para as jornadas ideais do usuário do Grab, como a inicialização de gráficos de dependência do Dagger durante o lançamento do app. Para caminhos de código não cobertos na distribuição inicial, os dispositivos dependiam da compilação JIT e da otimização em segundo plano local nos dias seguintes. A implementação de um perfil de referência personalizado resolveu esse problema ao fornecer essas jornadas ideais do usuário diretamente aos perfis de nuvem do Google Play, expandindo a cobertura de otimização para que esses caminhos principais fossem compilados em código de máquina imediatamente após a instalação. 

"Sempre tínhamos picos na taxa de ANR a cada lançamento semanal do app", explica Nguyen Van Minh, engenheiro de software líder da equipe principal do app de passageiros da Grab. 

Para eliminar os ANRs e melhorar os tempos de inicialização, o Grab implementou otimizações do R8, perfis de referência e perfis de inicialização. A otimização guiada por perfil, junto com o otimizador R8, resultou em uma melhoria imediata de 12% na inicialização a frio do R8 e mais 15% dos perfis de referência, alcançando um tempo de inicialização 27% mais rápido e eliminando efetivamente os picos de ANR pós-lançamento.

A Grab executou essa otimização do app em três fases estratégicas: ativar a otimização do R8 no modo de compatibilidade, fazer a transição para o modo completo do R8 e, em seguida, refinar as regras de manutenção com o Configuration Analyzer e adicionar governança de CI/CD.

Fase 1: ativação da otimização do R8  (lançada em 2025)

Nessa primeira etapa, a Grab abandonou o arquivo padrão legado do Proguard para adotar o proguard-android-optimize.txt, que permite as otimizações do R8.  Como a base de código tinha mais de uma década e mais de 10 milhões de linhas de código, para ativar o otimizador, foi necessário lidar com configurações legadas e o uso de reflexão.

Para maximizar o impacto dessa fase, a Grab lançou a atualização do app com o modo de compatibilidade do R8 ativado, além de perfis de referência e de inicialização. Esse esforço combinado resultou em uma redução imediata de 25% nas taxas de ANR percebido pelo usuário, uma redução de 16% no tamanho do download do app e uma melhoria geral de 27% nos tempos de inicialização a frio.

Fase 2: modo completo e migração do R8 (lançamento em 2026)

Lançada nove meses após o primeiro lançamento, essa fase mudou o app para o modo completo do R8, que desbloqueou outras otimizações. Enquanto as bibliotecas padrão, como Retrofit, Firebase e Jetpack Compose, funcionaram perfeitamente com o R8 usando as regras integradas, a migração do restante da enorme base de código foi feita resolvendo caminhos de código específicos com muita reflexão:

Para migrar para o modo completo do R8, a equipe adotou as regras de manutenção do consumidor da versão mais recente do Gson para garantir uma análise JSON sem problemas. Eles também abordaram os desafios de otimização com proxies dinâmicos do Java, que usam reflexão para gerar implementações de interface no momento da execução. Como o R8 não consegue detectar esse uso de ambiente de execução durante a compilação, ele remove ou renomeia as classes necessárias, fazendo com que o aplicativo falhe. Em vez de aplicar exceções amplas que aumentariam o tamanho do app, a equipe isolou as classes específicas que dependem da reflexão e implementou regras de manutenção altamente direcionadas, preservando a estabilidade do app e a eficiência da otimização.

No final, o modo completo do R8 proporcionou melhorias enormes e cumulativas, incluindo uma redução adicional de 14% no tamanho do download do app, uma melhoria extra de 10% no tempo de inicialização e outra redução de 10% nos ANRs percebidos pelo usuário. Após a migração para o modo completo do R8, a base de código do Grab alcançou estas pontuações de otimização do R8. 

• Pontuação de otimização: 72%
• Pontuação de redução: 73%
• Pontuação de ofuscação: 79,6%

Essas pontuações forneceram feedback sobre a configuração do R8 e a necessidade de refinar as regras keep para maximizar a otimização do R8. 

Fase 3: refinamento da regra de manutenção 

Na fase final da jornada de otimização, a Grab está se concentrando em estabelecer a integridade da base de código a longo prazo, o monitoramento contínuo do desempenho e uma governança de compilação rigorosa. Para medir sistematicamente a higiene das regras e evitar regressões de configuração em ciclos de lançamento contínuos, a equipe está integrando o R8 Configuration Analyzer ao fluxo de trabalho de avaliação. Essa ferramenta oferece uma visibilidade profunda de como as regras keep do Grab permitem que o R8 otimize, reduza e ofusque o aplicativo.

Ao usar o modo completo do R8 como base e reduzir metodicamente as regras de manutenção legadas, o Grab está alcançando melhorias substanciais nas três dimensões principais avaliadas pelo analisador:

• Pontuação de otimização: está aumentando de 72% para 78,2%
• Pontuação de redução: está aumentando de 73% para 79,1%
• Pontuação de ofuscação: está aumentando de 79,6% para 81,7%

Além de melhorar essas pontuações de diagnóstico, essa fase dedicada de refinamento da regra de manutenção está resultando em uma redução adicional de aproximadamente 3,6% no tamanho do download do app. Mais importante ainda, o acompanhamento dessas métricas fornece à equipe de engenharia os dados objetivos necessários para implementar proteções de CI automatizadas antes da mesclagem, garantindo que o código recém-introduzido siga padrões rígidos de regras de manutenção e que os ganhos de desempenho conquistados com esforço permaneçam protegidos ao longo do tempo.

Resultados

Principais melhorias de desempenho após o lançamento do otimizador R8:

Desafios técnicos 

A ativação do otimizador R8 na base de código de uma década da Grab apresentou obstáculos técnicos importantes em escala:

• Teste:uma década de reflexão acumulada criou casos extremos sob otimização total. Como era impossível realizar testes exaustivos em milhões de LOC, a equipe adotou uma abordagem incremental de alta prioridade, concentrando os testes na cobertura de código coberta pelas regras de manutenção que estavam sendo reduzidas e refinando essas regras de forma iterativa para segmentar apenas as classes, os métodos ou os campos específicos necessários para a reflexão, maximizando a otimização do R8.
• Latência de build e arquitetura híbrida:o sistema de build híbrido da Grab (Bazel para depuração, Gradle para builds de lançamento do R8) significava que as mudanças experimentais do R8 exigiam até 2 horas na CI remota. Para preencher a lacuna de feedback, a Grab alinhou as versões diárias de controle de qualidade para corresponder ao comportamento do R8 de produção e automatizou a coleta de artefatos de build de CI importantes, como mapping.txt e configuration.txt, para simplificar a investigação.
• Ciclos de depuração lentos:rastrear as causas raiz em centenas de classes otimizadas era um fardo pesado para uma equipe enxuta. A Grab resolveu isso automatizando os uploads de arquivos de mapeamento para o Firebase Crashlytics via Gradle e agrupando mapeamentos de desofuscação para o Play Console, o que permitiu a resolução instantânea e precisa de símbolos para problemas de tempo de execução

Impacto do código a longo prazo com o R8

Além dos ganhos imediatos de desempenho, a ativação do otimizador R8 gerou uma vantagem estrutural permanente para a enorme base de código da Grab. Na Grab, a equipe usou a ferramenta de código aberto app-sizer para medir o impacto do R8 e observou que ele reduziu permanentemente o custo de cada linha de código no app em termos de tamanho de download.

Na era do desenvolvimento assistido por IA, em que o volume de código aumenta rapidamente, essa otimização é ainda mais importante. Sem o R8, a expansão do código aumenta proporcionalmente o tamanho do download. O R8 garante que a mesma taxa de expansão de código mantenha um consumo de memória drasticamente reduzido.

Observação: metodologia: contribuição do Kotlin/Java do app-sizer para o tamanho de download do app (dispositivo representativo), dividida pelas linhas de código (LOC) do Kotlin de produção (cloc; somente conjuntos de origem principais; módulos de teste, simulação e amostra excluídos).

Gerenciamento de regras e proteções do Keep

Para evitar a degradação das regras e manter as otimizações do R8 ao longo do tempo, o Grab planeja integrar proteções automatizadas de pré-mesclagem diretamente ao pipeline de CI. De acordo com essa política, novas regras de retenção são estritamente restritas, e qualquer regra adicional exige justificativa e análise explícitas. A equipe da Grab monitora as pontuações de otimização do R8 na CI. Com base nisso, a equipe planeja usar essas métricas como um ciclo de feedback contínuo, para que as regressões sejam detectadas antes da mesclagem e os ganhos de otimização sejam preservados em todos os ciclos de lançamento. 

Figura 1: painel de CI que monitora as pontuações de redução, otimização e ofuscação do R8 ao longo do tempo em builds do Grab para identificar e evitar regressões de forma proativa em todas as versões.

Conclusão 

Diante dos desafios de uma base de código enorme e em amadurecimento, a equipe do Pax App Core da Grab enfrentou proativamente o aumento dos tempos de inicialização e os picos de desempenho pós-lançamento, implementando perfis de referência e melhorando continuamente a configuração do R8. A equipe reduziu os ANRs percebidos pelo usuário em cerca de 32,5%, o tamanho do download do app em cerca de 30,3% e o tempo de inicialização a frio em cerca de 35%, além de melhorar fundamentalmente a eficiência do escalonamento da base de código.

Essas otimizações proporcionaram uma experiência de superapp mais rápida e estável para milhões de usuários no Sudeste Asiático, além de oferecer aos engenheiros da Grab as ferramentas para criar recursos mais rapidamente sem o aumento do tamanho do download.

Para começar e saber mais sobre o R8, acesse - d.android.com/r8.