Coletor de lixo no Android

Tenho visto muitas respostas do Android que sugerem chamar o coletor de lixo em algumas situações.

É uma boa prática solicitar o coletor de lixo no Android antes de fazer uma operação que consome muita memória? Caso contrário, devo chamá-lo apenas se receber um OutOfMemoryerro?

Há outras coisas que devo usar antes de recorrer ao coletor de lixo?

Para versões anteriores a 3.0 honeycomb : Sim, ligue System.gc() .

Tentei criar bitmaps, mas sempre obtinha "erro de VM sem memória". Mas, quando liguei System.gc()primeiro, estava tudo bem.

Ao criar bitmaps, o Android geralmente falha com erros de falta de memória e não tenta coletar o lixo primeiro . Portanto, chame System.gc()e você terá memória suficiente para criar Bitmaps.

Se estiver criando objetos, acho System.gcque será chamado automaticamente se necessário, mas não para criar bitmaps. Simplesmente falha.

Portanto, eu recomendo chamar manualmente System.gc()antes de criar bitmaps.

De modo geral, na presença de um coletor de lixo, nunca é uma boa prática chamar manualmente o GC. Um GC é organizado em torno de algoritmos heurísticos que funcionam melhor quando deixados por conta própria. Chamar o GC manualmente geralmente diminui o desempenho.

Ocasionalmente , em algumas situações relativamente raras, pode-se descobrir que um determinado GC está errado e uma chamada manual para o GC pode melhorar as coisas em termos de desempenho. Isso ocorre porque não é realmente possível implementar um GC "perfeito" que gerenciará a memória de forma otimizada em todos os casos. Essas situações são difíceis de prever e dependem de muitos detalhes sutis de implementação. A "boa prática" é deixar o GC funcionar sozinho; uma chamada manual para o CG é a exceção, que deve ser prevista somente após um problema de desempenho real ter sido devidamente testemunhado.

Falta de memória no aplicativo Android é muito comum se não manusearmos o bitmap adequadamente. A solução para o problema seria

if(imageBitmap != null) {
    imageBitmap.recycle();
    imageBitmap = null;
}
System.gc();
BitmapFactory.Options options = new BitmapFactory.Options();
options.inSampleSize = 3;
imageBitmap = BitmapFactory.decodeFile(URI, options);
Bitmap  scaledBitmap = Bitmap.createScaledBitmap(imageBitmap, 200, 200, true);
imageView.setImageBitmap(scaledBitmap);

No código acima, tentei reciclar o bitmap, o que permitirá que você libere o espaço de memória usado, portanto, a falta de memória pode não acontecer. Tentei funcionar para mim.

Se ainda estiver enfrentando o problema, você também pode adicionar essas linhas

BitmapFactory.Options options = new BitmapFactory.Options();
options.inTempStorage = new byte[16*1024];
options.inPurgeable = true;

para mais informações, dê uma olhada neste link

https://web.archive.org/web/20140514092802/http://voices.yahoo.com/android-virtual-machine-vm-out-memory-error-7342266.html?cat=59

NOTA: Devido ao momentânea "pausa" causada pela realização de gc, é que não é recomendado para fazer isso antes de cada alocação de bitmap.

O design ideal é:

1. Libertar todos os bitmaps que já não são necessários , pelo if / recycle / nullcódigo mostrado. (Faça um método para ajudar nisso.)

2. System.gc();

3. Aloque os novos bitmaps.

Se você obtiver um OutOfMemoryError, geralmente é tarde demais para chamar o coletor de lixo ...

Aqui está uma citação do desenvolvedor Android:

Na maioria das vezes, a coleta de lixo ocorre por causa de toneladas de objetos pequenos e de curta duração e alguns coletores de lixo, como coletores de lixo geracionais, podem otimizar a coleta desses objetos para que o aplicativo não seja interrompido com muita frequência. O coletor de lixo do Android infelizmente não é capaz de realizar tais otimizações e a criação de objetos de curta duração em caminhos de código de desempenho crítico é, portanto, muito cara para seu aplicativo.

Portanto, no meu entendimento, não há necessidade urgente de ligar para o gc. É melhor despender mais esforço para evitar a criação desnecessária de objetos (como a criação de objetos dentro de loops)

Parece System.gc()não funcionar no Art Android 6.0.1 Nexus 5x, então eu uso em seu Runtime.getRuntime().gc();lugar.

Meu aplicativo gerencia muitas imagens e morreu com um OutOfMemoryError. Isso me ajudou. No Manifest.xml Adicionar

<application
....
   android:largeHeap="true"> 

De um modo geral, você não deve chamar GC explicitamente com System.gc (). Existe até a palestra IO ( http://www.youtube.com/watch?v=_CruQY55HOk ) onde eles explicam o que o log de pausas do GC significa e na qual eles também afirmam para nunca chamar System.gc () porque Dalvik sabe melhor do que você quando fazê-lo.

Por outro lado, como mencionado nas respostas acima, o processo de GC no Android (como tudo o mais) às vezes apresenta erros. Isso significa que os algoritmos Dalvik GC não estão no mesmo nível dos JVMs Hotspot ou JRockit e podem errar em algumas ocasiões. Uma dessas ocasiões é ao alocar objetos de bitmap. Isso é complicado porque usa memória Heap e Non Heap e porque uma instância solta de objeto de bitmap no dispositivo com restrição de memória é suficiente para fornecer uma exceção OutOfMemory. Portanto, chamá-lo depois de não precisar mais desse bitmap é geralmente sugerido por muitos desenvolvedores e até considerado uma boa prática por algumas pessoas.

A prática recomendada é usar .recycle () em um bitmap, pois é para isso que esse método foi feito, pois ele marca a memória nativa do bitmap como segura para exclusão. Tenha em mente que isso depende muito da versão, o que significa que geralmente será necessário em versões mais antigas do Android (Pre 3.0, eu acho), mas não será necessário em versões posteriores. Também não vai doer muito usá-lo em versões mais novas do ether (apenas não faça isso em um loop ou algo parecido). O novo tempo de execução do ART mudou muito aqui porque eles introduziram uma "partição" especial do Heap para objetos grandes, mas acho que não vai doer muito fazer isso com o ART ether.

Também uma observação muito importante sobre System.gc (). Este método não é um comando ao qual Dalvik (ou JVMs) são obrigados a responder. Considere isso mais como dizer à máquina virtual "Você poderia fazer a coleta de lixo se não for um incômodo".

A melhor maneira de evitar OOM durante a criação de bitmap,

http://developer.android.com/training/displaying-bitmaps/index.html

Eu diria que não, porque os documentos do desenvolvedor sobre o estado de uso de RAM :

...
GC_EXPLICIT

Um GC explícito, como quando você chama gc () (que você deve evitar chamar e, em vez disso, confiar que o GC será executado quando necessário).

...

Eu destaquei a parte relevante em negrito.

Ter um olhar para a série YouTube, do Android Performance Patterns - que irá mostrar-lhe dicas sobre o gerenciamento de uso de memória do seu aplicativo (como o uso do Android de ArrayMaps e SparseArrays em vez de HashMaps).

Nota rápida para desenvolvedores Xamarin .

Se você gostaria de chamar System.gc()em aplicativos Xamarin.Android você deve chamarJava.Lang.JavaSystem.Gc()

Não há necessidade de chamar o coletor de lixo após um OutOfMemoryError.

Seu Javadoc afirma claramente:

Thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, and no more memory could be made available by the garbage collector.

Portanto, o coletor de lixo já tentou liberar memória antes de gerar o erro, mas não teve êxito.