Vazamento de memória: o que é, cenários típicos e diagnóstico

O que é um vazamento de memória em aplicativos móveis?

Vazamento de memória é uma situação em que a memória alocada não é retornada ao sistema depois que o objeto não é mais necessário para o programa. O coletor de lixo considera esse objeto como vivo porque há uma cadeia de referências ativa de um GC Root apontando para ele.

Em Java/Kotlin, o coletor de lixo funciona automaticamente, mas não consegue determinar que um objeto é logicamente desnecessário se houver uma referência técnica para ele. O desenvolvedor deve quebrar explicitamente as conexões desnecessárias. Em Swift/Objective-C, o ARC conta referências automaticamente, mas os retain cycles bloqueiam a diminuição do contador.

O principal perigo dos vazamentos é o efeito cumulativo. Cada vazamento consome uma pequena quantidade de memória, mas com transições repetidas entre telas (rotações de tela, abertura/fechamento de Activities), os vazamentos se acumulam até esgotar o limite do heap.

Como um vazamento difere de inchaço?

Vazamento — o objeto está inacessível ao código, mas não é removido pelo GC. Inchaço — o objeto é logicamente necessário, mas é armazenado em quantidade excessiva. Exemplo de inchaço: um cache de imagens de 100 MB com um conjunto de trabalho de 30 MB. Ambos os problemas levam a OOM, mas as causas e os métodos de tratamento são diferentes.

Como funciona o coletor de lixo e por que ocorrem vazamentos?

ART (Android Runtime) usa coleta de lixo geracional com compactação concorrente. A memória é dividida em geração jovem (Young), geração velha (Old) e objetos grandes (Large). Objetos que sobrevivem a vários ciclos de GC são movidos para a geração Old, onde a coleta ocorre com menos frequência — isso acelera os ciclos normais.

O GC começa quando o heap atinge um certo limite de ocupação (normalmente 75-85%). Durante o GC, todas as threads do aplicativo são pausadas (STW — Stop The World). Quanto mais objetos vivos, mais longa a pausa. Os vazamentos aumentam o número de objetos vivos, prolongando as pausas do GC.

O coletor determina objetos vivos percorrendo o gráfico a partir das GC Roots: campos estáticos, variáveis de pilha de threads ativas, referências JNI. Qualquer objeto alcançável por referências a partir dessas raízes é considerado vivo — mesmo que o desenvolvedor saiba que não é mais necessário.

// Exemplo: coleção estática como GC Root — vazamento permanente
object GlobalHolder {
    val listeners = mutableListOf<WeakReference<Any>>()
}

class LeakingFragment : Fragment() {
    override fun onCreate(savedInstanceState: Bundle ?= null) {
        super.onCreate(savedInstanceState)
        GlobalHolder.listeners.add(WeakReference(this))
        // WeakReference não impede o GC — comportamento correto
    }
}

WeakReference resolve o problema: o GC ignora referências fracas ao determinar objetos vivos. Se apenas referências fracas restarem para um objeto, ele será coletado no ciclo de GC mais próximo.

Cenários típicos de vazamentos em Android e iOS

Activity Context — o cenário de vazamento mais massivo no Android. Se um singleton, campo estático ou serviço de longa duração armazena uma referência a um Activity Context, toda a Activity com todas as suas Views não pode ser coletada pelo GC. Solução: use Application Context para objetos de longa duração.

Handler e mensagens enviadas — Handler.postDelayed(runnable, delay) coloca uma mensagem na fila do Main Looper. Se a Activity for destruída antes do término do atraso, a mensagem ainda está na fila e mantém uma referência através de Runnable → classe anônima → classe externa (Activity).

class SafeActivity : AppCompatActivity() {
    private val mainHandler = Handler(Looper.getMainLooper())
    private val callback = Runnable { /* update UI */ }

    override fun onResume() {
        super.onResume()
        mainHandler.postDelayed(callback, 5000)
    }

    override fun onPause() {
        mainHandler.removeCallbacks(callback) // obrigatório: limpar fila
        super.onPause()
    }
}

Classes internas — uma classe interna não estática tem uma referência implícita à instância da classe externa. Se a classe externa for uma Activity e a classe interna for passada para algum lugar externo (por exemplo, para RecyclerView.Adapter), a Activity não pode ser coletada.

• TimerTask e ScheduledExecutorService — tarefas agendadas antes da destruição da Activity
• BroadcastReceiver — não registrado em onPause/onDestroy continua segurando o Context
• ViewModel com referência a View — ViewModel sobrevive à Activity, a referência à View leva a vazamento
• Retrofit Call — se o Call não for cancelado, a resposta chega a um Fragment destruído

Ferramentas de diagnóstico de vazamentos de memória

Android Studio Memory Profiler — ferramenta integrada para monitoramento de heap em tempo real. Mostra um gráfico de memória usada, número de alocações e objetos por tipo. Permite gravar um heap dump e exportá-lo no formato HPROF para análise no MAT.

Eclipse MAT (Memory Analyzer Tool) — analisador de desktop de heap dump. Constrói automaticamente relatórios de Leak Suspects, destacando objetos com o maior retained size e sugerindo a possível cadeia de GC Root para cada objeto suspeito.

Xcode Memory Graph Debugger — para iOS. Pausa o aplicativo e visualiza o gráfico de objetos. Retain cycles são destacados em vermelho; você pode clicar em qualquer objeto para ver seu retain count e referências.

De acordo com o Uber Engineering Blog, a integração de perfilamento automático de memória (LeakCanary + análise de heap dump) no pipeline CI/CD reduz incidentes relacionados à memória em produção em 60% em 3 meses.

Métodos para eliminar vazamentos

Substituir Context — se um objeto sobreviver à Activity, use applicationContext. Todos os objetos de longa duração (singletons, repositórios, helpers de banco de dados) devem receber Application Context, não Activity Context. Exceção: componentes de UI que precisam de acesso ao tema ou recursos específicos da Activity.

Componentes conscientes do ciclo de vida — usar LifecycleObserver, DefaultLifecycleObserver ou extensões reativas cancela automaticamente as assinaturas em onDestroy. O Android Jetpack fornece lifecycleScope e viewModelScope, que são limpos pelo evento de ciclo de vida correspondente.

Classe interna estática — se a classe interna não precisar de acesso aos campos da classe externa, torne-a static. Uma classe interna estática não tem referência implícita à classe externa. Se o acesso for necessário, use WeakReference para a referência explícita.

class MyActivity : AppCompatActivity() {

    // ❌ Classe interna não estática — referência implícita a MyActivity
    inner class BadListener : SomeListener {
        override fun onEvent() { /*...*/ }
    }

    // ✅ Classe interna estática — sem referência implícita
    class GoodListener(private val activityRef: WeakReference<MyActivity>) : SomeListener {
        override fun onEvent() { /*...*/ }
    }
}

Em iOS, use listas de captura: [weak self] em closures que podem sobreviver ao seu criador. Para delegados, use referências fracas (weak var delegate). Para closures que são garantidas de serem chamadas apenas durante a vida de self, [unowned self] pode ser usado, mas com cuidado — acessar um objeto desalocado causará uma falha.