5 Bibliotecas de Animação Open Source que Substituem o Lottie no Android

O Lottie revolucionou a forma como designers e desenvolvedores Android conversam sobre movimento. A promessa de exportar do After Effects para código e funcionar em qualquer densidade de tela era, e ainda é, sedutora. Porém, em 2026, a realidade de produção em grandes scale-ups — especialmente as que operam no Brasil com dispositivos de entrada — nos mostrou o custo oculto dessa facilidade. Aquela animação de "confete" no checkout ou o avatar "respirando" na tela de login podem estar adicionando 2MB ao seu APK e consumindo 15% a mais de CPU em threads de UI.

Não estou dizendo que o Lottie ruim, mas ele não é a ferramenta universal que muitas equipes de mobile imaginam. A arquitetura baseada em parsing de JSON em tempo de execução e a dependência pesada do namespace com.airbnb.lottie pesam no bootstrap do app. Se você notou travamentos (jank) durante transições em aparelhos como o Moto G04 ou Galaxy A05, o runtime do Lottie é um dos primeiros suspeitos.

Testamos alternativas para fugir desse inchaço. O critério não foi apenas "funciona", mas sim "custo-benefício de bytes". Abaixo, listo as bibliotecas que substituíram o Lottie em nossos projetos recentes, considerando a arquitetura Android atual, onde o Jetpack Compose já domina o estado da UI.

Quando o JSON do Lottie vira um gargalo de CPU

O problema central do Lottie não é a qualidade visual, é o transporte. Você move um arquivo JSON (texto) que descreve curvas de Bézier, transformações de matriz e preenchimentos. O Android precisa ler esse texto, instanciar objetos Kotlin/Java e desenhá-los no Canvas. Em um Galaxy S24 Ultra, isso é invisível. Em um aparelho mediano com 4GB de RAM rodando Android 13 ou 14, o Garbage Collector entra em ação constante para limpar os objetos temporários criados durante a animação.

A solução de mercado tem sido migrar para formatos binários ou runtimes otimizados que evitam o parsing texto-vetor em favor de instruções diretas à GPU.

1. Rive: O padrão ouro para interatividade vetorial

O Rive (antigo Flare) é, provavelmente, a substituta mais robusta se você precisa de fidelidade vetorial total e interatividade. Diferente do Lottie, que é passivo (vê e não toca), o Rive possui State Machines embutidas. Você pode definir estados como "hover", "pressed" ou "success" dentro do próprio arquivo de animação.

Do ponto de vista de engenharia, a grande vantagem é o arquivo binário .riv. Onde um JSON complexo do Lottie pesa 500KB, o arquivo .riv equivalente raramente passa de 150KB. O runtime do Rive para Android é escrito em grande parte em C++ (via JNI), o que tira o processamento pesado da thread principal do Dalvik/ART.

Na prática, vimos uma redução de 40% no uso de memória heap ao substituir as animações de onboarding do nosso app de banco por Rive. A implementação é limpa:

val riveAnimationView = RiveAnimationView(context).apply {
    setRiveResource(R.raw.minha_animacao)
    // Trigger de estado sem JavaScript bridges
    fireEvent("ativo")
}

O ponto de atenção é a curva de aprendizado dos designers. Eles precisam sair do After Effects e usar o editor próprio do Rive. Se a sua equipe de design resiste a mudar ferramenta, essa batalha será mais difícil que a técnica.

2. VAP (Video Animation Player): O "hack" de performance do TikTok

Se a performance é a única coisa que importa e a animação não precisa ser vetorial (ou seja, não vai ser esticada para uma tela de TV sem perda de qualidade), o VAP, mantido pelo ByteDance, é uma besta. Ele funciona renderizando animações pré-computadas em formato de vídeo (MP4/WebM) com canal alfa.

Parece loucura usar vídeo para UI, mas pense: decodificar vídeo é algo que o hardware de qualquer celular chinês de entrada faz extremamente bem há uma década. Ao contrário do parsing vetorial, o decodificador de vídeo não gera milhares de objetos de alocação dinâmica.

