GrenderG/Toasty

Memory leak when allowQueue=false

Open

#128 aberto em 12 de nov. de 2019

Ver no GitHub
 (3 comments) (0 reactions) (0 assignees)Java (822 forks)batch import
bughelp wanted

Métricas do repositório

Stars
 (6.535 stars)
Métricas de merge de PR
 (Nenhuma PRs mesclada em 30d)

Description

If allowQueue parameter set to false Toasty uses lastToast static variable to save previous Toast object which holds reference to Context causing memory leak. Leak is reported by com.squareup.leakcanary library.

You need to set allowQueue to true to eliminate leak (no static reference to Context).

// Causing leak
            Toasty.custom(_context, _text,
                    ContextCompat.getDrawable(_context, R.drawable.ic_alert_white_36dp),
                    ContextCompat.getColor(_context, R.color.warn_background),
                    ContextCompat.getColor(_context, R.color.defaultTextColor),
                    _duration, true, true).show();

// No leak
Toasty.Config.getInstance().allowQueue(true).apply();
Toasty.custom(_context, _text,
                    ContextCompat.getDrawable(_context, R.drawable.ic_alert_white_36dp),
                    ContextCompat.getColor(_context, R.color.warn_background),
                    ContextCompat.getColor(_context, R.color.defaultTextColor),
                    _duration, true, true).show();

Guia do colaborador

Direção de pesquisa
O vazamento de memória tem origem no campo estático `lastToast` na classe `Toasty`. Investigue como `allowQueue` afeta a atribuição e a limpeza desse campo. Uma correção potencial é substituir a referência estática por uma WeakReference ou limpá la após o toast ser dispensado. Revise o método `Toasty.custom()` e a classe `Config` para entender a lógica. Certifique se de adicionar testes unitários para verificar que nenhum vazamento de memória ocorra.
Pilha de tecnologia
java
Domain
mobileperformance
Tipo Issue
Bug
DifficultyDificuldade de implementação estimada para um novo contribuidor, de 1 para alterações muito pequenas a 5 para trabalho de nível especializado.
2
Tempo estimadoUm intervalo de tempo aproximado para um colaborador experiente investigar, implementar, testar e preparar um pull request.
1-3 horas
Status da atividadeQuão disponível o issue aparece agora: novo, ativo, obsoleto, bloqueado ou aguardando entrada do mantenedor.
Antigo
ClarityCom que clareza o issue explica a mudança esperada, os critérios de aceitação e a próxima etapa.
Claro
Prerequisites
Java basicsAndroid context handlingMemory leak concepts
Simpatia para novatosUma pontuação de 1 a 100 que estima o quão acessível este issue é para colaboradores iniciantes.
75