Quais são as vantagens de definir largeHeap como true?

Tenho um App com quase 50 turmas que estou montando android:largeHeap="true", como pode ser visto a seguir. Esta é uma boa prática?

<application
        android:name=".MyApplication"
        android:allowBackup="true"
        android:icon="@drawable/ic_launcher"
        android:label="Mall"
        android:largeHeap="true"
        android:logo="@drawable/logo_for_up"
        android:screenOrientation="portrait"
        android:theme="@style/AppTheme" >
</application>

Sugira vantagens e desvantagens para usá-lo.

Estou tendo problemas de memória, é por isso que faço esta pergunta.

Tarde demais para a festa aqui, mas vou oferecer meus 0,02 $ de qualquer maneira.
Não é uma boa ideia usar android:largeHeap="true" este trecho do Google que explica isso,

No entanto, a capacidade de solicitar um grande heap destina-se apenas a um pequeno conjunto de aplicativos que podem justificar a necessidade de consumir mais RAM (como um grande aplicativo de edição de fotos). Nunca solicite um heap grande simplesmente porque você ficou sem memória e precisa de uma solução rápida - você deve usá-lo apenas quando souber exatamente onde toda a sua memória está sendo alocada e por que deve ser retida. No entanto, mesmo quando você tem certeza de que seu aplicativo pode justificar o grande heap, você deve evitar solicitá-lo na medida do possível. O uso da memória extra prejudicará cada vez mais a experiência geral do usuário porque a coleta de lixo levará mais tempo e o desempenho do sistema pode ser mais lento durante a alternância de tarefas ou a execução de outras operações comuns.

aqui está o link completo da documentação https://developer.android.com/training/articles/memory.html

ATUALIZAR

Depois de trabalhar excrutantemente com, out of memory errorseu diria que adicionar isso ao manifesto para evitar o problema de oom não é um pecado, também como @Milad aponta abaixo, isso não afeta o funcionamento normal do aplicativo

ATUALIZAÇÃO 2

Aqui estão algumas dicas para lidar comout of memory errors

1) Use estes callbacks que o android fornece onLowMemory, onTrimMemory(int) e limpe o cache de imagens como (picasso, glide, fresco ....) você pode ler mais sobre eles aqui e aqui
2) comprima seus arquivos (imagens, pdf)
3) leia sobre como lidar com bitmap de forma mais eficiente aqui
4) Use lint regularmente antes de impulsos de produção para garantir que o código seja elegante e não volumoso

Acho que esta é uma pergunta muito eficaz e deixe-me adicionar alguns detalhes sobre as vantagens e desvantagens de usar essa opção.

O que você obtém:

• Obviamente, você obtém heap maior, o que significa diminuição do risco de OutOfMemoryError.

O que você perde:

• Você pode perder alguns quadros, o que pode causar um engate visível . Um heap maior faz com que as coletas de lixo demorem mais. Porque o coletor de lixo basicamente tem que percorrer todo o seu conjunto ativo de objetos. Normalmente, o tempo de pausa da coleta de lixo é de cerca de 5 ms, e você pode pensar que alguns milissegundos não são grande coisa. Mas cada milissegundo conta. O dispositivo Android precisa atualizar sua tela a cada 16 ms e um tempo de GC mais longo pode empurrar o tempo de processamento de seu quadro para além da barreira de 16 milissegundos, o que pode causar um engate visível.

• Além disso, a troca de aplicativos ficará mais lenta . O sistema Android pode matar processos no cache LRU começando com o processo menos usado recentemente, mas também levando em consideração quais processos consomem mais memória. Portanto, se você usar um heap maior, é mais provável que seu processo seja eliminado quando estiver em segundo plano, o que significa que pode demorar mais tempo quando os usuários desejam alternar de outros aplicativos para o seu. Além disso, outros processos em segundo plano serão mais propensos a serem eliminados quando o processo estiver em primeiro plano, porque seu aplicativo requer mais memória. Isso significa que mudar de seu aplicativo para outros aplicativos também leva mais tempo.

Conclusão:

Evite usar a largeHeapopção tanto quanto possível. Pode custar a você uma queda de desempenho difícil de perceber e uma experiência ruim para o usuário.

Eu tenho um aplicativo com quase 50 aulas