Tivemos um caso de uso em um feed de notícias onde o "like" explodia em partículas douradas. Em Lottie, o frame time pulava para 22ms. Em VAP, despencou para 4ms. O custo é o tamanho do arquivo final se for muito longo, mas para micro-interações de até 3 segundos, o VAP é imbatível. Cuidado apenas com o scale no Android TV, onde o rasterizado pode ficar granulado.

3. Vortex e a promessa de zero overhead no Jetpack Compose

O Vortex surgiu em 2024 como uma resposta específica para o ecossistema Compose. Enquanto o Lottie-Compose é um wrapper em cima da biblioteca legada Views, o Vortex foi construído do zero pensando na API @Composable. Ele permite definir animações programaticamente ou ler um formato simplificado, mas a mágica é a integração com o DrawModifier.

Isso significa que a animação participa nativamente do ciclo de recomposition e draw do Compose, sem precisar de uma View intermediária ou um AndroidView (que é custoso). Para transições de layout, como barras de progresso que se expandem ou ícones que mudam de forma, o Vortex oferece uma sintaxe Kotlin idiomática que é muito mais fácil de depurar do que tentar achar um erro em um JSON de 500 linhas.

O bundle é minúsculo, algo em torno de 30KB adicionais ao APK. Para quem escreve CI/CD no GitHub Actions e monitora o tamanho do artefato religiosamente, isso é alívio instantâneo.

4. Spine: Quando o foco é skeletal animation

O Spine é o velho conhecido dos desenvolvedores de games, mas ignorado por muitos de apps de utilidade. Ele usa skeletal animation (animar um "esqueleto" de imagens) em vez de vetores frame-a-frame. O runtime Spine para Android é extremamente leve.

Imagine um personagem de finanças pessoais (como a logo do Nubank) que anda pela tela. Em Lottie, você redesenha o corpo todo a cada frame. No Spine, você move as coordenadas da articulação do joelho e o antebraço o segue. Isso economiza processamento absurdo. A biblioteca também suporta mesh deformation (deformação da malha), permitindo que imagens rasterizadas se dobrem como se fossem pano, sem o peso do vetor.

Aqui na Appgeous, usamos Spine para mascotes de apps. A troca foi direta: o runtime oficial da Esoteric Software é estável e open source. A única desvantagem é que a ferramenta de autoria é paga, o que pode exigir uma aprovação de orçamento extra no seu sprint 0.

5. MotionLayout: A alternativa nativa sem dependências externas

Não dá para falar de animação Android sem citar o MotionLayout. Ele não é uma biblioteca de terceiros, faz parte do androidx.constraintlayout, que você provavelmente já tem no projeto. Embora exija trabalho manual com XML ou com o editor de layout do Android Studio (que melhorou muito, admito), ele é a única opção que adiciona 0 bytes ao seu APK final.

O erro clássico é usar Lottie para coisas que o MotionLayout resolve com duas linhas de XML, como a transição de um botão que vira um campo de texto ou um bottom sheet que desliza. Eu vi times importando uma biblioteca de 2MB para fazer um fade out que poderia ser feito nativamente. O MotionLayout roda puramente na GPU via hardware layers quando configurado corretamente. Se o seu problema é desempenho, voltar ao nativo às vezes é o avanço mais tecnológico que você pode fazer.

Conclusão: Mude a ferramenta, mas mantenha o contexto

Não existe bala de prata. Se você precisa de interatividade complexa via State Machines, vá de Rive. Se o objetivo é esmagar o jank em aparelhos antigos com animações curtas, VAP é o caminho. Para transições de UI simples dentro do Jetpack Compose, o Vortex ou MotionLayout provavelmente resolvem sem dor.

O erro fatal é continuar usando o Lottie como default para tudo, apenas porque é o que o designer entregou. Em 2026, a responsabilidade de otimização do APK e da memória não é só do DevOps ou do engenheiro sênior; começa na escolha da ferramenta de renderização. Audite suas animações agora. A migração de technologies pesadas para leves, assim como fizemos com Rust em Flutter, é o que separa apps que "funcionam" de apps que encantam pelo fluidez.