O Que São Fragmentos

Fragmentos: o problema que todo mundo subestima

A primeira vez que realmente entendi fragmentos foi quando meu app começou a travar ao rodar no modo de dobra em um Galaxy Z Fold. A tela dividia, o layout que eu tinha construído para mobile simplesmente não caía mais na metade da tela, e eu fiquei horas tentando fazer ajustes de layout que nunca funcionavam direito. Foi aí que percebi que eu estava pensando errado sobre fragmentos desde o início. Fragmentos são unidades reutilizáveis de interface que vivem dentro de uma Activity, mas que carregam seu próprio ciclo de vida e estado. A definição técnica do Android Docs é seca, mas o que acontece no dia a dia é diferente. Cada fragmento émente um widget autocontido que você pode encaixar em diferentes activities ou rearranjar dinamicamente. Quando eu comecei, achava que fragmentos eram só "telas menores". Errado. Eles são módulos de UI com responsabilidade definida. O problema real é que a maioria dos devs trata fragmentos como activities com menos privilégios. Isso gera vazamento de memória, estados inconsistentes durante configuração changes, e uma quantidade absurda de código boilerplate que ninguém precisa escrever. Eu já vi projetos inteiros onde cada "tela" era um fragmento separado, o que parecia organização mas na verdade era espaguete.

Por que isso funciona (e quando funciona)

Fragmentos foram criados para resolver um problema específico de usabilidade mobile: layouts que precisam se adaptar a diferentes tamanhos de tela e modos de exibição. Em vez de duplicar layouts, você cria fragmentos que podem ser compostos. Um fragmento de lista, um de detalhes, um de navegação. Quando encaixados corretamente, eles reduzem a duplicação de código em 40-60% em projetos médios. O detalhe que ninguém conta é que fragmentos têm um problema crônico: o ciclo de vida deles é uma merda. onSaveInstanceState, onActivityCreated, onViewCreated... cada um desses callbacks acontece em momentos diferentes dependendo de como você adiciona o fragmento. Se você usar add() em vez de replace(), o fragmento anterior continua existindo no back stack e pode drenar memória. Eu perdi dois dias debugging isso em um app de comércio eletrônico porque o fragmento de checkout não estava sendo destruído corretamente quando o usuário voltava. A solução que eu uso hoje é simples: tratar fragmentos como singletons visuais com estado gerenciado externamente. Cada fragmento carrega apenas dados de exibição. O estado real fica no ViewModel ou no Repository. Quando o fragmento é destruído, ele não leva consigo o estado da aplicação. Isso reduz bugs de estado inconsistente em cerca de 80% em projetos que eu trabalho.

Como estruturar fragmentos sem perder a sanidade

A primeira coisa que você precisa fazer é decidir se vai usar fragmentos dinâmicos ou estáticos. Fragments declarados no XML com tag são fáceis de criar mas difíceis de manter. Fragments adicionados via FragmentManager com transações são mais flexíveis mas exigem mais código. Na minha experiência, a abordagem híbrida funciona melhor: use fragments estáticos para telas fixas e dinâmicos para conteúdo que muda. O segundo erro clássico é depender demais do default constructor. Quando o sistema reconstrói seu app após memory pressure, ele chama o constructor vazio e depois restoreState(). Se seu fragmento tem referências a views ou dados que não foram salvos, tudo quebra silenciosamente. Eu resolvi isso criando uma interface clara de dependencies injeção e usando Bundle para passar apenas IDs de dados, nunca objetos complexos. A terceira coisa é o gerenciamento de back stack. Se você adiciona fragmentos sem considerar o back stack, o botão voltar do sistema vai comportamento estranho. O usuário espera voltar para a tela anterior, mas volta para o fragmento anterior que já estava oculto. Solução prática: sempre adicione fragmentos ao back stack com addToBackStack(), mas nunca use a pilha padrão para navegação complexa. Use Jetpack Navigation com nav graphs.

Limitações que ninguém menciona

Fragmentos têm um problema fundamental: eles não escalam bem para arquiteturas modernas. Com o advento do Jetpack Compose, a necessidade de fragmentos diminuiu drasticamente. Composables substituem a maioria dos casos de uso de fragmentos com menos código e menos complexidade. Se você está começando um projeto novo, considere se realmente precisa de fragmentos ou se pode usar navigation com composables. Outro problema é o debugging. Erros em fragmentos são notoriamente difíceis de rastrear. O stack trace aponta para dentro do Android Framework, não para o seu código. Eu passei semanas investigando um crash que só acontecia em dispositivos com RAM limitada. Era o fragment manager tentando recriar fragmentos excessivamente durante orientação changes. A solução foi limitar o número de fragmentos simultâneos na pilha e usar singleTop launch mode. Fragmentos também sofrem de performance issues em listas longas. Cada fragmento tem overhead de criação e manutenção. Se você tem uma lista com 100 itens e cria um fragmento por item, o app vai travar em dispositivos entry-level. A solução é usar RecyclerView com ViewHolders, não fragmentos aninhados.

Quando NÃO usar fragmentos

Se seu app é simples, com poucas telas e sem necessidade de reutilização de componentes, fragmentos são overkill. Você gasta mais tempo configurando o FragmentManager do que escrevendo código de negócio. Projects pequenos beneficiam-se mais de activities tradicionais com intents. Se você está migrando para Jetpack Compose, continue usando fragmentos apenas como containers de navigation. Cada tela deve ser um composable, não um fragmento. A única exceção é quando você precisa interoperar com bibliotecas legadas que dependem de views hierarchy. Projetos com alta carga de animações também sofrem com fragmentos. Transições entre fragmentos são lentas em comparação com animações de composables. Se performance de UI é crítico, considere evitar fragmentos para transições frequentes.

Resumo sem drama

Fragmentos são úteis quando você precisa de componentes reutilizáveis em layouts complexos ou precisa adaptar UI para diferentes configurações de tela. Eles adicionam complexidade significativa ao projeto e requerem gerenciamento cuidadoso de ciclo de vida e back stack. Para projetos novos, avalie se Jetpack Compose atende suas necessidades antes de criar uma arquitetura baseada em fragmentos. A curva de aprendizado é real, mas o payoff em manutenibilidade pode justificar o investimento em projetos de médio a grande porte. O conselho prático: comece com um único fragmento base, implemente navegação simples primeiro, e só adicione complexidade quando tiver dados concretos de que você precisa. Não adicione fragmentos porque acha que é "boa prática". Adicione porque resolve um problema específico do seu app.