Não acho que isso seja muito problema. O motivo do erro outOfMemory geralmente é o carregamento de muitas imagens em seu aplicativo ou algo parecido. Se você não estiver satisfeito com o uso de heap grande, deverá encontrar uma maneira de otimizar o uso da memória.

Você também pode usar Bibliotecas de carregamento de imagens, como Picasso , UIL ou Glide . Todos eles possuem a funcionalidade de cache de imagens na memória e / ou no disco.

Na verdade, android: largeHeap é o instrumento para aumentar a memória alocada para o aplicativo.

Não há uma definição clara da necessidade de usar este sinalizador. Se você precisar de mais memória - o Android fornece uma ferramenta para aumentá-la. Mas a necessidade de usar, você se define.

Se você deve usar (e reter) uma grande quantidade de memória, então sim, você pode e deve usar android:largeHeap="true". Mas se você usá-lo, deve estar preparado para esvaziar seu aplicativo da memória sempre que outros aplicativos estiverem em primeiro plano.

Por "estar preparado", quero dizer que você deve projetar para essa probabilidade, de modo que seus métodos onStop()e onResume()sejam escritos da forma mais eficiente possível, enquanto garante que todo o estado pertinente seja salvo e restaurado de uma maneira que apresente uma aparência perfeita para o usuário.

Existem três métodos que se relacionam com este parâmetro: maxMemory(), getMemoryClass(), e getLargeMemoryClass().

Para a maioria dos dispositivos, maxMemory()representará um valor semelhante a getMemoryClass()por padrão, embora o último seja expresso em megabytes, enquanto o primeiro seja expresso em bytes.

Quando você usa o largeHeapparâmetro, maxMemory()será aumentado para um nível superior específico do dispositivo, enquanto getMemoryClass()permanecerá o mesmo.

getMemoryClass()não restringe o tamanho do heap, mas informa a quantidade de heap que você deve usar se quiser que seu aplicativo funcione de maneira confortável e compatível dentro dos limites do dispositivo específico no qual você está executando.

maxMemory(), Pelo contrário, não restringir o seu tamanho da pilha, e assim você faz ter acesso a pilha adicional através do aumento do seu valor, e largeHeapfaz aumentar esse valor. No entanto, a quantidade aumentada de heap ainda é limitada e esse limite será específico do dispositivo, o que significa que a quantidade de heap disponível para seu aplicativo irá variar, dependendo dos recursos do dispositivo no qual seu aplicativo está sendo executado. Portanto, usar largeHeapnão é um convite para que seu aplicativo abandone todo cuidado e abra caminho no buffet livre.

Seu aplicativo pode descobrir exatamente quanta memória seria disponibilizada em um dispositivo específico usando o largeHeapparâmetro invocando o método getLargeMemoryClass(). O valor retornado está em megabytes.

Esta postagem anterior inclui uma discussão sobre o largeHeapparâmetro, bem como uma série de exemplos de quais quantidades de heap são disponibilizadas com e sem seu uso, em vários dispositivos Android específicos:

Detectar o tamanho do heap do aplicativo no Android

Não implantei nenhum dos meus próprios aplicativos com este parâmetro definido como verdadeiro. No entanto, tenho algum código que consome muita memória em um de meus aplicativos para compilar um conjunto de parâmetros relacionados à otimização, que é executado apenas durante o desenvolvimento. Eu adiciono o largeHeapparâmetro apenas durante o desenvolvimento, para evitar erros de falta de memória ao executar este código. Mas eu removo o parâmetro (e o código) antes de implantar o aplicativo.

Se os processos do seu aplicativo devem ser criados com um grande heap Dalvik. Isso se aplica a todos os processos criados para o aplicativo. Ele se aplica apenas ao primeiro aplicativo carregado em um processo; se você estiver usando uma ID de usuário compartilhada para permitir que vários aplicativos usem um processo, todos eles devem usar esta opção de forma consistente ou terão resultados imprevisíveis.

A maioria dos aplicativos não precisa disso e, em vez disso, deve se concentrar na redução do uso geral da memória para melhorar o desempenho. Habilitar isso também não garante um aumento fixo na memória disponível, porque alguns dispositivos são limitados por sua memória total disponível.